PHP2Shell: kriitiline PHP turvanõrkus — kas teie veebileht on ohus?

Mõjutatud on kõik PHP versioonid, mis on oma harus vanemad kui 8.5.12, 8.4.27, 8.3.36 ja 8.2.35, ja see tähendab peaaegu iga PHP veebilehte, mida sel nädalal keegi ei ole uuendanud. Täna on esimene töö välja selgitada, milline versioon teie veebilehte teenindab, ja seda uuendada — täielikku hädalahendust ei ole, ja PHP enda teadaanne ütleb, et uuendamine on ainus turvaline valik.

Kolmapäeval, 21. oktoobril, lasi PHP meeskond korraga välja neli erakorralist versiooni. Turvanõrkuste paar, mida need parandavad, on saanud nime PHP2Shell, ja see kirjeldab tulemust täpselt: võrgupäringust kuni koodi käituseni serveris. See artikkel räägib sellest, mis täpselt leiti, kuidas aru saada, kas see puudutab teid, ja millises järjekorras tegutseda — ka siis, kui kohe uuendada ei saa.

Mis on PHP2Shell ja mis juhtus 21. oktoobril

Ametlikus teadaandes on öeldud, et 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 parandavad kaks kriitilist turvanõrkust, mis võivad lubada autentimata ründajal koodi kaugkäitust (RCE), ja et kõigil PHP kasutajatel on tungivalt soovitatav kohe uuendada. Sealsamas on ka lause, mis määrab kogu ülejäänud artikli: täielikku hädalahendust ei ole, ja uuendamine on ainus turvaline valik.

Mõlemale turvanõrkusele on PHP andnud CVSS v4.0 skoori 9.2 kümnest, aga need on kaks eraldi viga eri mehhanismiga ja, nagu allpool näha, ka eri kinnituse astmega — ja just see teine erinevus otsustab praktikas, millisest serverist alustada.

CVE-2026-109618 — rikutud mälu pärast out-of-memory (OOM) olukorda. Kui PHP-l saab mälu otsa, kasutab see longjmp(), et katkestada päringu töötlemine. Ametlik kirjeldus osutab, et mõnel hetkel on päringu mälu kättesaadav enne, kui see on täielikult algväärtustatud; kui just siis mälu eraldamine ebaõnnestub, ei käsitleta katkestust korrektselt ja järele jääb vigane mälu, mida lõpetamiskood veel loeb või mille põhjal see otsuse teeb.

Oluline detail, mis muudab seda, keda see oht puudutab: out-of-memory olukord saavutatakse spetsiaalselt koostatud multipart-päringuga, ja selles ei pea olema ühtegi üles laaditud faili. Ametlik kirjeldus nimetab mitut multipart-töötluse probleemi — päringut ilma kasutatava deklareeritud pikkuseta, osa piiramatu päiste arvuga, tühje failivälju, mida piirangutesse ei arvestata. See tähendab, et päring võib olla päris väike ja mahtuda tavalistesse post_max_size ja memory_limit piiridesse.

CVE-2026-109619 — aegunud globaalne olek. PHP protsessis püsib päringute vahel globaalne olek: vigade, sessioonide, objektide ja laienduste andmed. Ametlik kirjeldus ütleb, et see olek tuleb lähtestada, enne kui päringu mälu vabastatakse. Kui lähtestamise katkestab fataalne viga või kui diagnostika täidab selle lõpetamise hetkel uuesti, vabastatakse mälu, aga viit sellele jääb. Seda veaklassi nimetatakse rahvusvaheliselt use-after-free.

Edasi tuleb tingimus, mis teeb selle turvanõrkuse raskemaks, kui see kõlab: aegunud viita saab kasutada ainult toiming, mis juhtub enne tavalist päringu algväärtustamist, ja ametlik kirjeldus nimetab kaks sellist kinnitatud juhtu — INI diagnostika ja sessiooni üleslaadimise edenemise töötlus. Pealegi peab ründaja hilisem päring jõudma täpselt samasse protsessi, kus rikutud olek tekkis, seepärast õnnestub üksik katse harva, ja kirjeldus ütleb otse, et mitu protsessi ja nende väljavahetamine vähendavad tõenäosust, aga tingimust ennast ei kõrvalda.

