Kritinės PHP pažeidžiamybės – atnaujinkite dabar (CVE-2026-109618 ir CVE-2026-109619)

Spalio 20 d. PHP projektas paskelbė apie saugos leidimą dėl dviejų kritinių pažeidžiamybių. Spalio 21 d. 13.30 UTC pataisymai buvo išleisti. Abi pažeidžiamybės leidžia neautentifikuotą nuotolinį kodo vykdymą su CVSS 9,2, o viešas proof-of-concept kodas jau cirkuliuoja.

Tai ne pažeidžiamybė, kurią planuojate kitam techninės priežiūros langui. Tai pažeidžiamybė, kurią ištaisote šiandien.

Trumpai

• Atnaujinkite į PHP 8.5.12, 8.4.27, 8.3.36 arba 8.2.35.
• Paveiktas visas PHP, kuris apdoroja žiniatinklio užklausas – PHP-FPM, mod_php, php-cgi, FrankenPHP ir LiteSpeed.
• Gali pakakti vienos neautentifikuotos užklausos, ir ji gali suveikti dar prieš paleidžiant jūsų programos kodą.
• PoC kodas yra viešas. Tikitės plataus skenavimo per valandas, o ne savaites.
• Jei negalite pataisyti iš karto: izoliuokite internetui atvirus servisus, kol pataisymas bus įdiegtas ir patvirtintas.

Kas nutiko

Spalio 20 d. PHP projektas pranešė, kad ruošiamas saugos leidimas. Kitą dieną, spalio 21 d. 13.30 UTC, pataisymai buvo paskelbti keturiose versijose vienu metu: 8.5.12, 8.4.27, 8.3.36 ir 8.2.35. CERT-EU tą pačią dieną išleido saugos įspėjimą ir paragino organizacijas nedelsiant atnaujinti.

Tai, kad pataisymas pasirodė greitai, yra gerai. Tai, kad techninis aprašymas tuo pačiu metu tapo viešas, reiškia, kad laikas nuo „pataisymas yra“ iki „užpuolikai bando“ matuojamas valandomis.

Ką pažeidžiamybės iš tikrųjų daro

CVE-2026-109618 – atminties korupcija ties atminties riba

PHP sustabdo užklausą, kuri viršija memory_limit, nutraukdamas ją su longjmp(). Tai reiškia, kad nutraukimas gali įvykti viduryje vidinės operacijos, kai užklausos duomenys dar tik iš dalies inicializuoti – pavyzdžiui, analizuojant failo įkėlimą formoje.

Tada užklausos valymas gali traktuoti netinkamus duomenis kaip tinkamus ir atlaisvinti atmintį, kuri niekada nebuvo inicializuota. Toje atmintyje gali likti duomenų iš ankstesnių paskyrimų, kuriuos kontroliuoja užpuolikas. Rezultatas – atminties korupcija, galinti sukelti kodo vykdymą.

CVE-2026-109619 – likęs globalus būvis

Vienai užklausai priklausantis vidinis būvis gali išlikti po to, kai jo atmintis atlaisvinama – pavyzdžiui, po kritinės klaidos. Vėlesnė užklausa, kurią apdoroja tas pats darbinis procesas, gali naudoti tą likusį būvį, kol normali inicializacija dar nespėjo jo atstatyti.

Taigi nė viena pažeidžiamybė nepriklauso nuo to, ar jūsų programa turi klaidą. Jos yra pačiame PHP užklausų apdorojime.

Demonstruotas exploit rodo, kad viena neautentifikuota užklausa gali suaktyvinti ataką prieš paleidžiant bet kokį programos kodą.

Kas paveikta

Visos PHP instaliacijos, kurios aptarnauja žiniatinklio srautą. PHP komanda laiko mod_php labiausiai pažeidžiama konfigūracija.

• PHP 8.5 iki 8.5.12
• PHP 8.4 iki 8.4.27
• PHP 8.3 iki 8.3.36
• PHP 8.2 iki 8.2.35
• Pasibaigusios šakos (PHP 8.1 ir senesnės), kurios negauna reguliarių atnaujinimų

Be to: daugelis komercinių ir atvirojo kodo produktų naudoja PHP savo viduje. Jie gali būti paveikti, net jei patys neadministruojate PHP instaliacijos. NCSC-NL paskelbė trečiųjų šalių programinės įrangos, kurioje įdiegtas PHP, sąrašą.

Dažniausia klaida, kurią matome: skaičiuojami tik tie serveriai, kuriuos įrengėte patys. Nepamirškite konteinerių, CI atvaizdų, įrenginių, vidinių įrankių ir tiekėjų valdomų paslaugų.

Patikrinkite situaciją – penkios minutės vienai aplinkai

1. Paleiskite php -v kiekviename hoste ir kiekviename konteineryje. Ne tik viename.
2. Surašykite vykdymo aplinkas: PHP-FPM baseinai, Apache su mod_php, php-cgi, FrankenPHP, LiteSpeed.
3. Perstatykite konteinerių atvaizdus – svarbus bazinis atvaizdas, o ne veikiantis egzempliorius.
4. Klauskite tiekėjų, kurie jums valdo nuo PHP priklausančius produktus: kokią versiją naudojate ir kada būsite atnaujinę?
5. Raskite pasibaigusias šakas. PHP 8.1 ir senesnės negauna reguliarių pataisymų.

