Kriitilised PHP haavatavused (CVE-2026-109618 ja CVE-2026-109619): mis juhtus ja mida teha

21. oktoobril 2026 avaldas PHP projekt parandused kahele kriitilisele veale ning CERT-EU avaldas samal päeval turvateate 2026-018. Mõlema hinnang on 9,2 ja mõlemat kirjeldatakse koodi kaugkäivitusena ilma autentimiseta. Kui kasutate WordPressi saiti, e-poodi või mõnda muud PHP-rakendust, puudutab see Teid ning lahenduseks on uuendus, mitte seadistus. See artikkel selgitab, mis on teada, kuidas rünnak sisse pääseb ja mida teha. Seis: 22. oktoober 2026, CERT-EU turvateate versiooni 1.1 põhjal.

Mis juhtus

PHP teatas turvaväljalaskest 20. oktoobril ja avaldas parandused 21. oktoobril kell 13:30 UTC. CERT-EU nimetas oma turvateate „Critical Vulnerabilities in PHP“ ja loetleb kaks CVE-d: CVE-2026-109618 ja CVE-2026-109619, mõlemal hinnang 9,2. CERT-EU kirjutab ka, et tehnilisi üksikasju arutatakse nüüd avalikult ja esimene näidisrünnakukood (proof of concept) on hakanud levima. Turvateade ei kinnita rünnakuid päris keskkonnas, kuid märgib, et see muudab tõenäolisemaks, et ründajad kasutavad vigu juba ära. Käsitlege seda kiireloomulisena.

Keda see puudutab

Ohustatud on iga PHP väljalase, mis on toetatud haru parandatud versioonist vanem, ning kõik elutsükli lõppu jõudnud harud.

CERT-EU nimetab PHP-FPM-i, Apache’it koos mod_php-ga,php-cgi, FrankenPHP-d ja LiteSpeedi. PHP meeskonna sõnul on suurim risk mod_php-l. Ohustatud võivad olla ka tooted, mis PHP-d endasse põimivad; CERT-EU viitab Hollandi NCSC loetelule selle artikli lõpus. Arvesse läheb iga paigaldus, mis teenindab veebipäringuid, olenemata sellest, kas sellel on üleslaadimisvorm.

Kuidas ründaja esimese veani jõuab

Keegi ei pea sisse logima. CERT-EU andmetel näitab demonstreeritud ärakasutamine, et üks autentimata päring võib käivitada rünnaku enne, kui jõuab tööle ükski rakenduse kood. See on punkt, mille enamik jätab märkamata: pole vahet, kas Teie WordPress on ajakohane, kas Teie pluginad on paigatud või kas Teie kontaktivorm on kaitstud. Päring jõuab esmalt PHP mootorini.

Esimene viga, CVE-2026-109618, toimib nii:

1. Päring saabub aadressile, mida PHP teenindab. Ei mingit sisselogimist ega kontot.
2. PHP hakkab päringu keha lugema. CERT-EU nimetab näitena vormipõhiste failiüleslaadimiste töötlemist.
3. PHP jõustab oma memory_limit-i funktsiooniga longjmp(). Kui piir ületatakse, hüppab PHP pooleliolevast tegevusest välja ja lõpetab päringu.
4. Kui see juhtub päringu sisemiste andmete ülesseadmise keskel, jääb see andmestik pooleldi ehitatuks.
5. Järgnev koristus peab kehtetuid andmeid kehtivaks ja vabastab mälu, mida ei olnud kunagi lähtestatud. Selles mälus võivad veel olla varasemate eraldustega jäänud andmed, mida ründaja kontrollis.
6. Sealt edasi kirjeldab turvateade koodi kaugkäivitust serveris.

Me ei kirjelda tahtlikult, kuidas ründaja viimast sammu juhib. Piisab teadmisest, et sisenemispunkt ei ole Teie rakendus, ja just sellepärast ei saa miski Teie rakenduse sees seda peatada.

Teine viga: olek, mis elab mälust kauem

CVE-2026-109619 on teistsugune mehhanism sama tulemusega. PHP hoiab iga päringu jaoks sisemist olekut. Pärast teatud tõrkeid, näiteks saatuslikku viga, võib see olek alles jääda, kuigi selle all olev mälu on vabastatud. Sama töötaja järgmine päring võib seda iganenud olekut kasutada enne, kui see tavapäraselt lähtestatakse. Ründaja vajab kahte päringut, mis satuvad samale töötajale; CERT-EU hindab tulemuse samaks nagu esimese vea puhul: koodi kaugkäivitus.

