PHP kriitilised haavatavused – uuenda kohe (CVE-2026-109618 ja CVE-2026-109619)

1. oktoobril teatas PHP projekt kahest kriitilisest haavatavusest ja turvaväljaandest. 21. oktoobril kell 13.30 UTC avaldati parandused. Mõlemad haavatavused võimaldavad autentimata kaugkoodi käivitamist CVSS-skooriga 9,2 ning avalik proof-of-concept kood ringleb juba.

See ei ole haavatavus, mille planeerite järgmisse hooldusaknasse. See on haavatavus, mille parandate täna.

Lühikokkuvõte

• Uuendage versioonile PHP 8.5.12, 8.4.27, 8.3.36 või 8.2.35.
• Mõjutatud on kogu PHP, mis töötleb veebipäringuid – PHP-FPM, mod_php, php-cgi, FrankenPHP ja LiteSpeed.
• Piisab ühest autentimata päringust, ja see võib tabada enne, kui teie rakenduse kood üldse käivitub.
• PoC-kood on avalik. Arvestage laialdase skaneerimisega tundide, mitte nädalate jooksul.
• Kui te ei saa kohe uuendada: isoleerige internetile avatud teenused, kuni parandus on paigaldatud ja kontrollitud.

Mis juhtus

1. oktoobril teatas PHP projekt, et turvaväljaanne on tulemas. Järgmisel päeval, 21. oktoobril kell 13.30 UTC, avaldati parandused korraga neljas versioonis: 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. CERT-EU andis samal päeval välja turvateate ja kutsus organisatsioone üles kohe uuendama.

See, et parandus tuli kiiresti, on hea. See, et tehniline kirjeldus sai samal ajal avalikuks, tähendab, et aega seisundist „parandus on olemas" seisundini „ründajad proovivad" mõõdetakse tundides.

Mida haavatavused tegelikult teevad

CVE-2026-109618 – mälukorruptsioon mälupiirangul

PHP peatab memory_limit ületava päringu, katkestades selle longjmp() abil. See tähendab, et katkestus võib toimuda keset sisemist operatsiooni, samal ajal kui päringu andmed on ainult osaliselt initsialiseeritud – näiteks vormi failiüleslaadimise parsimise ajal.

Päringu koristamine võib seejärel käsitleda kehtetuid andmeid kehtivatena ja vabastada mälu, mida kunagi ei initsialiseeritud. Selles mälus võivad endiselt olla ründaja kontrollitavad andmed varasematest eraldustest. Tulemuseks on mälukorruptsioon, mis võib viia koodi käivitamiseni.

CVE-2026-109619 – järelejäänud globaalne olek

Ühele päringule kuuluv sisemine olek võib jääda püsima pärast selle mälu vabastamist – näiteks pärast tõsist viga. Hilisem päring, mida töötleb sama tööprotsess, võib seda järelejäänud olekut kasutada enne, kui tavaline initsialiseerimine on jõudnud selle lähtestada.

Kumbki haavatavus ei sõltu seega sellest, et teie rakenduses oleks viga. Need asuvad PHP enda päringutöötluses.

Demonstreeritud exploit näitab, et üks autentimata päring võib rünnaku käivitada enne, kui ükski rakenduse kood jookseb.

Kes on mõjutatud

Kõik PHP paigaldused, mis teenindavad veebiliiklust. PHP meeskond peab mod_php-d kõige kaitsmata konfiguratsiooniks.

• PHP 8.5 enne 8.5.12
• PHP 8.4 enne 8.4.27
• PHP 8.3 enne 8.3.36
• PHP 8.2 enne 8.2.35
• Eluea lõpetanud harud (PHP 8.1 ja vanemad), mis ei saa enam korrapäraseid uuendusi

Lisaks: paljud kommerts- ja avatud lähtekoodiga tooted kasutavad taustal PHP-d. Need võivad olla mõjutatud ka siis, kui te ise PHP paigaldust ei halda. NCSC-NL on avaldanud nimekirja kolmandate osapoolte tarkvarast, millesse PHP on sisse ehitatud.

Kõige tavalisem viga, mida näeme: loendatakse ainult neid servereid, mille ise üles seadsite. Ärge unustage konteinereid, CI-kujutisi, seadmeid, sisemisi tööriistu ja tarnijate hallatavaid teenuseid.

Kontrollige olukorda – viis minutit keskkonna kohta

1. Käivitage php -v igal hostil ja igas konteineris. Mitte ainult ühes.
2. Kaardistage käituskeskkonnad: PHP-FPM-i poolid, Apache koos mod_php-ga, php-cgi, FrankenPHP, LiteSpeed.
3. Ehitage konteineri kujutised uuesti – määrav on baaskujutis, mitte jooksev instants.
4. Küsige tarnijatelt, kes haldavad teie jaoks PHP-st sõltuvaid tooteid: millist versiooni kasutate ja millal olete uuendanud?
5. Leidke eluea lõpetanud harud. PHP 8.1 ja vanemad ei saa korrapäraseid parandusi.

Parandage

