Kritinės PHP spragos (CVE-2026-109618 ir CVE-2026-109619): kas nutiko ir ką daryti

2026 m. spalio 21 d. PHP projektas išleido dviejų kritinių klaidų pataisas, o CERT-EU tą pačią dieną paskelbė saugos pranešimą 2026-018. Abi klaidos įvertintos 9,2 balo ir abi apibūdinamos kaip nuotolinis kodo vykdymas be autentifikavimo. Jei naudojate „WordPress“ svetainę, parduotuvę ar kitą PHP programą, tai liečia ir Jus, o sprendimas yra atnaujinimas, ne nustatymas. Šiame straipsnyje paaiškiname, kas žinoma, kaip ataka patenka vidun ir ką daryti. Būklė: 2026 m. spalio 22 d., remiantis CERT-EU pranešimo 1.1 versija.

Kas nutiko

PHP spalio 20 d. paskelbė saugos išleidimą, o pataisas išleido spalio 21 d. 13:30 UTC. CERT-EU savo pranešimą pavadino „Critical Vulnerabilities in PHP“ ir nurodo du CVE: CVE-2026-109618 ir CVE-2026-109619, kurių kiekvienos įvertis 9,2. CERT-EU taip pat rašo, kad techninės detalės dabar aptariamos viešai ir pradėjo plisti pirmasis koncepcijos įrodymo kodas (angl. proof of concept). Pranešime atakų realiame pasaulyje nepatvirtinama, tačiau teigiama, kad dėl to labiau tikėtina, jog užpuolikai šias klaidas jau išnaudoja. Traktuokite tai kaip skubų atvejį.

Ko tai liečia

Pažeidžiamas kiekvienas PHP leidimas, senesnis už pataisytą palaikomos šakos versiją, ir visos šakos, kurių palaikymas baigėsi.

CERT-EU mini PHP-FPM, Apache su mod_php, php-cgi, FrankenPHP ir LiteSpeed. Pasak PHP komandos, didžiausia rizika kyla mod_php. Pažeidžiami gali būti ir produktai, kurie PHP įtraukia į save; CERT-EU nurodo Nyderlandų NCSC sąrašą šio straipsnio pabaigoje. Svarbi kiekviena diegtis, aptarnaujanti žiniatinklio užklausas, nesvarbu, ar joje yra įkėlimo forma.

Kaip užpuolikas pasiekia pirmąją klaidą

Prisijungti niekam nereikia. Pasak CERT-EU, parodytas išnaudojimas rodo, kad vienas neautentifikuotas užklausimas gali sukelti ataką dar prieš pradedant vykdyti bet kokį programos kodą. Būtent tą dalį dauguma praleidžia: nesvarbu, ar Jūsų „WordPress“ naujausias, ar Jūsų papildiniai užlopyti, ar Jūsų kontaktų forma apsaugota. Užklausa pirmiausia pasiekia PHP variklį.

Pirmoji klaida, CVE-2026-109618, veikia taip:

1. Užklausa ateina adresu, kurį aptarnauja PHP. Jokio prisijungimo, jokios paskyros.
2. PHP pradeda skaityti užklausos turinį. CERT-EU kaip pavyzdį mini formomis siunčiamų failų įkėlimų apdorojimą.
3. PHP savo memory_limit užtikrina naudodamas longjmp(). Kai riba viršijama, jis iššoka iš to, ką darė, ir baigia užklausą.
4. Jei tai nutinka vidury vidinių užklausos duomenų kūrimo, tie duomenys lieka tik iš dalies sukurti.
5. Vėlesnis valymas neteisingus duomenis laiko teisingais ir atlaisvina atmintį, kuri niekada nebuvo inicializuota. Toje atmintyje dar gali būti ankstesnių paskirstymų duomenų, kuriuos valdė užpuolikas.
6. Toliau pranešime aprašomas nuotolinis kodo vykdymas serveryje.

Mes sąmoningai neaprašome, kaip užpuolikas valdo paskutinį žingsnį. Pakanka žinoti, kad įėjimo taškas nėra Jūsų programa, todėl nieko Jūsų programos viduje nepavyksta jo sustabdyti.

Antroji klaida: būsena, išgyvenanti savo atmintį

CVE-2026-109619 yra kitoks mechanizmas su tuo pačiu rezultatu. PHP kiekvienai užklausai laiko vidinę būseną. Po tam tikrų gedimų, pavyzdžiui, lemtingos klaidos, ši būsena gali likti, nors po ja esanti atmintis jau atlaisvinta. Kita to paties darbinio proceso užklausa gali panaudoti šią pasenusią būseną, kol ji dar nebuvo įprastai atstatyta. Užpuolikui reikia dviejų užklausų, patekusių į tą patį darbinį procesą; CERT-EU rezultatą vertina taip pat kaip pirmosios klaidos: nuotolinis kodo vykdymas.