Mida täna teha

1. Selgitage välja, millist PHP versiooni Teie sait tegelikult kasutab. php -v käsureal näitab käsurea versiooni, mis võib erineda veebiserveri kasutatavast. Kontrollige php-fpm -v, oma majutuse haldusliidest või lehte, mis kutsub välja phpinfo(). Jagatud majutuse puhul küsige teenusepakkujalt.
2. Uuendage parandatud versioonile: 8.5.12, 8.4.27, 8.3.36 või 8.2.35. Distributsioonid portivad parandusi sageli tagasi, muutmata versiooninumbrit, seega otsige oma tarnija turvateatest CVE-numbreid. Konteinerite puhul ehitage uuesti uuendatud baaspildilt. PHP meeskond märgib, et rpms.remirepo.net-il ei olnud väljalaskepäeval uuendusi, ning soovitab distributsiooni pakette või ehitamist lähtekoodist.
3. Taaskäivitage kõik PHP töötajad. Uuendus kettal ei muuda juba töötavaid protsesse. Taaskäivitage PHP-FPM või veebiserver ja kontrollige seejärel töötavat versiooni uuesti.
4. Kui te ei saa täna uuendada, eraldage server avalikest võrkudest, kuni parandus on paigaldatud ja kontrollitud. CERT-EU on selge, et need vead parandab täielikult ainult uuendus.
5. Kui kasutate PHP 8.1 või vanemat, küsige tarnijalt tagasiportimist või minge üle toetatud harule. Need versioonid regulaarseid uuendusi ei saa.

Lahendused, mis vähendavad riski, kuid viga ei paranda

CERT-EU loetleb meetmed, mis muudavad rünnaku raskemaks. Ta ütleb selgelt, et need ei muuda paigaldust turvaliseks. Kasutage neid uuenduse ettevalmistamise ajal, mitte selle asemel.

• CVE-2026-109618 vastu: seadke memory_limit=-1 nii, et rakendused seda üle kirjutada ei saa, näiteks php_admin_value abil FPM-i kogumis, ning kontrollige, et ükski kogum, kataloog ega rakenduse kirje ei seaks uuesti lõplikku piiri. Seadke madal post_max_size (8M ilma üleslaadimisteta, 32M üleslaadimistega) ja hoidke upload_max_filesize sellest allpool. Piirake päringu suurust, väljade arvu, mitmeosaliste päringute osade arvu, päisete arvu ja pesastussügavust veebiserveris või puhverserveris. Kasutage konteineri või cgroupi mälupiiri kättesaadavuse piirina, kuid mitte RLIMIT_AS ega RLIMIT_DATA, mis võivad esile kutsuda haavatava mälueraldustõrke.
• CVE-2026-109619 vastu: seadke session.upload_progress.enabled=0 failis php.ini, FPM-i kogumis või serveri seadistuses, mis kehtib enne päringu töötlemist (mitte ini_set() ega .user.ini abil), ja taaskäivitage kõik töötajad. PHP 8.5-l seadke lisaks fatal_error_backtraces=0. Eemaldage kehtetud või vananenud päringukohased seadistused, mis väljastavad diagnostikat enne lähtestamist, ning parandage saatuslikud vead ja täitmise ajalõpud, milleni ründaja pääseb.

Mida SilentShield siin saab ja mida mitte

See ei ole botiprobleem ning ütleme seda pigem otse, kui jätame tootelehe seda vihjama. Rünnak tabab PHP mootorit enne, kui päringut näeb miski meie oma või ükski CAPTCHA, plugin või tulemüürireegel Teie rakenduse sees. Vormi botikaitse seda ei peata ja keegi ei tohiks Teile väita vastupidist. Ainus täielik lahendus on PHP uuendus.

SilentShieldi API ja töölaud ei ole kirjutatud PHP-s. WordPressi plugin ja PHP SDK töötavad Teie enda PHP-s, seega tuleb nende puhul uuendus teha Teie serveris. Pärast uuendamist on tavapärane kaitse botide ja vormispämmi vastu sama kasulik kui varem; see lihtsalt ei olnud kunagi vastus sellele probleemile.

Allikad

• CERT-EU turvateade 2026-018: Critical Vulnerabilities in PHP
• PHP teadaanne 20. oktoobrist 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: tooted, mis põimivad PHP-d