Kui lihtne seda on ära kasutada ja mille vastu see on tõestatud

Siin tasub olla täpne, sest just selles kohas enamik interneti artikleid liialdab ühes või teises suunas.

Parooli ei ole vaja, ja ei ole vaja ka seda, et keegi veebilehel midagi vajutaks — CVSS-vektoris paistab see PR:N ja UI:N kujul. Samas vektoris on aga AC:H ja AT:P: ründe keerukus on hinnatud kõrgeks ja sellel on lisatingimused. Praktikas tähendab see korduvaid katseid, ja õnnestumine sõltub PHP järgust, laiendustest, frontendi käitumisest ja mälu paigutusest. Niisiis ei — ühest tavalisest päringust ei piisa; aga see ei maksa ründajale ka midagi, sest katsete arvu ei piira miski.

Tõestuse aste on kahel veal erinev, ja see erinevus on tähtis, kui valida, kui palju kiirustada. CVE-2026-109618 puhul on täielik koodi kaugkäitus kinnitatud mod_php vastu vaikimisi sisendi- ja mälupiirangutega; PHP-FPM-i kohta ütleb sama kirjeldus, et lähtekoodi analüüs peab seda haavatavaks, aga täielikku PHP-FPM-i rünnet ei ole demonstreeritud. FrankenPHP on seal mainitud mod_php analoogina, LSAPI aga PHP-FPM-i analoogina, mõlemal juhul ilma kontrollitud ründeta.

CVE-2026-109619 puhul on sessiooni elutsükli tee läbi proovitud nii mod_php kui ka PHP-FPM-i vastu; teine tee, mis läheb läbi fataalse vea jälje, on aga kinnitatud ainult mod_php vastu.

Sellest järeldub praktiline järjekord: kui teie veebileht töötab mod_php peal, olete esimeses reas, sest just seal on mõlemad vead kinnitatud. PHP-FPM-i ja LiteSpeedi puhul on risk reaalne, aga seni osaliselt kinnitatud. Ühelgi neist juhtudest ei ole see põhjus oodata — see on põhjus teada, millisest serverist alustada.

Kuidas see nädal tunni kaupa välja nägi

Kronoloogia ei ole kurioosum — see seletab, miks esimeste tundide soovitused erinesid nendest, mis kehtivad praegu, ja miks osa interneti artikleid on endiselt vananenud.

20. oktoobri õhtul oli teada, et midagi on tulemas, aga ei olnud teada, mis täpselt: PHP oli teatanud eelseisvast erakorralisest väljalaskest, ja CloudLinuxi staatuseleht fikseerib sama õhtu kohta, et tehnilised andmed ja mõjutatud versioonid on plaanis avaldada järgmise päeva väljalaske hetkel. Tehniline kirjeldus ei olnud siis veel avalik.

Järgmiseks päevaks oli olukord muutunud, ja mitte paremuse poole: 21. oktoobri hommikul fikseerib CloudLinux, et avalikus ringluses on juba ründemuster, ja kell 9.08 UTC levitab veebirakenduse tulemüüri (WAF) reeglistikku, mis blokeerib teadaoleva ärakasutamise päringumustri. Kaheksateist minutit hiljem ilmub samale lehele lause, mis iseloomustab seda nädalat kõige paremini — sellele mustrile vastavaid katseid juba vaadeldakse, seega otsis keegi juba servereid, millel turvapaika veel ei ole.

PHP turvapaigad tulid välja kell 14.00 UTC, mis tähendab, et avalikult kättesaadava ründemustri ja avalikult kättesaadava turvapaiga vahele jäi mitu tundi, ja neil tundidel ründekatsed juba toimusid.

