PHP2Shell (CVE-2026-109618 ja CVE-2026-109619): mida peaksid PHP-d kasutavad ettevõtted nüüd tegema

Tehnik sülearvutiga serveririiuli juures töötamas

21. oktoobril 2026 avaldas PHP projekt versioonid PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35, et parandada kaks haavatavust, mis „võivad võimaldada koodi kaugkäivitamist ilma autentimiseta“. Lihtsamalt öeldes: igaüks, kes saab teie veebisaidile HTTP-päringu saata, võib olla võimeline teie serveris oma koodi käivitama. Parooli ei ole vaja ja mõne seadistuse puhul toimib rünnak enne, kui teie rakendus on jõudnud täita ühegi rea. Haavatavuste paar on saanud nimeks PHP2Shell ja PHP annab mõlemale hinde 9,2 (CVSS 4.0, 10-pallisel skaalal).

See juhend on neile, kes peavad selle põhjal tegutsema: PHP-veebisaitide ja e-poodide omanikele, IT-juhtidele ja kõigile, kelle eest käitab PHP-d mõni tarnija. See on kirjutatud 22. oktoobril 2026, päev pärast väljalaset, PHP projekti enda turvateadete, riiklike küberturbeasutuste juhiste ja tarnijate avaldatud arvude põhjal. Kus allikad lahknevad, ütleme seda.

Lühidalt

Uuendage PHP-d ennast ja seejärel taaskäivitage see. WordPressi, Drupali, Laraveli või mõne plugina uuendamine seda ei paranda. Viga on PHP-s, teie rakenduse all.
Mõjutatud on iga PHP-paigaldus, mis teenindab veebipäringuid, ütleb PHP: PHP-FPM, Apache koos mod_php-ga, php-cgi, FrankenPHP ja LiteSpeed. Apache koos mod_php-ga on PHP hinnangul kõige suurema riskiga.
Peaaegu pooled PHP-veebisaidid kasutavad haru, millele PHP projekt enam väljalaskeid ei tee (meie tõlgendus W3Techsi andmetest, vt allpool). Nende jaoks ei ole ametlikku paketti, mida paigaldada.
Seadistused ja tulemüürid annavad aega, mitte turvalisust. PHP loetleb ajutisi meetmeid ja ütleb, et need „ei muuda paigaldust turvaliseks“.
Kui te ei saa täna paigata, annavad USA, Ühendkuningriigi ja ELi asutused sama nõuande: võtke süsteem internetist maha, kuni saate.

Mis juhtus ja millal

19. august 2026. Wizi uurijad leidsid oma avalikustamise järgi neist vigadest esimese ja teatasid neist PHP turvameeskonnale 24. augustil. PHP turvateated tunnustavad ka mitme teise ettevõtte uurijaid.
20. oktoober. CVE-numbrid lekkisid internetti kaks päeva enne kavandatud avalikustamist. PHP tõi väljalaske päeva võrra ettepoole, 21. oktoobrile kell 14:00 UTC, ja kutsus kõiki valmistuma.
21. oktoober, 03:02 UTC. Cloudflare lülitas tulemüürireeglid sisse kõigile klientidele, kes kasutavad tema WAF-i, kaasa arvatud tasuta paketi kasutajatele. Hiljem teatas ettevõte, et „täheldas meie kliente sihtivat ründeliiklust“, ja nägi, kuidas ründajad „muutsid ründekoodi, et püüda meie kaitsest mööda pääseda“.
21. oktoober, umbes 14:00 UTC. PHP avaldas parandused ja oma turvateate. Samal päeval kutsusid organisatsioone viivitamata paikama USA-s CISA, Ühendkuningriigi NCSC, CERT-EU ning Euroopa Komisjoni, ENISA, CERT-EU, Europoli ja ELi riiklike CSIRTide ühisavaldus.

Kui tõsine see on?

Kolm asja eristavad seda tavalisest igakuisest paigast.

