PHP2Shell on nimi kahdelle vakavalle PHP-ohjelmointikielen haavoittuvuudelle: CVE-2026-109618:lle ja CVE-2026-109619:lle. Tietyissä tilanteissa niitä voidaan käyttää koodin suorittamiseen haavoittuvalla palvelimella ilman kirjautumista. PHP julkaisi korjaukset 21. lokakuuta 2026. Osa organisaatioista sulki palvelujaan tai rajoitti niiden käyttöä varotoimena. Havaitut skannaukset ja hyökkäysyritykset eivät kuitenkaan itsessään todista onnistunutta murtoa.
4
7
18
Mitä PHP2Shell-haavoittuvuuksista tiedetään?
Haavoittuvuudet ovat PHP:n ydinohjelmistossa, eivät yksittäisessä verkkosivustossa käytettävässä lisäosassa tai sovelluksessa. Toinen liittyy muistin loppumisen käsittelyyn, toinen vanhentuneeseen globaaliin tilaan. Tietyissä olosuhteissa muotoiltu verkkopyyntö voi johtaa koodin etäsuoritukseen; toinen haavoittuvuus voi myös paljastaa arkaluonteista tietoa prosessin muistista.
4
11
PHP:tä käytetään laajasti verkkopalveluissa. Joidenkin arvioiden mukaan se on käytössä jopa 70 prosentilla verkkosivustoista, mutta luku ei tarkoita, että kaikki PHP-sivustot olisivat haavoittuvia tai yhtä suuressa vaarassa. Riski riippuu muun muassa käytössä olevasta PHP-versiosta, asetuksista ja siitä, voiko hyökkääjä päästä käsiksi haavoittuvaan toimintoon.
45
46
Tutkimus, tekoäly ja kiirehtinyt julkistus
Haavoittuvuuksien löytämiseen ja korjaamiseen osallistuneiksi on raportoitu Wiz, Calif ja OpenAI. Osa uutisoinnista on kuvannut tekoälyn osuutta tutkimustyössä. Saatavilla olevat lähteet eivät kuitenkaan vahvista kaikkia löytöihin liitettyjä yksityiskohtia, kuten väitettyä WordPressistä Drupal-kohteeseen edennyttä tutkimusketjua tai sitä, mikä ryhmä löysi kummankin haavoittuvuuden.
14
45
Tapausta koskevien tietojen mukaan taustalla ollut muistinkäsittelyn ongelma oli havaittu jo aiemmin, mutta sen mahdollisuutta johtaa etäkoodin suoritukseen ei ollut tuolloin osoitettu. Ero on olennainen: virheen huomaaminen ei vielä tarkoita, että sen avulla olisi osoitettu toimiva hyökkäysreitti.
22
38
Haavoittuvuuksien tietoja vuoti julkisuuteen ennen suunniteltua julkistusta. Tämä lisäsi painetta ja vauhditti korjausten julkaisemista.
6
23 Tapaus havainnollistaa, miten nopeasti teknisestä tietoturvaongelmasta voi tulla palveluiden ylläpitoon liittyvä kiiretilanne, kun tiedon varmistaminen ja korjausten asentaminen on tehtävä tiiviissä aikataulussa.
Korjaukset ja hyökkäysyritykset – mitä niistä voi päätellä?
Lokakuun 21. päivänä julkaistut korjatut PHP-versiot olivat 8.2.35, 8.3.36, 8.4.27 ja 8.5.12. Tarkista myös oman käyttöjärjestelmä- tai palveluntarjoajasi tietoturvatiedote: jotkin toimittajat jakavat korjaukset takautuvasti vanhempiin ohjelmistopaketteihin, jolloin versionumero ei välttämättä vastaa suoraan PHP:n omaa julkaisunumeroa.
4
39
Tietoturvayhtiöt raportoivat skannauksista ja hyväksikäyttöyrityksistä julkistuksen aikoihin. Cloudflareen liittyvässä uutisoinnissa kuvattiin yritysten määrän kasvaneen nopeasti. Havaitut lukumäärät kertovat kuitenkin tiettyjen palveluiden näkemistä pyynnöistä ja yrityksistä, eivät murrettujen järjestelmien määrästä.
5
36
Arviot onnistuneista hyökkäyksistä vaihtelivat. BBC kertoi 22. lokakuuta, ettei onnistuneista hyväksikäytöistä ollut raportoitu. Beazleyn myöhemmän tiedotteen mukaan laajoista yrityksistä oli raportoitu, mutta se ei ollut tietoinen vahvistetusta laajamittaisesta hyväksikäytöstä. Myös Sansec arvioi myöhemmin, että laajamittainen hyväksikäyttö vaikutti odotettua epätodennäköisemmältä. Arviot kuvaavat tilannetta julkaisuhetkellä – ne eivät tee korjaamattomasta palvelimesta turvallista.
7
9
18
Miksi osa palveluista suljettiin?
Osa organisaatioista rajoitti palvelujaan tai otti niitä tilapäisesti pois käytöstä arvioidessaan altistumista ja valmistellessaan päivityksiä. Uutisoinnin mukaan Britannian hallinto sulki 32 palvelua. Palveluiden tilaa seuraava StatusGator puolestaan kirjasi yli sadan palvelun ilmoittaneen katkosta, huoltotöistä tai PHP2Shell-varoituksesta ennen korjauksen julkaisua. Nämä toimet kertovat kiireellisen korjaamisen aiheuttamista häiriöistä, eivät siitä, että palveluihin olisi hyökätty onnistuneesti.
22
34
Myös muiden maiden viranomaisten ja organisaatioiden toimista kerrottiin. Saatavilla olevien tietojen perusteella ei kuitenkaan voi muodostaa kattavaa, riippumattomasti varmennettua listaa kaikista vaikutuksen saaneista palveluista tai vahvistaa jokaista nimettyä paikallista katkosta.
20
25
Mitä verkkopalveluiden ylläpitäjän kannattaa tehdä?
- Selvitä, missä kaikkialla PHP:tä käytetään. Tarkista tuotantopalvelimet, kontit, varajärjestelmät ja ulkoistettu hosting – ei vain pääsivustoa.
- Asenna sopiva korjaus viipymättä. Käytä korjattua PHP-versiota tai toimittajan vahvistamaa takautuvaa korjausta. Käynnistä PHP-prosessit tai palvelut tarvittaessa uudelleen ja varmista, että korjaus on käytössä. Sovelluksen tai lisäosan päivitys ei yksin korjaa PHP-ympäristöä.
14
39
- Rajoita altistumista, jos korjausta ei saada heti asennettua. Palvelun julkista käyttöä voi rajoittaa tai sen voi sulkea tilapäisesti riskin ja palvelun liiketoimintamerkityksen perusteella. Verkkosäännöt ovat väliaikainen suoja, eivät korjauksen korvike.
- Tarkista mahdolliset murtojäljet. Käy läpi olennaiset lokit ja etsi odottamattomia tiedostoja, prosesseja tai ylläpitotilejä. Jos epäilet murtoa, säilytä tutkinnassa tarvittava aineisto ja selvitä tapahtumat: päivitys ei poista jo tapahtunutta tunkeutumista.
- Varmista korjaus palveluntarjoajalta. Hosting- tai hallintapalvelua käyttävän organisaation kannattaa pyytää selkeä vahvistus siitä, että kaikki sen käytössä olevat PHP-ympäristöt on korjattu.
Yhdysvaltain NSA suositteli kriittisten korjausten asentamista ja kertoi priorisoivansa PHP2Shelliä mahdollisesti hyödyntävien toimijoiden tunnistamista. FBI kehotti niin ikään organisaatioita päivittämään PHP-asennuksensa. Käytettävissä olevat lähteet eivät kuitenkaan osoita, että FBI, NSA ja CISA olisivat antaneet yhteisen määräyksen sulkea kaikki järjestelmät, jos korjausta ei pystytä asentamaan.
17
28
Mitä tavallinen käyttäjä voi tehdä?
Pidä omat laitteet, sovellukset ja reititin ajan tasalla. Käytä monivaiheista tunnistautumista ja jokaisessa palvelussa eri salasanaa. Nämä ovat hyviä yleisiä tietoturvakäytäntöjä, mutta ne eivät korjaa verkkosivuston PHP-palvelinta – siitä vastaa sivuston ylläpitäjä tai palveluntarjoaja.
PHP2Shellin käytännön opetus on selvä: korjaukset pitää asentaa nopeasti ja niiden käyttöönotto varmistaa. Tapaus muistuttaa, että tietoturvatutkimus, julkistus ja hyökkäysyritykset voivat edetä lyhyessä ajassa. Havaitut yritykset eivät silti ole sama asia kuin vahvistetut laajat murrot, eikä näyttö tue väitettä koko verkon tietoturvan romahtamisesta.