Ištaisykite

Distribucijų paketai. Linux distribucijos ir LTS tiekėjai pataisymus turėjo iš anksto. Atnaujinkite per paketų tvarkyklę ir paleiskite darbinius procesus iš naujo.

Konteinerių atvaizdai. Atnaujinkite bazinį atvaizdą ir perstatykite. Seno atvaizdo paleidimas iš naujo nieko neišsprendžia.

Savarankiškai kompiliuota. Atnaujinkite į 8.5.12, 8.4.27, 8.3.36 arba 8.2.35.

Pasibaigusios versijos. PHP komanda paskelbė minimalius backportus 7.4, 8.0 ir 8.1 versijoms tiems, kurie kompiliuoja iš šaltinio arba neturi LTS tiekėjo. Jei turite LTS tiekėją: pirmiausia susisiekite su juo.

rpms.remirepo.net: ši savanorių prižiūrima saugykla leidimo dieną negauna atnaujinimų. PHP komanda ragina naudotojus pereiti prie distribucijos paketų arba kompiliuoti iš šaltinio.

Po atnaujinimo paleiskite PHP-FPM ir kitus darbinius procesus iš naujo. Naujas dvejetainis failas be paleidimo iš naujo vis dar yra senas procesas.

Jei negalite pataisyti šiandien

Toliau pateiktos priemonės sumažina paveikumą konkretiems atakos keliams. Jos nepadaro instaliacijos saugios. Tik atnaujinimas uždaro pažeidžiamybę.

Prieš CVE-2026-109618:

• Nustatykite memory_limit=-1 taip, kad programa negalėtų to perrašyti, pavyzdžiui, php_admin_value FPM baseine arba Apache konfigūracijoje. Patikrinkite, ar joks baseinas, katalogas ar programos nustatymas negrąžina ribos.
• Nustatykite mažą post_max_size: 8M programoms be failų įkėlimo, 32M ten, kur įkėlimas būtinas. Laikykite upload_max_filesize mažesnį už post_max_size.
• Nustatykite žiniatinklio serverio arba proxy ribas iššifruotos užklausos dydžiui, laukų skaičiui, multipart dalių skaičiui, antraščių skaičiui ir įdėjimo gyliui. Ribos turi apimti ir užklausas be tinkamos Content-Length.
• Naudokite konteinerio arba cgroup atminties ribą kaip prieinamumo ribą, pageidautina su politika, kuri nužudo tik paveiktą darbinį procesą. Nenaudokite RLIMIT_AS ar RLIMIT_DATA – jie gali suaktyvinti pažeidžiamą paskyrimo kelią.

Prieš CVE-2026-109619:

• Nustatykite session.upload_progress.enabled=0 ir paleiskite kiekvieną darbinį procesą iš naujo. Nustatykite tai php.ini, FPM baseine arba serverio konfigūracijoje, kad galiotų prieš užklausos analizę. Nepasikliaukite ini_set() ar FPM .user.ini.
• PHP 8.5 atveju: nustatykite fatal_error_backtraces=0 ir paleiskite kiekvieną darbinį procesą iš naujo.
• Pašalinkite netinkamus ar pasenusius užklausos lygio nustatymus, kurie išveda diagnostiką prieš inicializaciją. Diagnostikos slėpimas su error_reporting, display_errors ar @ nepadeda.
• Ištaisykite kritines klaidas ir vykdymo laiko ribas, kurias užpuolikas gali pasiekti – callback funkcijose, įkėlime, importe ir valyme.

Kodėl nereikia laukti

Trys dalykai skiria šį įvykį nuo įprasto pataisymo:

1. Autentifikacija nereikalinga. Nėra prisijungimo, už kurio pasislėpti.
2. Ataka vyksta prieš jūsų kodą. Programos logika, WAF taisyklės ir teisių modelis čia nėra apsaugos barjeras.
3. PoC jau viešas. Tai, kas paprastai trunka savaites, jau padarė kažkas kitas.

Pataisymo ir paleidimo iš naujo kaina šiandien yra nereikšminga, palyginti su įsibrovimo kaina. Tai ypač aktualu, jei jus apima NIS2, pagal kurį apie reikšmingą incidentą reikia pranešti per 24 valandas.

Po pataisymo – trys dalykai

1. Patikrinkite kiekviename mazge. Versiją – ne tik tai, kad paketų tvarkyklė pranešė OK.
2. Skaitykite žurnalus atgal. Multipart POST užklausos, netikėti 500 atsakymai, nulūžę darbiniai procesai ir srautas iš nežinomų šaltinių per pastarąsias dienas.
3. Esant menkiausiam įtarimui: paleiskite incidento procedūrą. Izoliuokite, užtikrinkite žurnalus, įvertinkite, ar reikia pranešti.

Šaltiniai

• 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, produktų su įdiegtu PHP sąrašas: https://github.com/NCSC-NL/php2shell

---

Tokios pažeidžiamybės yra pats argumentas už nuolatinį saugumą: atnaujinimai, tikrinimas ir stebėjimas, kurie vyksta visą laiką – o ne metinė apžvalga. Plačiau apie tai, ką nuolatinis saugumas reiškia praktiškai.