Üks mööndus on siin aus välja öelda: maailm ei olnud päris ilma turvapaigata, sest PHP teadaandes on öeldud, et Linuxi distributsioonid ja pikaajalise toe pakkujad said turvapaigad ette, nii et osal serveritest oli uuendus saadaval varem kui ülejäänutel — uuendus ise ei olnud siiski kellelegi avalikult kättesaadav.

Seejärel algas pikem osa, mis kestab siiani: pakettide levitamine. Operatsioonisüsteemide haldajad ja veebimajutuse platvormid ehitavad oma paketid eraldi, ja need ilmuvad tundide või päevade jooksul, igaüks omas tempos. Just selles etapis on suur osa virtuaalserveri kasutajatest, ja just seepärast on küsimus „kas turvapaik on välja tulnud“ ja küsimus „kas turvapaik on minu serveris“ sel nädalal kaks eri küsimust eri vastustega.

Kas teie veebileht on ohus

Ametlikes hoiatustes on mõjutatud versioonide vahemikud kirjas nii: kõik, mis on vanem kui 8.2.35, kõik, mis on vanem kui 8.3.36, kõik, mis on vanem kui 8.4.27, ja kõik, mis on vanem kui 8.5.12 — igaüks oma harus.

Oluline detail, mis lubab eksida: number, mida näitab php -v, ei ütle alati kõike. Linuxi distributsioonid ja veebimajutuse platvormid kipuvad turvapaiga vanemale versioonile üle kandma, ilma selle numbrit muutmata — muutub ainult paketi väljalaske number. Sel juhul võib 8.4.26 olla juba turvapaigaga, aga ei pruugi. Ainus viis seda teada on vaadata paketi kirjeldust või küsida pakkujalt; versiooninumber ise sellele küsimusele ei vasta.

Eraldi vanemate versioonide kohta. PHP 8.1 ja vanemad ei saa PHP projektilt enam regulaarseid uuendusi, aga tõsidust arvestades on turvameeskond valmistanud minimaalsed lähtekoodi turvapaigad versioonidele 7.4, 8.0 ja 8.1 — neile, kes ehitavad lähtekoodist või kellel ei ole juurdepääsu haldaja toele. Teadaanne soovitab sealsamas võtta ühendust oma pakkujaga, sest osa distributsioone ja pikaajalise toe pakkujaid kannab turvapaigad üle. Kui teie veebileht töötab PHP 7.x peal, ei ole tegelik probleem see nädal — tegelik probleem on, et järgmisel korral ei pruugi turvapaika ollagi. Ja PHP 8.2, mis seekord turvapaiga sai, jõuab end of life'i 31. detsembril 2026.

Kuidas versiooni kontrollida, olenevalt sellest, kus veebileht elab

Kontroll võtab minuteid, ja seda tasub teha iga veebilehe kohta eraldi, mitte iga serveri kohta: ühes serveris elavad tihti veebilehed eri PHP versioonidega, ja tavaliselt on just see vanim, mille kõik on unustanud, avalikult kättesaadav.

Virtuaalserver cPaneliga. Versiooni näitab MultiPHP Manager, kus igal domeenil on oma rida; Plesk kasutab sama asja jaoks iga tellimuse sees jaotist PHP Settings. Mõlemal juhul tasub veenduda, et vaatate seda domeeni, millest jutt on, mitte serveri vaikeseadet.

Oma server või VPS. Käsureal näitab seda php -v, aga ühe olulise mööndusega: käsurea PHP on tihti hoopis teine versioon kui see, mis veebipäringuid teenindab. Usaldatavaima vastuse annab sama tee, mida mööda veebileht töötab — käivitatav fail, mis on näidatud PHP-FPM-i konfiguratsiooni pool-jaotises.

Konteinerid. Kui veebileht töötab Dockeris, määrab versiooni tõmmis, mitte hostmasin, seepärast on kaks sammu: ehitada tõmmis uuesti uuendatud põhitõmmisega ja seejärel taaskäivitada konteinerid. Tõmmis, mis on ehitatud enne 21. oktoobrit, turvapaika ei sisalda, ükskõik kui sageli konteinerit on taaskäivitatud.

