PHP2Shell: miks üks PHP haavatavus ohustab peaaegu iga veebilehte?

21. oktoobril avaldas PHP meeskond parandused kahele kriitilisele haavatavusele, mida ründajad hakkasid ära kasutama juba enne nende avalikustamist. Selgitame, mis on PHP2Shell, milliseid veebilehti see puudutab ja mida tasub teha juba täna.

9.2CVSS v4.0 hinne, mõlemal haavatavusel

0sisselogimist vajab ründaja

5.4+vanim mõjutatud PHP versioon

1,3 mln+potentsiaalselt haavatavat serverit

Enamik veebilehtede turvauudiseid puudutab konkreetset pluginat või platvormi: uuendate ühe komponendi ja probleem on lahendatud. PHP2Shell on teistsugune. Haavatavused on PHP-s endas – programmeerimiskeeles, millel töötavad WordPress, Joomla, Drupal, Magento, PrestaShop, Laravel ja enamik teisi veebilehtede süsteeme. W3Techsi andmetel kasutab PHP-d peaaegu 70% veebilehtedest, mille serveripoolne keel on teada.

Seega pole küsimus seekord „kas kasutan haavatavat pluginat?“, vaid „milline PHP versioon minu veebilehte teenindab ja kas see on juba parandatud?“

Mis on PHP2Shell?

PHP2Shell on nimi, mille teadlased andsid kahe haavatavuse ahelale: CVE-2026-109618 ja CVE-2026-109619. PHP turvameeskond hindas mõlemat CVSS v4.0 skaalal 9.2 punktiga. Algselt internetis levinud hinne 10.0 oli vale, kuid ka 9.2 tähendab kriitilist haavatavust.

Nimi kirjeldab tagajärge. PHP kaudu saab ründaja „shelli“ – võimaluse käivitada Teie serveris käske. Selleks ei vaja ta parooli ega kontot veebilehel: piisab ühest spetsiaalselt koostatud HTTP-päringust.

Teadlased on kinnitanud toimivaid rünnakuid WordPressi, Drupali, Joomla ja Magento veebilehtede vastu. Mõjutatud on kõik viisid, kuidas PHP veebipäringuid teenindab:

PHP-FPM – tänapäevastes serverites kõige levinum;
Apache mod_php – siin peab PHP meeskond riski kõige suuremaks;
php-cgi, LiteSpeed ja FrankenPHP.

Miks turvaplugin Teid ei kaitse

PHP2Shelli kõige olulisem omadus on hetk, mil rünnak toimub. PHP töötleb päringu andmeid juba enne, kui Teie veebilehe kood käivitub. Seetõttu ei saa ükski veebilehe sees töötav kaitse rünnakust isegi teada.

Päringu teekond Teie veebileheni

Vajutage nuppu ja vaadake, kus rünnak peatub. Kihil klõpsates näete, mida see suudab teha.

Spetsiaalselt koostatud HTTP POST päring. Väliselt tavaline liiklus, mis ei vaja sisselogimist ega kontot.
Võib blokeerida tuntud rünnakumustreid, kuid ainult seda läbivale liiklusele. Uued variandid võivad läbi lipsata ja kui server on otse IP-aadressi kaudu kättesaadav, jäetakse WAF täielikult vahele.
Edastab päringu PHP-le. Päringute suuruse piiramine sellel tasemel vähendab ühe tuntud rünnakuviisi riski, kuid haavatavust ei kõrvalda.
Just siin peitub haavatavus. PHP loeb ja töötleb päringu andmeid enne Teie veebilehe koodi käivitamist, seega käivitub ründaja kood just selles etapis.
Veebilehe süsteem ei jõua isegi käivituda. Pole vahet, kas see on uuendatud või mitte.
Pole midagi peatada: rünnak toimus enne, kui need kaitsed sisse lülitusid.

Järeldus on lihtne: ainus täielik lahendus on uuendada PHP-d ennast. Kõik muu on ajutised meetmed, mis aitavad aega võita.

Kaks haavatavust, üks ahel

Mõlemad haavatavused on seotud sellega, kuidas PHP päringuid töödeldes mälu haldab. Veebilehe omanik ei pea tehnilisi üksikasju teadma, kuid tasub mõista, mille poolest need erinevad, sest ajutised kaitsemeetmed on kummalgi erinevad.

Mälupuuduse viga · CVSS 9.2

Kui PHP-l saab mälu otsa kohe, kui ta hakkab POST-päringut lugema, jääb osa sisemisi andmeid poolikuks. Päringu lõpus käsitleb PHP neid nii, nagu need oleksid korras, kuigi nende sisu kontrollib ründaja. See avab tee oma koodi käivitamiseks.

Lihtsalt öeldes: ründaja „koormab“ PHP teadlikult üle ja kasutab ära sellest järele jäänud segaduse.

Ajutine meede: memory_limit=-1 serveri tasemel ja päringute suuruse piirang veebiserveris.

Vabastatud mälu kasutamine · CVSS 9.2