Ründajal pole vaja muud kui päringut. Pole vaja sisse logida ega kedagi, kes lingile klõpsaks. PHP turvateade kirjeldab Apache'i ja mod_php vastu näidatud ärakasutust, „kus autentimata päring võib rünnaku käivitada enne, kui mis tahes rakenduse kood käivitub“. Wiz näitas ründeid WordPressi, Drupali ja Joomla praeguste versioonide vastu ning märgib, et „isegi lihtne ‚Hello World‘ rakendus, mis töötab mõjutatud PHP versioonil, võib olla haavatav“. Sel viisil käivitatud koodil on veebiserveri konto õigused ja enamikul saitidel saab see konto lugeda rakenduse konfiguratsiooni: andmebaasi parooli, API-võtmeid, e-posti ja maksete juurdepääsuandmeid. Teise vea, CVE-2026-109619 puhul kinnitab PHP ka mälu avalikustamist: andmed lekivad serveri mälust välja ka ilma täieliku koodikäivituseta.

Paigaldusbaas on tohutu. W3Techsi andmetel töötab PHP-l 69,3% veebisaitidest, mille serveripoolne keel on teada (22. oktoobri 2026 seisuga). Palo Alto Networksi Unit 42 loendas oma internetiskaneerimise põhjal üle 22,6 miljoni internetile avatud instantsi, mis on potentsiaalselt haavatavad, ning teatab, et vähemalt üks Euroopa valitsus võttis ettevaatusabinõuna oma veebisaidi võrgust maha.

Ründekoodi arendus käib kiiresti. CERT-EU teatab, et esimesed kontseptsioonitõendused (proof of concept) „on hakanud levima“. Turbeettevõte watchTowr ütleb, et tema meepotid (honeypot) on ärakasutamist registreerinud alates 21. oktoobrist. Cloudflare teatab ründeliiklusest. Wiz aga ütleb, et tema uurijad kasutasid kogu töö vältel tehisintellekti mudeleid, nii et üks uurija tegi nädalaga ära selle, mis „oleks maailmatasemel meeskonnal võtnud kuid“. Ründajatel, kes kohandavad ründekoodi teie PHP versioonile, on samad tööriistad.

Õigluse huvides ka teine pool: kui CISA avaldas 21. oktoobril oma hoiatuse, ei olnud ta ärakasutamist täheldanud ja kumbki viga ei olnud veel tema kataloogis Known Exploited Vulnerabilities (teadaolevalt ärakasutatud haavatavused). Red Hat hindab probleemi tasemele „Important“ (oluline), mitte kriitiliseks, sest tavaline Red Hat Enterprise Linuxi server kasutab PHP-FPM-i, mille puhul on ärakasutamine raskem. Raskem ei tähenda võimatut: PHP kinnitab, et üks teise vea ründetee töötab ka PHP-FPM-iga. Miski sellest ei muuda seda, mida peaksite tegema. See muudab ainult seda, kui palju eelhoiatust te saate.

Milline versioon teil on? Arvud

W3Techs avaldab ka seda, milliseid PHP versioone veebisaidid kasutavad, arvestades saite, mis oma versiooni näitavad. Kui panna kokku selle kaks 22. oktoobri 2026 tabelit:

PHP haru	Osakaal PHP-veebisaitidest	Parandus PHP projektilt
8.3, 8.4, 8.5	umbes 34%	Jah: 8.3.36, 8.4.27, 8.5.12
8.2	umbes 18%	Jah: 8.2.35. Kuid 8.2 ise jõuab eluea lõppu 31. detsembril 2026
8.0, 8.1	umbes 14%	Väljalaset ei ole. 8.0 ja 8.1: ainult lähtekoodi backport
7.x	26,9%	Väljalaset ei ole. 7.4: ainult lähtekoodi backport; 7.3 ja vanemad: mitte midagi
5.x ja vanemad	7,8%	Mitte midagi

Seega kasutab umbes 48% PHP-veebisaitidest haru, millele PHP projekt parandatud väljalaset ei avalda, ja veel 18% saab paranduse nüüd, kuid kaotab toe kümne nädala pärast.

Kaks mööndust. W3Techs näeb ainult saite, mis oma versiooni näitavad. Ja Linuxi distributsioon võib olla vana haru ise paiganud: Ubuntu on seda teinud, nagu allpool näete. Versiooninumber üksi ei ütle, kas olete kaitstud. Seda ütleb teie tarnija paketi versioon.