Kui juurdepääsu ühelegi neist ei ole. Siis on küsimus veebimajutuse pakkujale, ja sel nädalal on see täiesti tavaline küsimus, millele neil on vastus juba valmis. Sõnastus, mis säästab kirjavahetust: „Milline PHP versioon teenindab minu domeeni, kas selles on PHP2Shell turvapaik, ja kui veel ei ole, mis kuupäeval see tuleb?“

Mida täna teha

Tänane järjekord on selline: esmalt uuendada PHP ja taaskäivitada kõik, mis seda käitab, siis veenduda, et külastajaid teenindab päriselt uus versioon, seejärel kontrollida, kas kasutatav paketihoidla on turvapaiga üldse välja lasknud, ja alles pärast seda otsida jälgi. Esimene samm võtab minuteid, viimane võib võtta päevi, ja just seepärast ei tasu neid samme omavahel ära vahetada.

Esiteks uuendage. Hallatava veebimajutuse puhul teeb seda pakkuja, ja teie töö on esitada küsimus ja saada kuupäev. Kui haldate serverit ise, tuleb pärast pakettide uuendamist taaskäivitada see, mis PHP-d käitab: Apache, PHP-FPM või LSAPI. See samm jäetakse üllatavalt sageli vahele — pakett on välja vahetatud, aga vanad protsessid töötavad edasi vana koodiga, nii et kontroll näitab uut versiooni, kuni külastajaid teenindab vana.

Teiseks kontrollige, et uuendus on päriselt rakendatud — sama teed mööda, mida mööda veebileht töötab, mitte käsurea kaudu.

Kolmandaks, kui kasutate vabatahtlikult hallatavat paketihoidlat, kontrollige, kas see on turvapaiga välja lasknud. PHP teadaandes on eraldi hoiatus rpms.remirepo.net kohta: selle kasutajatel soovitatakse minna üle distributsiooni pakettidele või ehitada lähtekoodist.

Neljandaks, alles seejärel kontrollige, kas veebilehel on jälgi. Uuendamine sulgeb ukse, aga ei vasta küsimusele, kas keegi on sealt juba sisse tulnud.

Kui kohe uuendada ei saa

Seda jaotist tasub lugeda selge teadmisega, et ükski siin nimetatud samm ei asenda uuendust — PHP teadaanne ütleb seda otse.

CVE-2026-109618 vastu mainib teadaanne mälupiirangu eemaldamist: memory_limit=-1, ja pealegi nii, et rakendus ei saa seda üle kirjutada — näiteks php_admin_value abil PHP-FPM-i või Apache konfiguratsioonis, veendudes, et ükski teine säte ei pane lõplikku piirangut tagasi. Tuleb aru saada, mida see valik maksab: virtuaalserveris vahetab see ühe riski teise vastu, sest üks päring võib nüüd ära süüa kogu saadaoleva mälu. Turvanõrkuse kirjeldus hoiatab ka, et RLIMIT_AS ja RLIMIT_DATA tuleb jätta kasutamata, sest need võivad panna mälu eraldamise ebaõnnestuma ja viia täpselt sellele teele, kus turvanõrkus on.

CVE-2026-109619 vastu mainib teadaanne session.upload_progress.enabled=0 ja PHP 8.5 puhul fatal_error_backtraces=0 — mõlemal juhul juhisega seejärel kõik protsessid taaskäivitada. Turvanõrkuse enda kirjelduses on ka pm.max_requests=1, mis paneb PHP-FPM-i pärast iga päringut protsessi (PHP-FPM worker) välja vahetama; see on PHP-FPM pooli säte, ja seal on see mainitud mööndusega „kui jõudlus ei ole tegur“. Sealsamas on öeldud ka see, mis hoiab seda meedet õigetes piirides: protsesside väljavahetamine vähendab tõenäosust ühe päringu kohta, aga tingimust ennast ei kõrvalda.

