PHP2Shell: kriitilised PHP lüngad – nii paigate kohe

21. oktoober 2026 | PHP | IT-turvalisus

21. oktoobril 2026 avaldas PHP turvameeskond värskendused kõigile veel toetatud PHP versioonidele. Need sulgevad kaks kriitilist haavatavust, mis on saanud tuntuks nimega PHP2Shell. BSI on selle kohta hoiatuse välja andnud ja nõuab mõjutatud süsteemide viivitamatut paikamist. Kes käitab PHP-ga veebiserverit, peaks tegutsema juba täna. See kehtib ka kõigi kohta, kes käitavad „ainult“ WordPressi, Nextcloudi või Joomlat, sest need rakendused töötavad PHP peal.

See artikkel võtab kokku, mis juhtus, millised PHP versioonid on mõjutatud, millist versiooni te nüüd vajate ja kuidas te mõne minutiga kontrollite, kas teie server on kaitstud.

Mis juhtus? Ajaline kulg

PHP turvameeskond kuulutas paranduste avaldamise ette ära, et hostijatel ja administraatoritel oleks aega valmistuda. Avaldamine ise toimus 21. oktoobril 2026. BSI andis oma hoiatuse (versioon 1.1) välja samal päeval.

• 20. oktoober 2026: PHP turvameeskonna eelhoiatus, et järgmisel päeval ilmuvad turvavärskendused.
• 21. oktoober 2026, 14:00 UTC (16:00 CEST): PHP 8.5, 8.4, 8.3 ja 8.2 paigad avaldatakse.
• 21. oktoober 2026: BSI hoiatab „kriitiliste haavatavuste eest, mis ohustavad veebirakendusi kogu maailmas“, ja soovitab viivitamatult paikata. BSI andmetel on suured hostimisteenuse pakkujad osaliselt servereid ennetavalt võrgust maha võtnud.

Kaks PHP haavatavust ülevaatena

Tegemist on kahe eraldi veaga PHP tuumas: CVE-2026-109618 ja CVE-2026-109619. Mõlemad võivad PHP turvameeskonna andmetel viia selleni, et ründaja saab serveris programmikoodi täita ilma sisse logimata (unauthenticated Remote Code Execution). Haavatavusi hinnatakse CVSS v4.0: 9,2 (kriitiline).

BSI hinnangul ei olnud avaldamise ajal kinnitatud rünnakuid, kuid esines kinnitamata viiteid ärakasutamiskatsetele. Kriitiliste lünkade korral nii laialt levinud tarkvaras tuleb kogemuse põhjal arvestada, et ründajad analüüsivad paranduse ja valmistavad ette automatiseeritud rünnakuid. Paikamise ajaaken on seetõttu lühike.

Keda see mõjutab?

Mõjutatud on põhimõtteliselt iga server, kus PHP töötab, sõltumata sellest, kuidas PHP on ühendatud: PHP-FPM, mod_php Apache'is, php-cgi, FrankenPHP või LiteSpeed. PHP turvameeskonna sõnul on risk suurim Apache'i koos mod_php-ga puhul.

BSI nimetab sõnaselgelt rakendusi, mis põhinevad PHP-l ja võivad seetõttu olla kaasmõjutatud:

• Sisuhaldussüsteemid: WordPress, Drupal, TYPO3, Joomla
• Poesüsteemid: Magento
• Pilve- ja failihoidla: Nextcloud
• Tulemüüri liidesed: pfSense, OPNsense

Rakendus ise ei pea selleks vigane olema. Lünk on PHP-s, seetõttu ei aita WordPressi, Nextcloudi & Co. värskendus üksi mitte. Serveris tuleb värskendada PHP versiooni. Tulemüüride nagu pfSense ja OPNsense puhul tuleb parandatud PHP versioon vastava tootja püsivara värskendusega.

Need PHP versioonid on turvalised

Haavatavused on parandatud järgmistes versioonides. Kõike sellest madalamat peetakse haavatavaks.

Nii kontrollite ja värskendate oma serverit

1. Paigaldatud PHP versiooni tuvastamine

Serveri käsureal näitab php -v käsurea-PHP versiooni. Veebiserver võib kasutada teistsugust PHP versiooni. Kontrollige seetõttu ka PHP-FPM-i või Apache'i mooduli versiooni, näiteks käsuga php-fpm8.3 -v või lehe kaudu, mis väljastab phpinfo() (selle eemaldage seejärel kohe uuesti).

2. Värskenduse paigaldamine paketihalduse kaudu

Debiani, Ubuntu, RHEL-i ja sugulaste puhul tuleb parandatud versioon tavalise paketihalduse kaudu, näiteks apt update && apt upgrade või dnf upgrade. Kolmandate osapoolte allikate nagu Sury PPA või Remi repositooriumi puhul ilmuvad uued paketid enamasti kiiresti.

3. PHP teenuse taaskäivitamine