1. samm: leidke üles kõik PHP-paigaldused, mida kasutate

Te ei saa paigata seda, mida te pole üles loetlenud, ja PHP oskab hästi peituda. Ühendkuningriigi NCSC palub organisatsioonidel leida üles kõik PHP-süsteemid, esmalt internetile avatud süsteemid, ning lisab: „ärge piirake otsingut aegunud PHP versioonidega“. ELi ühisavaldus hoiatab, et mõnda toodet „võivad need haavatavused mõjutada ka siis, kui need ei paista PHP-d otseselt kasutavat“.

Kust otsida:

Veebisaidid ja e-poed: WordPress ja WooCommerce, Drupal, Joomla, Magento ja Adobe Commerce, Shopware, PrestaShop, TYPO3 ning kõik, mis on ehitatud Laraveli või Symfony peale.
Unustatud süsteemid: kampaaniate mikrosaidid, saidi vana keeleversioon, internetist ligipääsetavad staging- ja testserverid, veebipost või kasutajatoe süsteem, mille keegi aastaid tagasi paigaldas.
Konteinerid: iga konteinerikujutis, mis on ehitatud php baaskujutisest, sisaldab oma PHP-d. Hostmasina uuendamine ei tee sellele midagi.
Majutuse juhtpaneelid: cPanel, Plesk ja sarnased paneelid toovad süsteemi PHP kõrvale kaasa oma PHP-järgud. Iga paneelis sisse lülitatud versiooni tuleb eraldi uuendada.
Tooted, mille sees on PHP: seadmed, seiretööriistad, CRM-id, kasutajatoe süsteemid ja tarnijate haldusliidesed. Madalmaade NCSC peab avalikku nimekirja sellistest toodetest koos nende olekuga, tarnija kaupa.
Tarnijad: teie majutusettevõte, teie agentuur, iga teenus, mille puhul teate, et selle all on PHP. Küsige neilt kirjalikult, millised PHP versioonid teie süsteemides töötavad ja millal need paigatakse.

Kirjutage igaühe kohta üles PHP versioon, kuidas PHP töötab (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, konteiner), kas see on internetist ligipääsetav ja kes saab seda paigata.

2. samm: paikage õiges järjekorras

Alustage kõigest, mis on internetist ligipääsetav, ja selle seas Apache'i ja mod_php seadistustest.

Toetatud harul (8.2 kuni 8.5). Uuendage versioonile 8.5.12, 8.4.27, 8.3.36 või 8.2.35 või oma distributsiooni paketile, mis parandust sisaldab. PHP sõnul said Linuxi distributsioonid paigad kätte juba varem. Seni kinnitatud:

Ubuntu: parandatud paketid kõigile väljalasetele vahemikus 14.04 kuni 26.10. Versioonidel 22.04 ja uuematel tulevad need tavaliste uuendustega; versioonidel 20.04 ja vanematel on vaja Ubuntu Pro tellimust, mis on kuni viiele masinale tasuta (Canonicali teade).
Debian: php8.4 8.4.27 Debian 13 jaoks (DSA-6574-1) ja php8.2 8.2.35 Debian 12 jaoks (DLA-4848-1).
Red Hat Enterprise Linux: Red Hati turvabülletään RHSB-2026-013 loetleb paketid väljalasete kaupa.
Remi hoidla, mida kasutatakse laialt uuema PHP jaoks Red Hati perekonna süsteemides: 21. oktoobril märkis CERT-EU, et sellel ei olnud väljalaskepäeval pakette, ja soovitas minna üle distributsiooni pakettidele või ehitada PHP lähtekoodist. Enne kui sellele tuginete, kontrollige, kas see on järele jõudnud.

PHP 7.4, 8.0 või 8.1 puhul. PHP projekt neile väljalaset ei avalda. Selle turvameeskond tegi kolmele harule minimaalsed lähtekoodi backportid, mis aitavad, kui kompileerite PHP ise. Muul juhul peab parandus tulema teie tarnijalt (näiteks Ubuntu Pro katab PHP 7.4 Ubuntu 20.04-l) või PHP viimisest uuemale versioonile. CISA nõuanne kõigile, kes kasutavad versiooni 8.1 või vanemat ega saa uuendada, on otsekohene: võtke süsteem võrgust maha, kuni see on paigatud või uuemale versioonile viidud.