Distributsiooni paketid. Linuxi distributsioonidel ja LTS-tarnijatel olid parandused eelnevalt olemas. Uuendage paketihalduri kaudu ja taaskäivitage tööprotsessid.

Konteinerid. Uuendage baaskujutist ja ehitage uuesti. Vana kujutise taaskäivitamine ei lahenda midagi.

Ise kompileeritud. Uuendage versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35.

Eluea lõpetanud versioonid. PHP meeskond on avaldanud minimaalsed backportid versioonidele 7.4, 8.0 ja 8.1 neile, kes ehitavad lähtekoodist või kellel puudub LTS-tarnija. Kui teil on LTS-tarnija: võtke kõigepealt nendega ühendust.

rpms.remirepo.net: see vabatahtlikult hooldatav repositoorium ei saa väljaandmispäeval uuendusi. PHP meeskond kutsub kasutajaid üles liikuma distributsiooni pakettidele või ehitama lähtekoodist.

Taaskäivitage PHP-FPM ja muud tööprotsessid pärast uuendust. Uus binaarfail ilma taaskäivituseta on endiselt vana protsess.

Kui te ei saa täna uuendada

Allolevad meetmed vähendavad kokkupuudet konkreetsete ründeteedega. Need ei muuda paigaldust turvaliseks. Ainult uuendus sulgeb haavatavuse.

CVE-2026-109618 vastu:

• Seadke memory_limit=-1 viisil, mida rakendus ei saa üle kirjutada, näiteks php_admin_value FPM-i poolis või Apache konfiguratsioonis. Kontrollige, et ükski pool, kataloog ega rakenduse seade ei pane piirangut tagasi.
• Seadke madal post_max_size: 8M rakendustele ilma failiüleslaadimiseta, 32M seal, kus üleslaadimine on vajalik. Hoidke upload_max_filesize väiksem kui post_max_size.
• Seadke veebiserveris või puhverserveris piirangud dekodeeritud päringu suurusele, väljade arvule, multipart-osade arvule, päiste arvule ja pesastussügavusele. Piirangud peavad katma ka päringud, millel puudub kasutatav Content-Length.
• Kasutage konteineri või cgroupi mälupiirangut kättesaadavuse piiranguna, eelistatavalt poliitikaga, mis tapab ainult kannatanud tööprotsessi. Ärge kasutage RLIMIT_AS-i ega RLIMIT_DATA-t – need võivad käivitada haavatava eraldustee.

CVE-2026-109619 vastu:

• Seadke session.upload_progress.enabled=0 ja taaskäivitage iga tööprotsess. Seadke see php.ini-s, FPM-i poolis või serveri konfiguratsioonis nii, et see kehtib enne päringu parsimist. Ärge lootke ini_set()-ile ega FPM-i .user.ini-le.
• PHP 8.5 puhul: seadke fatal_error_backtraces=0 ja taaskäivitage iga tööprotsess.
• Eemaldage kehtetud või aegunud päringupõhised seaded, mis väljastavad diagnostikat enne initsialiseerimist. Diagnostika peitmine error_reporting-, display_errors- või @-ga ei aita.
• Parandage tõsised vead ja täitmise ajalimiidid, milleni ründaja võib jõuda – callbackides, üleslaadimises, impordis ja koristamises.

Miks ei tasu oodata

Kolm asja eristavad seda sündmust tavalisest uuendusest:

1. Autentimist ei nõuta. Pole sisselogimist, mille taha peituda.
2. Rünnak toimub enne teie koodi. Rakendusloogika, WAF-i reeglid ja õiguste mudel ei ole siin kaitsebarjäär.
3. PoC on juba väljas. See, mis tavaliselt võtab nädalaid, on juba kellegi teise poolt ära tehtud.

Uuenduse ja taaskäivituse hind täna on tühine võrreldes sissetungi hinnaga. See kehtib eriti siis, kui teid hõlmab NIS2, mille kohaselt tuleb olulisest intsidendist teatada 24 tunni jooksul.

Pärast uuendust – kolm asja

1. Kontrollige igal sõlmel. Versioon – mitte ainult see, et paketihaldur ütles OK.
2. Lugege logisid tagurpidi. Multipart-POST-id, ootamatud 500-vastused, kokku jooksnud tööprotsessid ja tundmatutest allikatest pärit liiklus viimastel päevadel.
3. Väiksemagi kahtluse korral: käivitage intsidendiprotseduur. Isoleerige, kindlustage logid, hinnake, kas teavitamine on vajalik.

Allikad

• CERT-EU, Security Advisory 2026-018: https://cert.europa.eu/publications/security-advisories/2026-018/
• PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35: https://www.php.net/
• GHSA-w8hw-w9fx-j79w: https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
• GHSA-6wmf-4rv5-p3rp: https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
• NCSC-NL, nimekiri toodetest, millesse on PHP sisse ehitatud: https://github.com/NCSC-NL/php2shell

---

Sellised haavatavused on iseenesest argument pideva turvalisuse poolt: uuendused, kontroll ja seire, mis toimuvad kogu aeg – mitte aastane ülevaatus. Loe lähemalt, mida pidev küberturvalisus praktikas tähendab.