Kasulik on ka see, mis ei ole hädalahendus, vaid vähendab ründepinda: konservatiivne post_max_size, mõistlik sisendi pesastuse sügavus ja piiratud üleslaadimise maht. Need on head väärtused igal nädalal, mitte ainult sel nädalal.

Kuidas aru saada, kas teid on juba tabatud

Pärast uuendamist tasub vaadata üle veebiserveri logid viimaste päevade kohta. Otsida tasub ebatavaliselt suurt hulka multipart-päringuid ühele ja samale aadressile — ja siin on lihtne otsida valesti: need kipuvad olema väikesed ja mahtuma tavalistesse piirangutesse, seepärast mahu järgi neid ei leia. Kõnekamad on järsud 500-vigade jadad, mis algavad ja lõpevad nähtava põhjuseta: rünnak, mis toetub out-of-memory olukorrale, ebaõnnestub palju sagedamini, kui õnnestub, ja iga ebaõnnestunud katse jätab vea.

Failisüsteemis loevad muutmise ajad: PHP-fail, mida on muudetud öösel, kui keegi ei töötanud, vajab seletust. Tasub kontrollida ka ajastatud ülesandeid ja kirjeid, mis tagavad automaatse käivitumise pärast taaskäivitust — ründajal, kellel on koodi käitus, on esimene töö kinnistuda, et juurdepääs elaks üle just selle uuenduse, mille te just paigaldasite.

Eraldi tasub kontrollida administraatorikontode nimekirja ning rakenduse paroole ja võtmeid. Kui koodi käitus on toimunud, tuleb kõike, mida server teab, pidada loetuks — ka andmebaasi ühenduse andmeid ja API võtmeid konfiguratsioonifailis.

Kui miski sellest ei tundu õige, on puhastamine eraldi töö oma järjekorraga, ja seda tasub teha metoodiliselt, mitte kahtlasi faile ükshaaval kustutades. Oleme seda kirjeldanud eraldi — kuidas häkitud veebilehe taastamine käib, ja kui soovite, et seda teeks keegi teine, on häkitud veebilehe taastamine eraldi teenus kindla järjekorraga: isoleerimine, puhastamine, põhjuse kõrvaldamine ja kontroll, et veebileht on otsingumootorite hoiatusnimekirjadest maha võetud.

Millal sündmusest saab intsident, millest tuleb teatada

Kui on põhjust arvata, et ründaja on pääsenud isikuandmetele, muutub tehniline küsimus ka õiguslikuks. Isikuandmete kaitse üldmäärus näeb ette tähtaja, mis ei alga rünnakust, vaid hetkest, mil vastutav töötleja sai isikuandmetega seotud rikkumisest teada: võimaluse korral hiljemalt 72 tunni jooksul teade järelevalveasutusele. Kohustust ei teki, kui rikkumine tõenäoliselt ei kujuta ohtu füüsiliste isikute õigustele ja vabadustele, ning kui risk on suur, tuleb teavitada ka isikuid endid — ka sellel kohustusel on määruses omad erandid.

Selle jaotise praktiline mõte on üks: hetk, mil logidest on leitud midagi kahtlast, ei ole hetk, mil 72 tundi jooksma hakkavad — see on hetk, mil tuleb välja selgitada, kas isikuandmetega seotud rikkumine on üldse toimunud. Eraldi 500-vigade jada, mis, nagu eespool kirjeldatud, on kõige sagedamini ebaõnnestunud katse, ei ole iseenesest isikuandmetega seotud rikkumine. Just seepärast ei tasu seda väljaselgitamist jätta ajaks „kui tööd on vähem“, ja just seepärast tuleb logid alles hoida, enne kui roteerimine need üle kirjutab: need on ainus tõend nii selle kohta, mis juhtus, kui ka selle kohta, mis ei juhtunud.

Kui teie vastutusel on mitu veebilehte

Agentuuridele ja mitme veebilehega ettevõtetele on see nädal mitte niivõrd tehniline kui korralduslik ülesanne, ja järjekord, mis töötab, on lihtne: esmalt nimekiri, siis versioonid, siis uuendamine prioriteedi järjekorras.