PHP 7.3 või vanema puhul. PHP projektilt ei tule midagi. Kui mõni tarnija teie järku veel ei paika, on valik uuemale versioonile üleminek või süsteemi võrgust mahavõtmine.

Taaskäivitage pärast uuendamist. Paketi paigaldamine ei asenda juba töötavat PHP-d. Ubuntu teade ütleb selle otse välja: rakendus „tuleks tõenäoliselt taaskäivitada“. Taaskäivitage igas serveris PHP-FPM, Apache, LiteSpeed või konteiner. Seejärel kontrollige versiooni, mida veebiserver tegelikult kasutab, mitte ainult käsurea php -v tulemust, sest see võib pärineda teisest järgust.

Konteinerid: ehitage konteinerikujutised paigatud baaskujutisest uuesti ja juurutage need uuesti. Paigatud hostmasin, millel töötab vana kujutis, on endiselt ohus.

Hallatud majutus: küsige teenusepakkujalt kuupäeva ja versiooni ning kontrollige seejärel ise.

3. samm: kui te ei saa täna paigata

PHP turvateade loetleb ajutisi meetmeid ja esitab need koos hoiatusega: need „vähendavad avatust konkreetsetele ründeteedele, kuid ei muuda paigaldust turvaliseks“. Lühidalt, neile, kes teie servereid haldavad:

CVE-2026-109618 vastu: seadke memory_limit=-1 nii, et rakendus ei saaks seda üle kirjutada (näiteks php_admin_value abil PHP-FPM-i protsessikogumi (pool) või Apache'i konfiguratsioonis); seadke madal post_max_size (PHP soovitab 8M ilma failide üleslaadimiseta, 32M koos nendega); piirake veebiserveris või proksis päringu suurust, väljade arvu ja multipart-osade arvu; ning kasutage konteineri või cgroupi mälupiirangut, mitte kunagi RLIMIT_AS ega RLIMIT_DATA.
CVE-2026-109619 vastu: seadke session.upload_progress.enabled=0 failis php.ini või serveri konfiguratsioonis (mitte ini_set() ega .user.ini faili kaudu) ja taaskäivitage kõik töötajaprotsessid (worker). PHP 8.5 puhul seadke lisaks fatal_error_backtraces=0.

Kaks hoiatust. 20. oktoobril laialt levinud seansiseadistus sulgeb ainult teise vea ründeteed, nagu üks PHP turvameeskonna liige välja tõi; esimese vastu ei tee see midagi. Ja memory_limit=-1 eemaldab PHP enda mälupiirangu, nii et üksainus raske päring võib nüüd serveri ressursid ammendada. Kasutage seda koos konteineri või cgroupi piiranguga.

Veebirakenduse tulemüür (WAF) aitab, aga vähe. Cloudflare'i reeglid on vaikimisi sees kõigis pakettides, mis sisaldavad tema WAF-i, kaasa arvatud tasuta paketis, ning Palo Alto Networks ja teised tarnijad on avaldanud oma kaitsemeetmed. Cloudflare ütleb klientidele siiski, et PHP tuleb paigata „ka WAF-kaitse olemasolul“, ja nägi, kuidas ründajad muutsid ründekoodi, et tema reeglitest mööda pääseda. WAF kaitseb ka ainult liiklust, mis seda läbib. Kui teie server vastab oma IP-aadressil, saab ründaja sellest mööda minna.

Kui midagi sellest ei saa kiiresti teha, osutavad CISA, CERT-EU, NCSC ja ELi ühisavaldus kõik samas suunas: võtke süsteem avalikust internetist maha, kuni see on parandatud. Hooldusleht päevaks maksab vähem kui uuesti üles ehitatud server.

4. samm: kontrollige, kas teid on juba rünnatud

Aken avanes 20. oktoobril, kui leke algas, ja ründeliiklusest teatati järgmisel hommikul. Kui süsteem oli selle akna ajal ligipääsetav ja paikamata, sulgeb paikamine ukse, kuid ei ütle, kas keegi tuli enne sisse. NCSC palub kõigil, kes ei saanud kohe paigata, otsida kompromiteerimise ja tagauste märke.

Mida otsida, avaldatud juhiste ja tavapärase intsidentide käsitlemise praktika põhjal:

PHP-protsessid, mis teevad asju, mida PHP kunagi ei tee, näiteks käivitavad shelli või laadivad alla tööriistu (CISA).
Ebatavalised multipart-päringud, millele järgnevad mälupiirangu vead või korduvad HTTP 500 vastused, ilma selge põhjuseta taaskäivituvad PHP töötajaprotsessid ning ebatavaliselt suured või vigased PHPSESSID küpsised vastustes (Wiz).
Uued või muudetud PHP-failid üleslaadimiskaustades, vahemälukaustades või veebi juurkataloogis, uued administraatorikontod teie sisuhaldussüsteemis ja ajastatud ülesanded, mida keegi ei loonud.

Puhtad logid ei ole tõend. PHP turvateade teise vea kohta hoiatab just selle eest ja Wiz märgib, et rakenduse logides võib olla vähe konteksti.

Kui leiate midagi, käsitlege seda intsidendina, mitte paikamistööna. Isoleerige server, säilitage tõendid, kaasake intsidentidele reageerimise teenusepakkuja ja vahetage kõik saladused, mida veebiserver sai lugeda: andmebaasi paroolid, API-võtmed, maksete ja e-posti juurdepääsuandmed, allkirjastamisvõtmed. Kuna teine viga võib mälu sisu avalikustada, kaaluge kõige tundlikumate saladuste vahetamist igas serveris, mis oli päevi avatud ja paikamata, ka siis, kui sissetungi märke ei ole.

5. samm: millest võib olla vaja teatada

Haavatavus üksi ei ole intsident, millest peab teatama. Ärakasutatud haavatavus võib olla.

NIS2: kui teie organisatsioon kuulub kohaldamisalasse ja kompromiteerimine on oluline intsident, tuleb varajane hoiatus teie riiklikule CSIRTile esitada 24 tunni jooksul. Vt meie NIS2 juhendit.
Isikuandmete kaitse üldmäärus (GDPR): kui isikuandmetele pääseti ligi, tuleb järelevalveasutust teavitada 72 tunni jooksul pärast seda, kui saite rikkumisest teada, välja arvatud juhul, kui rikkumine tõenäoliselt ei ohusta inimesi. Vt meie isikuandmete kaitse üldmääruse juhendit.
Küberkerksuse määrus (CRA): kui müüte tarkvara või seadet, mille sees on PHP, olete CRA mõistes selle tootja. Alates 11. septembrist 2026 on tootjad pidanud oma toodete aktiivselt ärakasutatud haavatavustest teatama CRA ühtse teavitusplatvormi (Single Reporting Platform) kaudu, nagu ELi ühisavaldus meelde tuletab. Vt meie küberkerksuse määruse juhendit.
Teie kliendid: kui majutate või käitate PHP-d klientide jaoks, siis nad küsivad. Lühike kirjalik teade (mida te kasutate, millal see paigati, mida kontrollisite) vastab enamikule küsimustest ja see on sama teade, mida soovib näha audiitor või küberkindlustuse pakkuja.

Pärast hädaolukorda: mida muuta

Enamikus hästi hallatud serverites on PHP2Shell mõne päevaga paigatud. See, mida see teie seadistuse kohta paljastas, jääb tõeks ka pärast seda.

Teadke, kui kaua teil paikamine aega võtab. Turvateatest kuni iga serveri taaskäivitamiseni: tunnid, päevad või nädalad? Kui aus vastus on „peaksime agentuurilt küsima“, parandage see enne järgmist korda. Kui uurijad ütlevad, et tehisintellekt lühendas nende ründekoodi arendustööd kuudelt nädalale, eeldage, et ka ründajad suudavad liikuda sama kiiresti.
Hoidke äsja koostatud inventuur alles. See oli reageerimise kõige raskem osa ja see vananeb hetkel, kui keegi selle eest ei vastuta.
Loobuge eluea lõppu jõudnud PHP-st. Sait versioonil 7.4 või 8.1 vajas seekord tarnijat või lähtekoodi backporti; järgmisel korral ei pruugi kumbagi olla. PHP 8.2 jõuab eluea lõppu 31. detsembril 2026, seega peaks 8.1-lt lahkuv sait minema otse versioonile 8.3 või uuemale. PHP vahetamine tähendab sageli ka rakenduse uuendamist: meie artikkel Drupali, Umbraco ja Kentico eluea lõpust näitab, mida see ühe sisuhaldussüsteemi puhul hõlmab.
Eelistage võimaluse korral PHP-FPM-i mod_php-le. Seekord oli see väiksema riskiga seadistus.
Jätke üleslaadimise edenemise jälgimine välja lülitatuks, kui te seda ei kasuta. PHP turvateade soovitab hoida session.upload_progress.enabled välja lülitatuna ka pärast paikamist, kui rakendus seda ei vaja.
Kirjutage paikamise ajad oma lepingutesse. Küsige oma majutusteenuse pakkujalt ja agentuurilt, kui kiiresti nad kriitilisi PHP parandusi rakendavad, ja hankige vastus kirjalikult.

Kontrollnimekiri sellesse nädalasse

Loetlege üles kõik PHP-paigaldused, sealhulgas konteinerid, juhtpaneelid, tarnijate tooted ja staging-serverid.
Paikage esmalt internetile avatud süsteemid, alustades Apache'i ja mod_php seadistustest.
Taaskäivitage kõik PHP-protsessid ja kontrollige versiooni, mille veebiserver teatab.
Ehitage konteinerikujutised uuesti ja juurutage need uuesti.
Kus te ei saa täna paigata, rakendage PHP ajutisi seadistusi, suunake liiklus läbi WAF-i või võtke süsteem võrgust maha.
Küsige tarnijatelt ja majutusteenuse pakkujatelt kirjalikult nende PHP versiooni ja paikamise kuupäeva.
Vaadake üle logid ja failimuudatused kõigis süsteemides, mis on olnud alates 20. oktoobrist avatud ja paikamata.
Otsustage, kas kehtib mõni teatamiskohustus (NIS2, GDPR, CRA).
Planeerige loobumine PHP 8.1-st ja vanematest versioonidest ning 8.2-st enne 31. detsembrit.

Kuidas saame aidata

Enamikul ettevõtetel ei puudu tahe paigata. Neil puudub selge pilt sellest, mida nad kasutavad, või inimesed, kes töö sel nädalal ära teeksid. Selle osa võtame enda peale:

Inventuur ja paikamine päevadega. Leiame teie PHP-paigaldused serveritest, konteineritest, majutuse juhtpaneelidest ja tarnijate juurest, paikame need, taaskäivitame ja kontrollime ning jätame teile kirjaliku ülevaate sellest, mis tehti ja millal. See ülevaade on ka teie vastus klientidele ja audiitoritele.
Vanast PHP-st loobumine. Rakendused, mis on jäänud kinni PHP 7.x, 8.0 või 8.1 külge, sest kood ei tööta millelgi uuemal: pordime need toetatud versioonile meie pärandsüsteemide hooldusteenuse raames.
Karmistamine ja paikamise rutiin, et järgmine turvateade oleks plaaniline töö, mitte hädaolukord.

Kui leiate sissemurdmise märke, pöörduge kõigepealt intsidentidele reageerimise teenusepakkuja poole. Meie saame nende kõrval enda peale võtta süsteemi uuesti ülesehitamise ja uuendamise.

Kirjutage meile aadressil office@c9group.dev, mis teil töötab, ja me vastame, millest me alustaksime.

Allikad

Kontrollitud 22. oktoobril 2026. Olukord muutub endiselt: eelkõige ärakasutamise seis ja tarnijate paketid võivad vahepeal olla muutunud.

PHP projekt

Asutused

Uurijad, tarnijad ja andmed