Ką daryti šiandien

1. Išsiaiškinkite, kokia PHP versija iš tikrųjų aptarnauja Jūsų svetainę. php -v komandinėje eilutėje rodo komandinės eilutės versiją, kuri gali skirtis nuo tos, kurią naudoja Jūsų žiniatinklio serveris. Patikrinkite php-fpm -v, savo prieglobos valdymo skydelį arba puslapį, kuris iškviečia phpinfo(). Bendrojoje prieglobos paslaugoje paklauskite teikėjo.
2. Atnaujinkite į pataisytą versiją: 8.5.12, 8.4.27, 8.3.36 arba 8.2.35. Platinimai pataisas dažnai perkelia atgal nekeisdami versijos numerio, todėl savo tiekėjo saugos pranešime ieškokite CVE numerių. Konteineriuose perkurkite iš atnaujinto bazinio atvaizdo. PHP komanda pažymi, kad rpms.remirepo.net išleidimo dieną atnaujinimų neturėjo, ir rekomenduoja platinimo paketus arba kūrimą iš šaltinio kodo.
3. Paleiskite iš naujo visus PHP darbinius procesus. Atnaujinimas diske jau veikiančių procesų nepakeičia. Paleiskite iš naujo PHP-FPM arba žiniatinklio serverį, tada dar kartą patikrinkite veikiančią versiją.
4. Jei šiandien atnaujinti negalite, izoliuokite serverį nuo viešųjų tinklų, kol pataisa bus įdiegta ir patikrinta. CERT-EU aiškiai nurodo, kad šias klaidas visiškai pašalina tik atnaujinimas.
5. Jei naudojate PHP 8.1 ar senesnę versiją, paprašykite tiekėjo atgalinio perkėlimo arba pereikite prie palaikomos šakos. Šios versijos įprastų atnaujinimų negauna.

Apėjimo būdai, kurie sumažina riziką, bet jos nepašalina

CERT-EU išvardija priemones, apsunkinančias ataką. Jis aiškiai nurodo, kad jos diegties nepadaro saugios. Naudokite jas rengdamiesi atnaujinimui, o ne vietoje jo.

• Prieš CVE-2026-109618: nustatykite memory_limit=-1 taip, kad programos jo negalėtų pakeisti, pavyzdžiui, naudodami php_admin_value FPM telkinyje, ir patikrinkite, kad joks telkinys, katalogas ar programos įrašas vėl nenustatytų baigtinės ribos. Nustatykite mažą post_max_size (8M be įkėlimų, 32M su įkėlimais) ir laikykite upload_max_filesize žemiau jo. Apribokite užklausos dydį, laukų skaičių, daugiadalių užklausų dalių skaičių, antraščių skaičių ir įdėjimo gylį žiniatinklio serveryje ar tarpiniame serveryje. Konteinerio arba cgroup atminties ribą naudokite kaip prieinamumo ribą, bet ne RLIMIT_AS ar RLIMIT_DATA, kurie gali sukelti pažeidžiamą atminties paskirstymo gedimą.
• Prieš CVE-2026-109619: nustatykite session.upload_progress.enabled=0 faile php.ini, FPM telkinyje arba serverio konfigūracijoje, kuri taikoma prieš apdorojant užklausą (ne per ini_set() ar .user.ini), ir paleiskite iš naujo visus darbinius procesus. PHP 8.5 papildomai nustatykite fatal_error_backtraces=0. Pašalinkite neteisingus ar pasenusius kiekvienos užklausos nustatymus, kurie išveda diagnostiką prieš inicializavimą, ir ištaisykite lemtingas klaidas bei vykdymo laiko limitus, kuriuos gali pasiekti užpuolikas.

Ką SilentShield čia gali ir ko negali

Tai nėra botų problema, ir mieliau tai pasakome, nei leidžiame produkto puslapiui to nuspėti. Ataka smogia PHP varikliui anksčiau, nei užklausą pamato bet kas iš mūsų pusės ar bet koks CAPTCHA, papildinys ar ugniasienės taisyklė Jūsų programos viduje. Formos apsauga nuo botų jos nesustabdo, ir niekas neturėtų Jums teigti priešingai. Vienintelis visiškas sprendimas yra PHP atnaujinimas.

SilentShield API ir valdymo skydas nėra parašyti PHP. „WordPress“ papildinys ir PHP SDK veikia Jūsų pačių PHP, todėl jiems atnaujinimą reikia atlikti Jūsų serveryje. Kai atnaujinsite, įprasta apsauga nuo botų ir formų šlamšto bus tiek pat naudinga kaip anksčiau; ji tiesiog niekada nebuvo atsakymas į šią problemą.

Šaltiniai

• CERT-EU saugos pranešimas 2026-018: Critical Vulnerabilities in PHP
• PHP pranešimas, 2026 m. spalio 20 d.
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produktai, įtraukiantys PHP