Prioriteedi määrab mitte veebilehe tähtsus, vaid kättesaadavus ja see, mis seda teenindab. Üleval on avalikult kättesaadavad veebilehed mod_php peal, sest just seal on mõlemad turvanõrkused kinnitatud; siis ülejäänud avalikud, ja alles seejärel sisemised süsteemid tulemüüri taga. Testi- ja arenduskeskkonnad, mille kõik unustavad, tuleb nimekirja võtta kohustuslikult — need töötavad tihti vanema PHP versiooni peal ja on tihti internetist kättesaadavad, sest kunagi oli nii mugavam.

Veebilehed, mida haldab keegi teine, jäävad nimekirja, aga teise veeruga: kellele küsimus saadeti ja mis kuupäeval vastus saabus. See veerg osutub hiljem väärtuslikumaks kui ülejäänud, sest just see näitab, milline pakkuja reageerib ja milline mitte.

Mida hallatav veebimajutus sel juhul tähendas

See nädal näitab hästi, kus on piir platvormi ja rakenduse vahel, seepärast on aus öelda, kuidas see meie poolelt välja nägi.

Meie serverid töötavad CloudLinuxil ja neis on sisse ehitatud Imunify360. Kui ründemuster hakkas avalikult ringlema, fikseeris CloudLinux oma staatuselehel, et tulemüüri reeglistik, mis blokeerib teadaoleva ärakasutamise mustri, levitati kell 9.08 UTC — mitu tundi enne, kui PHP ise turvapaiga kell 14.00 välja lasi, ja enne seda, kui samale lehele ilmus kirje, et katseid juba vaadeldakse. Päeva jooksul järgnes veel kaks täiendust, millest teine blokeerib juba avalikult kättesaadava ärakasutamise tööriista. Kõik see juhtus automaatselt, ilma kliendi osaluseta. Valdkonnas kannab selline meede nime virtual patching: veebirakenduse tulemüüri (WAF) reegel blokeerib turvanõrkuse ärakasutamise, muutmata koodi ennast, milles turvanõrkus on.

Ja nüüd see, mida selline lause ei tähenda, sest just siin müüs valdkond sel nädalal kõige rohkem liialdusi. Tulemüüri reegel blokeerib teadaolevaid ründemustreid — sama sõna kasutab ka CloudLinux. Seesama leht nimetab seda meedet ajutiseks lahenduseks, mitte täielikuks turvapaigaks. See ei ole haavamatus, ja CloudLinux ise soovitab endiselt PHP-d uuendada, niipea kui paketid on saadaval. Vahe „kaitstud“ ja „paigatud“ vahel on sel nädalal täiesti konkreetne, ja üht teisena müüa oleks ebaaus.

Kuidas turvapaik ise välja näeb, on hea näide selle kohta, mille eest eespool hoiatasime. Meie serverid said uue ea-php84 järgu sama päeva õhtul, mõni tund pärast PHP väljalaset. Versiooninumber ei muutunud — php -v kirjutab endiselt 8.4.26, mitte 8.4.27, ja ainus, mis väljast muutust näitab, on järgu kuupäev, mis hüppas 9. oktoobrist 21. oktoobrini. Just nii näeb välja üle kantud turvapaik, ja just seepärast on küsimus veebimajutuse pakkujale kasulikum kui number, mida ekraan näitab.

Seepärast ei ole väärtus, mille hallatav veebimajutus siin ostis, haavamatus, vaid kitsam vahe: tunnid, mil ründemuster juba ringles ja katseid juba tehti, kaeti teadaoleva mustri blokeerimisega, mitte ei oodatud ära. Ja pärast seda — et keegi jälgib pakette ja taaskäivitab protsessid, mitte ei oota, kuni klient märkab. Meie hallatav veebimajutus algab 45 € kuus, ja just sellised nädalad on see, mille eest selles summas makstakse.

