Lühidalt: CVE-2026-109619 on teine PHP2Shelli taga olev turvaauk. Päringuga seotud sisemine seisund võib pärast mälu vabastamist alles jääda; hilisem päring samas tööprotsessis saab seda kasutada, enne kui see lähtestatakse. Tagajärg on koodi käivitamine ilma sisselogimata. Abinõu: uuendus versioonile PHP 8.5.12, 8.4.27, 8.3.36 või 8.2.35 ja kõigi tööprotsesside taaskäivitus.
Mis on CVE-2026-109619?
CVE-2026-109619 (GitHubi tähis GHSA-6wmf-4rv5-p3rp) on hinnatud CVSS v4.0 järgi 9,2. Koos CVE-2026-109618-ga moodustab see PHP2Shelli. Mõlemad turvaaugud asuvad PHP-s endas, mitte rakenduses.
Mõju on sama mis õdede turvaaugul: ründaja saab kaugelt, ilma paroolita ja ilma kasutajakontota serveris koodi käivitada. Põhjus on aga teine.
Miks tööprotsessi aegunud seisund on ohtlik
PHP veebiserver ei käivita iga päringu jaoks uut protsessi. PHP-FPM-i, Apache'i koos mod_php-ga, LiteSpeedi või FrankenPHP puhul töötleb üks tööprotsess järjest paljusid päringuid. Kahe päringu vahel lähtestab PHP oma sisemise seisundi, et päringust A ei satuks midagi päringusse B.
CVE-2026-109619 puhul see lähtestamine täielikult ei õnnestu. php.net-i järgi võib päringuga seotud sisemine seisund pärast mälu vabastamist alles jääda. Hilisem päring samas tööprotsessis saab seda aegunud seisundit kasutada, enne kui see lähtestatakse. Lihtsustatult: taaskasutatakse midagi, mis tegelikult enam ei kehti.
Töö seisukohast on see tähelepanuväärne. Tööprotsesside taaskasutus on tahtlik, sest see teeb veebiserveri kiireks: tööprotsessi ei pea iga päringu jaoks uuesti käivitama, laiendusi laadima ja mälu looma. Turvaauk tabab seega omadust, mis on praktiliselt igas tootmises PHP paigalduses. php.net ei nimeta seadistust, mis probleemi täielikult väldib; seetõttu kulgeb tee uuenduse kaudu.
Üksikasju ekspluateerimise kohta me ei avalda. Haldajale loeb: tähelepanu all tuleb hoida iga töörežiimi, kus tööprotsessid teenindavad mitut päringut, ja just need töörežiimid on tavalised.
Kaks PHP2Shelli turvaauku võrdluses
| Tunnus | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHubi tähis | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Hinnang | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Käivitaja | mälupuudus (Out-of-Memory) päringuandmete lähtestamise ajal | sisemine seisund jääb pärast vabastamist alles |
| Mõju | koodi käivitamine ilma sisselogimata | koodi käivitamine ilma sisselogimata |
| Parandatud versioonides | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |
Mõjutatud on PHP-FPM, Apache koos mod_php-ga, php-cgi, FrankenPHP ja LiteSpeed. Suurimat riski näeb PHP meeskond mod_php puhul; miks, selgitame lehel Miks mod_php kannab suurimat riski.
CVE-2026-109619 sulgemine: uuendus, siis kõigi tööprotsesside taaskäivitus
Just selle turvaaugu puhul on taaskäivitus otsustav. Kuni vanad tööprotsessid mälus töötavad, jätkab server vigase koodiga, ka siis, kui uued failid on ammu kettal.
Kontrollige versiooni ja paketi seisu. Paketinimed erinevad distributsiooniti ja majutaja liidesest:
php -v
php-fpm8.3 -v # FPM-i binaarfailil võib olla teine versioon kui CLI-l
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL-i perekond
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
Seejärel käivitage kõik mõjutatud teenused uuesti:
sudo systemctl restart php8.3-fpm # iga paigaldatud PHP versiooni kohta
sudo systemctl restart apache2 # mod_php puhul; RHEL-is on teenuse nimi httpd
Kui teie distributsioon või veebimajutaja paigaldab tagasiportimise, võib kuvatav versiooninumber jääda samaks. Siis loevad paketi muudatuslogi ja pakkuja kirjalik kinnitus. Samm-sammulise kontrolli leiate lehelt PHP-FPM-i ja kõigi tööprotsesside taaskäivitus.
Märkige üles taaskäivituse kuupäev ja kellaaeg. Hilisemaks hinnanguks, kas rünnak toimus enne või pärast paika, on see ajahetk kõige olulisem võrdluspunkt.
Mis jääb pärast paika veel teha
Paik ei tõesta, et varem midagi ei juhtunud. Meediateadete kohaselt täheldati esimest ründekatset 17. oktoobril, neli päeva enne paike. Hoidke serveri logid alles alates 20. oktoobrist, nagu erialaajakirjandus soovitab, ja kontrollige serverit kõrvalekallete suhtes. Näpunäiteid annab lehekülg Kas ma olen juba kompromiteeritud?.
Mõelge seejuures ulatusele: eduka koodi käivitamise korral on ründajal PHP protsessi õigused. Ta saab lugeda seda, mida rakendus tohib lugeda, näiteks seadistusfailid andmebaasi ligipääsude või API võtmetega. Kui intsident leiab kinnitust, tuleb need ligipääsuandmed pärast puhastamist uuendada.
Kuidas PHP SOS konkreetselt aitab?
PHP paikamisteenusega viime parandused ellu jälgitavalt:
- Kaardistamine: millised PHP versioonid ja töörežiimid millises serveris töötavad ja milline paketiallikas neid pakub?
- Paikamine: uuendus õigest allikast või ajutised meetmed php.net-i järgi, kus uuendus on veel blokeeritud.
- Taaskäivituse kontroll: kontrollime protsess protsessi haaval, et töötab ainult parandatud versioon.
- Dokumenteerimine: versioonid, paketi seisud ja taaskäivituse ajahetked, et saaksite seisu tõendada.
Korduma kippuvad küsimused
Mille poolest erineb CVE-2026-109619 turvaaugust CVE-2026-109618?
CVE-2026-109618 tekib siis, kui mälupuuduse (Out-of-Memory) seisund katkestab päringu keset lähtestamist. CVE-2026-109619 puudutab seisundit, mis jääb pärast päringu lõppu tööprotsessi alles. Mõlemad viivad koodi käivitamiseni ilma sisselogimata ja on parandatud samades PHP versioonides.
Kas aitab PHP-FPM-i tööprotsesside sagedasem taaskäivitus?
Uuenduse asendajaks see ei sobi. php.net ei nimeta tööprotsesside sagedasemat taaskäivitust ajutise meetmena. Tööprotsessid tuleb aga pärast uuendust uuesti käivitada, et parandatud versioon üldse töötaks.
Kas CMS-i uuendus kaitseb mind CVE-2026-109619 eest?
Ei. Turvaauk asub PHP-s, mitte WordPressis, Shopware'is, TYPO3-s ega muus süsteemis. Selle sulgeb ainult PHP uuendus või pakkuja kinnitatud tagasiportimine.
Kas on teada rünnaku jälgi CVE-2026-109619 kaudu?
Kinnitatud kompromiteerimisnäitajaid (Indicators of Compromise) pole seni avaldatud. Tuvastamine põhineb käitumisanalüüsil, näiteks uutel PHP failidel, ebatavalistel väljaminevatel ühendustel või tundmatutel cron-töödel.