Pärast ühte päringut võib PHP protsessi jääda viide juba vabastatud mälule. Järgmine päring, mida teenindab sama protsess, kasutab seda mälu. Nii saab lekitada mälu sisu ja käivitada koodi. Haavatavus on kättesaadav seansi üleslaadimise edenemise funktsiooni kaudu, mis on vaikimisi sisse lülitatud.

Lihtsalt öeldes: üks päring jätab maha „prahti“ ja järgmine kasutab selle ära.

Ajutine meede: session.upload_progress.enabled=0, PHP 8.5 puhul ka fatal_error_backtraces=0.

Kuidas kõik toimus

2024
Esimese mitme aasta järel tehtud välise PHP turvaauditi käigus märkab meeskond esimesi märke mäluprobleemist, millest hiljem sai CVE-2026-109618. Toimivat ründeviisi siis ei leita, avalikult sellest ei teatata ja parandus jääb toppama. PHP Foundation tunnistas hiljem, et selline viivitus oli viga.
11. august 2026
Califi ja OpenAI teadlased teatavad teineteisest sõltumatult PHP meeskonnale, et sama probleemi kaudu saab serveris koodi käivitada. Parandamine saab prioriteediks.
17. oktoober
Amazoni ohuluure registreerib oma meepotivõrgus esimese ärakasutamiskatse – neli päeva enne avalikustamist.
20. oktoober
CVE-numbrid lekivad avalikkuse ette. PHP meeskond avaldab eelteate kriitilise turvauuenduse kohta.
21. oktoober
Lekke tõttu avaldatakse parandatud versioonid 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 päev plaanitust varem. Cloudflare teatab esimestest rünnakutest ja võtab kasutusele ajutised WAF-reeglid.
Praegu
Rünnakuid tuleb aina juurde ja neid teevad mitu erinevat osapoolt. Amazon soovitab sissetungi märke otsida alates 17. oktoobrist, mitte avalikustamise päevast.

Mida see Teie jaoks tähendab: isegi kui uuendasite PHP eile, võis veebileht olla varem rünnaku ohvriks langenud. Parandus sulgeb ukse, kuid ei vii välja seda, kes jõudis juba sisse tulla.

Kas Teie veebileht on haavatav?

Haavatav on iga veebileht, mida teenindab parandamata PHP versioon. Järgmistel versioonidel on parandus juba olemas:

PHP haru	Turvaline versioon
PHP 8.5	8.5.12 või uuem
PHP 8.4	8.4.27 või uuem
PHP 8.3	8.3.36 või uuem
PHP 8.2	8.2.35 või uuem
PHP 7.4–8.1	Ametlikku parandatud versiooni pole. Tuleb uuendada versioonile 8.2+ või kasutada tarnija parandatud paketti.
PHP 5.4–7.3	Enam ei toetata, parandust ei tule. Uuendamine on hädavajalik.

Kontrollige oma PHP versiooni

Sisestage PHP versioon

Näited:

Kust leida PHP versioon?

Hostimise halduspaneelis (cPanel, DirectAdmin, Plesk) – jaotises „PHP versioon“ või „Select PHP Version“.
WordPress: Tööriistad → Saidi tervis → Info → Server.
Küsige hostimisteenuse pakkujalt – ja küsige ühtlasi, kas Teie PHP paketile on parandus juba paigaldatud.

Kui loote versiooni vaatamiseks phpinfo() faili, kustutage see kohe pärast seda – see paljastab serveri kohta palju teavet.

Miks versiooninumber võib eksitada

Linuxi distributsioonid paigaldavad paranduse sageli versiooninumbrit muutmata. Seega „vana“ number ei tähenda veel, et PHP on haavatav.
Käsureal nähtav PHP võib erineda sellest, mis tegelikult veebilehte teenindab.
Jagatud hostimises võib korraga töötada mitu PHP versiooni ja erinevad domeenid võivad kasutada erinevaid.

Riskitest 30 sekundiga

Vastake viiele küsimusele. Kui Te vastust ei tea, valige „Ei tea“ – ka see on oluline vastus.

Kas teate, milline täpne PHP versioon Teie veebilehte teenindab?
Kas PHP-d on uuendatud pärast 21. oktoobrit või on tarnija kinnitanud, et parandus on paigaldatud?
Kas veebileht töötab PHP 8.1 või vanema versiooniga?
Kas keegi on serveri logid ja failid alates 17. oktoobrist juba üle vaadanud?
Kas veebilehel on e-pood, kliendikontod või isikuandmed?

Vastatud 0 / 5

Telli PHP2Shelli audit

Mida saate teha juba täna

Selgitage välja täpne PHP versioon, mis Teie veebilehte teenindab, ja võrrelge seda ülaltoodud tabeliga.
Uuendage PHP parandatud versioonile või paluge seda teha hostimisteenuse pakkujal. Enne uuele harule üleminekut tehke varukoopia ja kontrollige, kas veebileht, teema ja pluginad sellega töötavad.
Kui Te ei saa kohe uuendada, lülitage sisse PHP meeskonna soovitatud ajutised meetmed (vt allpool) ja taaskäivitage kõik PHP protsessid.
Kontrollige, kas veebilehte pole juba rünnatud: tundmatud PHP-failid, uued administraatorid, veebilehe protsesside käivitatud shellid, mälu ammendumise vead „on line 0“ logides – alates 17. oktoobrist.
Kasutage WAF-i lisakihina, mitte parandusena. See kaitseb ainult seda liiklust, mis seda läbib.