Kui teie veebileht töötab praegu kuskil, kus küsimusele PHP versiooni ja uuenduse kuupäeva kohta vastust kätte ei saa, on see iseenesest vastus. Räägime üleviimisest — tavaliselt saab selle teha seisakuta.

Pärast uuendamist tuleb taaskäivitada rohkem, kui paistab

Protsess, mis jääb päringute vahel ellu, ei ole mingi eksootika — just nii töötab tavaline PHP-FPM pool ja mod_php, ja just nende vastu on koodi käitus kinnitatud. Seepärast ei ole CVE-2026-109619 mingi erikonfiguratsiooni oht; see on tavalise konfiguratsiooni probleem.

Sellest järeldub samm, mida kõige sagedamini vahele jäetakse: paketi vahetamine ei mõjuta protsessi, mis juba töötab. Pärast uuendamist tuleb taaskäivitada iga protsess, mis PHP-d käitab, ja see käib ka nende kohta, mida keegi tavaliselt ei puutu. Kaua töötavad PHP protsessid kipuvad nädalateks taaskäivitumata jääma, seepärast tasub need pärast uuendamist eraldi üles lugeda ja veenduda, et igaüks neist on uuesti käivitatud.

Õige kontrolliküsimus ei ole seepärast „mida näitab php -v“, vaid „kas iga protsess, mis PHP-d käitab, on käivitatud pärast seda, kui pakett välja vahetati“.

Miks ei piisa sellest, et „me ju ei laadi midagi üles“

Levinud vastuväide kõlab umbes nii: meie veebileht on visiitkaart, seal ei ole ei üleslaadimisvormi ega kasutajakontosid, järelikult see meid ei puuduta. Kahjuks puudutab see, ja põhjus on just see, mida eespool kirjeldati: rünnak ei vaja üles laaditud faili, piisab spetsiaalselt koostatud multipart-päringust, ja selle võib saata igale aadressile, mis vastab PHP-ga. Vormi olemasolu lehel ei ole eeltingimus, sest ründaja vormi ei täida.

Samuti ei ole tähtis, kas veebileht on väike. Rünnakud sellistele turvanõrkustele toimuvad automaatselt ja valimatult üle kogu interneti, ja valikut külastajate arvu järgi ei tee keegi. Palo Alto Networks üksus Unit 42 teatas avalikustamise päeval rohkem kui 22,6 miljonist internetist kättesaadavast PHP instantsist, mis on potentsiaalselt mõjutatud; ühtegi neist ei ole eraldi valitud.

Teine vastuväide käib WordPressi ja pistikprogrammide kohta. Ka see seekord ei pea paika — ainult vastupidises suunas: turvanõrkus on PHP-s endas, mitte WordPressis, Laravelis ega mõnes pistikprogrammis. See tähendab, et pistikprogrammide uuendamine seda probleemi ei lahenda, ja ühtlasi — et mõjutatud on iga PHP veebileht, olenemata sellest, millele see on ehitatud.

Mida sellest nädalast tasub alles hoida

Neil, kellel kõik oli korras, töötas kasuks mitte kiire reageerimine, vaid kolm asja, mis olid varem paika pandud: oli teada, milline veebileht millisel PHP versioonil töötab, oli teada, kes vastutab uuendamise eest, ja olid varukoopiad, mille pealt on päriselt kontrollitud, et veebilehe saab taastada. Ühtegi neist ei saa teha sel päeval, mil hoiatus on juba avaldatud, ja just seepärast oli see nädal ühtedele meeskondadele pool tundi tööd, teistele aga kaks päeva.

Kui sellest nädalast tuleb võtta üks ülesanne, et järgmisel korral oleks kergem, siis on see nimekiri: iga veebileht, selle PHP versioon, viis, kuidas seda käitatakse, selle veebimajutuse pakkuja ja inimene, kes tohib vajutada „uuenda“. Järgmine selline hoiatus tuleb, ja ainus küsimus on, kui kaua siis kulub, et vastata küsimusele „kas see puudutab meid“.