PHP2Shell: miksi PHP:n haavoittuvuus oli iso juttu ja voiko WordPressiin yhä luottaa

PHP julkaisi 21.10.2026 hätäpäivityksen kahteen kriittiseen haavoittuvuuteen, joille on annettu yhteinen nimi PHP2Shell (CVE-2026-109618 ja CVE-2026-109619). Niiden avulla hyökkääjä voi pahimmillaan ajaa omaa koodiaan palvelimella ilman kirjautumista. Korjatut versiot ovat PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Jos sivustosi pyörii PHP:llä, eli esimerkiksi WordPressillä, WooCommercella tai Laravelilla, varmista heti, että palvelimen PHP on päivitetty. WordPressin oma päivitys ei tätä korjaa.

Miksi tästä tuli niin iso hässäkkä?

Tavallisesti haavoittuvuus on yksittäisessä lisäosassa tai sovelluksessa ja se koskee vain niitä, jotka sitä käyttävät. Nyt vika oli PHP:ssä itsessään. PHP:n tiedotteen mukaan se koskee kaikkia verkkopyyntöjä palvelevia PHP-asennuksia, ajettiinpa PHP:tä PHP-FPM:llä, Apachen mod_php:llä, php-cgi:llä, FrankenPHP:llä tai LiteSpeedillä. Riski on suurin mod_php:llä, jossa hyökkäys voi käynnistyä yhdellä pyynnöllä ennen kuin sovelluksen koodia on ajettu lainkaan.

Haavoittuvuudet löytänyt Wiz Research kertoo, että ne ulottuvat lähes kaikkiin PHP-versioihin aina 5.4:stä asti. Wiz osoitti toimivan hyökkäyksen WordPressiä, Drupalia ja Joomlaa vastaan. Kun PHP pyörittää valtaosaa verkkosivuista, haavoittuvien palvelimien määrä on valtava.

Teknisesti kyse on muistinhallinnan virheistä. Kun PHP:n muisti loppuu kesken pyynnön käsittelyn, sisäinen tila voi jäädä puolivalmiiksi tai viitata jo vapautettuun muistiin. Seuraava pyyntö samassa prosessissa voi sitten käyttää tätä rikkinäistä tilaa. Wizin mukaan samalla tavalla voi myös vuotaa muistin sisältöä, kuten salasanoja ja avaimia.

Tilannetta pahensi vuoto. Julkistuksen piti tapahtua torstaina 22.10., mutta Huntressin mukaan tiedot haavoittuvuuksista ilmestyivät Hacker Newsiin jo maanantaiaamuna 20.10. Viesti poistettiin, mutta kuvakaappaukset ehtivät levitä. PHP aikaisti julkaisua yhdellä päivällä ja ilmoitti korjausten tulevan keskiviikkona 21.10.

Mitä paikkaaminen vaati?

Tämän tapauksen tärkein asia on se, että WordPressin, teeman tai lisäosien päivitys ei auta. Korjaus pitää asentaa palvelimelle, eli sen tekee ylläpitäjä tai hosting-palvelu.

Hallinnoidussa hostingissa palveluntarjoaja hoitaa päivityksen. Esimerkiksi Seravo ilmoitti, ettei sen asiakkaiden tarvitse tehdä mitään.
Omalla palvelimella tai VPS:llä PHP pitää päivittää itse heti, kun käyttöjärjestelmän paketit ovat saatavilla. Sen jälkeen PHP-prosessit pitää käynnistää uudelleen.
Vanhoilla PHP-versioilla tilanne on hankalin. PHP 8.1 ja sitä vanhemmat eivät saa enää virallisia päivityksiä. PHP julkaisi versioille 7.4–8.1 vain lähdekooditason korjaukset, joten käytännössä ainoa kestävä ratkaisu on nostaa PHP vähintään versioon 8.2.

PHP:n tiedote listaa asetuksia, jotka pienentävät riskiä, mutta painottaa, etteivät ne tee asennuksesta turvallista. Ainoa kunnollinen korjaus on päivitys.

Mitä paikkauksen jälkeen kannattaa tarkistaa?

Kun PHP on päivitetty, uusia hyökkäyksiä näitä aukkoja vastaan ei enää voi tehdä. Jos sivusto oli kuitenkin haavoittuvana verkossa vuodon ja paikkauksen välillä, kannattaa tarkistaa jälkikäteen ainakin nämä:

onko WordPressiin ilmestynyt uusia pääkäyttäjiä
onko palvelimelle tullut tiedostoja tai muuttunut koodia, jota et tunnista
näkyykö lokeissa poikkeavia pyyntöjä tai virheitä 20.–21.10. välillä.

Koska haavoittuvuus voi vuotaa muistin sisältöä, mieti myös salaisuuksien vaihtamista: tietokannan salasana, wp-config.php:n avaimet sekä rajapinta-avaimet esimerkiksi maksupalveluun tai ERP:hen. Tiedot hyökkäyksistä ovat ristiriitaisia. watchTowr kertoo havainneensa hyödyntämistä houkutuspalvelimillaan jo 21.10., kun taas Huntress ei ollut nähnyt hyökkäyksiä asiakkaillaan vielä saman päivän iltapäivänä. Kannattaa olettaa, että aukkoja yritetään hyödyntää. Tarkistukset kannattaa tehdä sen mukaan.

Kuinka nopeasti seuraava aukko löytyy?

Todennäköisesti aiempaa nopeammin. Wiz kertoo käyttäneensä tekoälymalleja haavoittuvuuksien etsimiseen ja hyökkäyksen rakentamiseen ja yksi tutkija teki noin viikossa työn, johon olisi aiemmin mennyt huippuryhmältä kuukausia. Wiz arvioi myös, että samasta virhetyypistä on todennäköisesti muitakin muunnelmia.

Sama työkalu toimii molempiin suuntiin. Tekoäly auttaa löytämään vuosia piilossa olleita vikoja ennen kuin niitä käytetään hyväksi, mutta se myös lyhentää aikaa julkistuksesta toimivaan hyökkäykseen. Sivuston omistajalle tämä tarkoittaa sitä, että päivitykset pitää saada asennettua päivissä, ei kuukausissa.

Pitäisikö WordPressistä ja PHP:stä luopua?

Minun vastaukseni on ei. Kriittisiä haavoittuvuuksia löytyy jokaisesta laajasti käytetystä alustasta. Javan Log4Shell vuonna 2021 on hyvä esimerkki siitä, että sama voi tapahtua missä tahansa. Alustan vaihtaminen ei poista riskiä, vaan vaihtaa sen toiseen.

Olennaisempaa on, miten sivustoa ylläpidetään. Tämän tapauksen jälkeen kysyisin omalta sivustoltani nämä asiat:

Onko PHP tuettu versio? PHP 8.2 saa tietoturvakorjauksia vain vuoden 2026 loppuun asti, joten 8.3 tai uudempi on parempi valinta jo nyt.
Kuka päivittää palvelimen ja kuinka nopeasti? Hallinnoitu hosting, kuten WordPress-sivustoille Seravo tai Laravel-sovelluksille Laravel Cloud, hoitaa tämän puolestasi. Omalla palvelimella sinun pitää tietää, kuka sen tekee.
Seurataanko tilannetta? Joku seuraa tietoturvatiedotteita ja huomaa, kun on kiire.

PHP:n tietoturvatiimi toimi tässä tapauksessa nopeasti: korjaukset julkaistiin noin vuorokausi vuodon jälkeen ja Linux-jakeluille ja tukipalveluille ne oli toimitettu etukäteen. Ongelma ei siis ollut PHP:n ylläpidossa vaan siinä, kuinka moni sivusto pyörii vanhalla versiolla tai palvelimella, jota kukaan ei aktiivisesti päivitä.

Usein kysyttyä

Korjaako WordPressin päivitys PHP2Shell-haavoittuvuuden?

Ei. Haavoittuvuus on PHP:ssä, ei WordPressissä. PHP pitää päivittää palvelimelle versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai uudempaan. Kysy hosting-palvelultasi, onko päivitys tehty.

Mistä näen, mikä PHP-versio sivustollani on?

WordPressissä se näkyy kohdassa Työkalut → Sivuston terveys → Tiedot → Palvelin. Hosting-palvelun hallintapaneelissa näkyy yleensä myös käytössä oleva versio. Pelkkä versionumero, esimerkiksi 8.3, ei riitä, vaan tarkista myös viimeinen numero.

Riittääkö, että sivusto on Cloudflaren takana?

Ei yksinään. Palomuuri voi torjua osan tunnetuista hyökkäysyrityksistä, mutta PHP:n mukaan ainoa täydellinen korjaus on päivitys.