Üksi paketivärskendusest ei piisa: töötavad PHP protsessid hoiavad vana koodi mälus. Käivitage PHP-FPM (systemctl restart php8.3-fpm) või Apache (systemctl restart apache2) uuesti ja kontrollige seejärel, kas protsessid käivitati pärast värskendust.

4. Hostitud veebilehed

Jagatud hostingu (shared hosting) puhul värskendab reeglina pakkuja. Kliendimenüüs saab enamasti seadistada PHP versiooni veebilehe kaupa. Valige seal üks ülalnimetatud turvalistest versioonidest või küsige pakkujalt paikamise seisu. BSI andmetel on üksikud pakkujad servereid ennetavalt võrgust maha võtnud. Kui teie leht on korraks kättesaamatu, võib see olla põhjus.

PHP 8.1 ja vanem: ametlikku värskendust pole

PHP 8.1 ja vanema jaoks ametlikke turvavärskendusi enam ei ole. Selliste süsteemide käitajatel on kaks võimalust:

• Üleminek toetatud versioonile (soovitatav). Mida vanem versioon, seda suurem on rakenduse ja laienduste kohandamise vaev, seetõttu tuleks üleminekut enne testida.
• Parandused tagasi portida. PHP turvameeskond on parandused GitHubis arendusharudes kättesaadavaks teinud. Kes PHP-d ise kompileerib, võib need muudatused vanematesse versioonidesse üle võtta. See on üleminekulahendus ja nõuab erialateadmisi.

Ka PHP 8.2 on toetatud ainult kuni 31. detsembrini 2026. Planeerige üleminek PHP 8.4-le või 8.5-le seetõttu nüüd ja ärge lükake seda aastavahetusele.

Üleminekumeetmed ja küsimus „Server võrgust maha võtta?“

PHP turvameeskond on teatega kirjeldanud ka ajutisi kaitsemeetmeid. Need vähendavad riski, kuid ei sulge lünki täielikult. Need ei asenda värskendust ja on mõeldud ainult värskenduseni jääva aja ületamiseks.

Kas server tuleks kuni värskenduseni võrgust maha võtta, sõltub selle tähtsusest ja kättesaadavusest. BSI märgib, et suured pakkujad on selle sammu astunud. Rusikareegel on:

• Avalikult kättesaadav server, värskendus on nüüd võimalik: paikake kohe, väljalülitamine pole vajalik.
• Avalikult kättesaadav server, värskendus lühiajaliselt võimatu: piirake ligipääsu (näiteks tulemüüri abil ainult tuntud aadressidele) või lülitage teenus ajutiselt välja, eriti mod_php korral.
• Ainult sisemiselt kättesaadav server: paikake lähiajal, kiireloomulisus on väiksem.

Korduma kippuvad küsimused

Kas pean WordPressi, Joomlat või Nextcloudi uuendama?

Mitte selle haavatavuse pärast. See asub PHP-s, mitte rakenduses. Uuendage serveris PHP versiooni. Rakenduse uuendamine on sellest sõltumata siiski mõistlik.

Kuidas tuvastada, kas keegi on haavatavust juba ära kasutanud?

Kindlat vastust on raske anda. Kahtlust äratavad tundmatud PHP-failid veebikataloogis, ebatavalised protsessid veebiserveri kasutaja all, uued kasutajakontod või cron-tööd ning ebatavaline väljaminev andmeliiklus. Konkreetse kahtluse korral tuleks süsteem forensiliselt üle vaadata ja kahtluse korral uuesti üles seada.

Kas veebirakenduste tulemüürist piisab?

Tulemüür võib tuntud ründemustreid tõrjuda, kuid ei asenda uuendust. Rohkem mitme kaitsekihi koostoimest saate lugeda meie artiklist Odoo 19 turvamine: tulemüür, 2FA & Web RBL. Põhimõtted kehtivad iga veebirakenduse puhul.

Kas Odoo on mõjutatud?

Ei. Odoo on kirjutatud Pythonis ja ei tööta PHP peal. Mõjutatud oleksid ainult PHP-rakendused, mis töötavad samas serveris.

Kust leian ametlikku teavet?

PHP turvameeskonna teate leiate php.net uudistearhiivist (kanne 20. oktoobrist 2026), versioonid aadressilt php.net/downloads. BSI hoiatuse number on 2026-297981-1032 ja see on avaldatud aadressil bsi.bund.de .

Biricon IT Services'i tugi

Kui te pole kindel, millist PHP versiooni teie server kasutab, või vajate abi paikamisel, aitame teid hea meelega: kõigi PHP-süsteemide inventeerimisel, uuenduste paigaldamisel, üleminekul toetatud PHP versioonile ja kompromiteerimise kontrollimisel. IT-teenusepakkujana hooldame väikeste ja keskmise suurusega ettevõtete servereid, tulemüüre ja veebirakendusi.

Võtke meiega ühendust

Seisuga: 21. oktoober 2026. Olukord võib lühikese aja jooksul muutuda; määrava tähtsusega on PHP turvameeskonna ja BSI avaldatud teave.