Ajutised meetmed PHP konfiguratsioonis:

memory_limit = -1                  ; CVE-2026-109618
session.upload_progress.enabled = 0  ; CVE-2026-109619
fatal_error_backtraces = 0         ; ainult PHP 8.5

memory_limit tuleb seadistada nii, et rakendused ei saaks seda muuta (nt php_admin_value kaudu PHP-FPM seadetes). Kuna see eemaldab PHP mälupiirangu, soovitab PHP meeskond tagada selle konteineri või cgroupi tasemel ja piirata päringute suurust veebiserveris. Need meetmed vähendavad riski, kuid ei muuda PHP-d turvaliseks.

Millal tasub pöörduda spetsialisti poole

PHP uuendamine võtab sageli vaid mõne minuti. Keerulisem on vastata kolmele küsimusele: kas parandus töötab tõesti just Teie veebilehte teenindavas PHP-s, kas veebileht töötab uue versiooniga ja kas keegi ei kasutanud haavatavust varem ära.

Just seda kontrollib Redfox Cloudi PHP2Shelli audit. Teie veebilehte kontrollib käsitsi serveriinsener, mitte automaatne skanner, ja tulemused saate kirjalikult, arusaadavas keeles. Te ei pea olema meie hostimise klient.

PHP2Shelli audit

29 € + KM

Täpne PHP versioon ja SAPI, mis Teie domeeni teenindab
Kas tarnija on Teie PHP paketile paranduse paigaldanud
Vealogid ja sissetungi märgid alates 17. oktoobrist
Teie sisuhaldussüsteemi ja pluginate risk
Kirjalik aruanne ja paranduse hind

Telli hinnaga 29 €

Täielik turvaaudit

199 € + KM

Kõik, mis kuulub PHP2Shelli auditisse
Süsteemipaketid, tuum ja teadaolevad CVE-d
Serveri, tulemüüri, SSH, TLS-i ja PHP konfiguratsioon
Sisuhaldussüsteemi, pluginate, teemade ja eritellimusel koodi turvavead
Pahatahtlik kood, tagauksed, tundmatud cron-tööd

Telli hinnaga 199 €

Võtame ühendust 2 tööaja tunni jooksul pärast makse laekumist (E–R 9:00–18:00 Leedu aja järgi). Makse on ühekordne. Paranduse hinna esitame pärast auditit ja Teie otsustate, kas töö teeme meie.

Korduma kippuvad küsimused

Kas piisab sellest, et hostimisteenuse pakkuja uuendas PHP-d?

Kui tarnija kinnitab, et parandus on paigaldatud just sellele PHP versioonile, mis Teie veebilehte teenindab, on kõige olulisem samm tehtud. Kuid jagatud hostimises töötab sageli mitu PHP versiooni ja parandus ei kustuta sissetungi jälgi, kui rünnak toimus varem. Seetõttu tasub üle vaadata ka logid alates 17. oktoobrist.

Kas Cloudflare või muu WAF kaitseb mind?

Ainult ajutiselt ja ainult osaliselt. WAF blokeerib tuntud rünnakumustreid seda läbivale liiklusele. Kui server on otse IP-aadressi kaudu kättesaadav või ilmub uus rünnakuvariant, WAF ei aita. Probleemi lahendab ainult PHP uuendamine.

Minu veebileht töötab PHP 7.4, 8.0 või 8.1 peal. Mida teha?

Nendele versioonidele ametlikke parandatud väljalaskeid pole – PHP meeskond avaldas ainult lähtekoodi parandused neile, kes kompileerivad PHP ise. Kõige turvalisem tee on uuendada PHP 8.2 või uuemale versioonile. Enne seda tasub kontrollida, kas veebileht ja pluginad uue versiooniga töötavad.

Kuidas aru saada, kas veebilehte on juba häkitud?

Levinumad märgid on tundmatud PHP-failid, uued administraatorid, kummalised ümbersuunamised, veebilehe protsesside käivitatud käsud ja korduvad mälu ammendumise vead „on line 0“ vealogides. Mõned märgid on nähtavad ainult serveri tasemel, seega ainult veebilehte vaadates võib need märkamata jätta.

Kas saan oma veebilehte kontrollida internetis avaldatud ründekoodiga?

Me ei soovita seda. Avalikult levitatava koodi toimimine pole kinnitatud ja selline kood on mõnikord ise pahavaraga nakatunud. Turvalisem on kontrollida PHP versiooni, paranduse olekut ja logisid.

Kas teate, milline PHP versioon Teie veebilehte praegu teenindab – ja kas keegi pole seda enne Teid ära kasutanud?