CVE-2026-109618: RCE Out-of-Memory-tilan kautta

Lyhyesti: CVE-2026-109618 on toinen PHP2Shellin takana olevista haavoittuvuuksista. Out-of-Memory-tila voi keskeyttää PHP:n, kun pyyntötiedot on alustettu vasta osittain; siivouksessa virheelliset tiedot voivat sitten päätyä kelvollisina käsiteltäviksi. Se mahdollistaa koodin suorittamisen ilman kirjautumista. Virhe on korjattu versioissa PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35.

Mikä on CVE-2026-109618?

CVE-2026-109618 (GitHub-tunniste GHSA-w8hw-w9fx-j79w) on muistivirhe-haavoittuvuus PHP:n ytimessä. Sen CVSS v4.0 -pistemäärä on 9.2. Yhdessä haavoittuvuuden CVE-2026-109619 kanssa se muodostaa sen, mitä mediassa kutsutaan PHP2Shelliksi.

Vaikutus on niin sanottu unauthenticated Remote Code Execution: hyökkääjä voi suorittaa koodia verkkopalvelimella etänä ilman käyttäjätiliä. Haavoittuvuus kuuluu siis vaarallisimpaan luokkaan, joka verkkopalvelimella voi olla.

Miten haavoittuvuus periaatteessa syntyy

Kun PHP käsittelee verkkopyyntöä, se luo sisäisesti tietorakenteita tälle pyynnölle, esimerkiksi lähetetyille lomaketiedoille. Jos PHP törmää tällöin muistirajaansa, se keskeytyy Out-of-Memory-tilaan. php.netin mukaan näin voi käydä, kun pyyntötiedot on alustettu vasta osittain.

Jokaisen pyynnön lopussa PHP siivoaa ja vapauttaa muistin. Juuri siinä virhe on: siivous voi käsitellä virheellisiä, vain puoliksi luotuja tietoja kelvollisina. Tästä virheellisestä toiminnasta voi tietyin edellytyksin johtaa koodin suorittamisen.

Miksi tällainen virhe on niin vakava? Muistivirhe ohjelmointikielessä koskee kaikkia sen päällä toimivia sovelluksia riippumatta siitä, kuinka huolellisesti ne on ohjelmoitu. Huollettu WordPress-asennus ajantasaisine lisäosineen on yhtä lailla vaarassa kuin vanha oma kehitystyö. Siksi sovelluksen päivitys ei auta, vaan vain PHP:n päivitys.

Muita teknisiä yksityiskohtia hyödyntämisestä emme tietoisesti julkaise. Puolustukseen niitä ei tarvita: ratkaisevaa on, käyttääkö palvelimenne korjattua versiota ja ovatko uudet prosessit todella käynnissä.

Haavoittuvat versiot ja ajotavat

Haavoittuvia ovat ajotavat PHP-FPM, Apache mod_php:n kanssa, php-cgi, FrankenPHP ja LiteSpeed. PHP-tiimi arvioi riskin suurimmaksi mod_php:ssä. Jakelut ja hosting-yritykset asentavat osin backporteja, joten näytetty versionumero on vanhempi, vaikka virhe on korjattu. Ratkaisevia ovat paketin tila ja palveluntarjoajan vahvistus.

Mittakaavasta: Palo Alto Networks (Unit 42) laski yli 22,6 miljoonaa julkisesti tavoitettavissa olevaa, mahdollisesti haavoittuvaa instanssia. BSI on antanut varoitustason 3 (oranssi) ja varautui nopeaan laajamittaiseen hyödyntämiseen.

CVE-2026-109618:n korjaus: päivitys ja uudelleenkäynnistys

Ainoa täydellinen ratkaisu on päivitys. Tarkistakaa ensin versio ja paketin tila. Pakettien nimet vaihtelevat jakelun mukaan; esimerkit lähtevät PHP 8.3:sta:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Jos paketin muutosloki mainitsee CVE-numeron, backport on asennettu. Jos se puuttuu, se ei automaattisesti tarkoita, että paketti on haavoittuva; silloin auttaa vertailu versiotaulukkoon tai kysely palveluntarjoajalta.

Päivityksen jälkeen kaikki PHP-prosessit on käynnistettävä uudelleen, esimerkiksi komennolla systemctl restart php8.3-fpm tai mod_php:n kanssa käynnistämällä Apache uudelleen. Miten varmistatte, ettei vanhoja workereita ole enää käynnissä, kerrotaan sivulla PHP-FPM ja kaikkien workerien uudelleenkäynnistys.

Väliaikaiset toimenpiteet, kun päivitys ei vielä onnistu

php.net on julkaissut PHP2Shellille väliaikaisia toimenpiteitä. Ne koskevat molempia haavoittuvuuksia yhdessä eivätkä nimenomaisesti ole täysi suoja. Se, että useat niistä liittyvät muistirajoihin, sopii CVE-2026-109618:n Out-of-Memory-laukaisijaan; yksittäisten toimenpiteiden virallista kohdentamista yksittäisiin CVE-tunnisteisiin ei kuitenkaan ole.

; Esimerkki FPM-poolista, esim. /etc/php/8.3/fpm/pool.d/www.conf (polku vaihtelee jakelun mukaan)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, jos tarvitaan latauksia
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Arvot on asetettava niin, etteivät sovellukset voi ylikirjoittaa niitä, siksi php_admin_value. Asetuksella memory_limit=-1 palvelu tarvitsee ulkoisen muistirajan kontin tai cgroupin kautta, ei RLIMIT_AS- tai RLIMIT_DATA-rajoilla. PHP 8.5:ssä mukaan tulee fatal_error_backtraces=0. Kaikki yksityiskohdat löytyvät sivulta Pikatoimet, jos ette voi vielä korjata.

Miten PHP SOS auttaa konkreettisesti?

PHP-korjauspalvelumme kautta suljemme CVE-2026-109618:n jäsennellysti:

• Nykytilan kartoitus: PHP-haara, ajotapa, pakettilähde ja backport-tila palvelimittain.
• Päivityksen asennus sopivasta pakettilähteestä tai, jos se ei onnistu, väliaikaisten toimenpiteiden asettaminen siististi poolin tai palvelimen konfiguraatioon.
• Uudelleenkäynnistyksen tarkistus: Varmistamme, ettei vanhoja PHP-prosesseja ole enää käynnissä.
• Todiste: Saatte dokumentaation versioista ja pakettitiloista ennen toimenpidettä ja sen jälkeen, esimerkiksi johdolle, vakuutusyhtiölle tai tietosuojalle.

Usein kysytyt kysymykset

Lähteet

• php.net: tietoturvatiedotteet
• PHP 8 ChangeLog
• BSI: Saksan liittovaltion tietoturvavirasto