Internetistä löytyi vakava PHP-haavoittuvuus – joko pitää panikoida?

Keskiviikkona 21. lokakuuta julkaistiin PHP:n tietoturvapäivitys, joka korjasi kaksi vakavaa haavoittuvuutta. Aukkojen avulla hyökkääjä voi sopivissa olosuhteissa saada oman ohjelmakoodinsa toimimaan verkkosivua pyörittävällä palvelimella ilman kirjautumista. Siinä oli hyvä syy saada liikettä palvelinten ympärille ja vauhtia nörtteihin. 

Pahimmillaan seurauksena voi olla asiakas- ja tilaustietojen varastaminen, sivuston valjastaminen huijauksiin tai koko verkkopalvelun lamauttaminen. Yritykselle tämä voi tarkoittaa menetettyä myyntiä ja asiakkaiden luottamuksen heikkenemistä. 

Monelle käyttäjälle PHP on vain yksi kirjainyhdistelmä internetin maailmassa. Sillä on kuitenkin iso tehtävä. PHP tekee töitä esimerkiksi WordPressin taustalla: muodostaa verkkosivuja, käsittelee lomakkeita ja auttaa verkkokauppaa palvelemaan asiakkaita. 

Olen käyttänyt tänä vuonna paljon aikaa tekoälyn ja ylläpidon automaation kehittämiseen. Lokakuun 20.–22. päivän kiireet näyttivät käytännössä, mihin niitä tarvitaan. Samalla ne muistuttivat siitä, että kiireessä myös ylläpitäjän omat oletukset pitää testata. 

Mitä haavoittuvuudet tarkoittavat tavalliselle sivustolle 

Ensimmäinen virhe liittyy tilanteeseen, jossa PHP:n käytettävissä oleva muisti loppuu kesken. Virhetilanteen siivous menee pieleen, ja ohjelma käsittelee keskeneräisiä tietoja kuin ne olisivat valmiita. Hyökkääjä voi tarkoitusta varten rakennetulla verkkopyynnöllä käyttää tätä sekaannusta hyväkseen. 

Toisessa virheessä PHP etsii edellisen verkkopyynnön tietoja paikasta, jonka se on jo vapauttanut muuhun käyttöön. Osoite on tuttu, mutta sisältö on voinut vaihtua. Hyökkääjä voi sopivissa oloissa vaikuttaa siihen, mitä PHP sieltä löytää, ja ohjata ohjelman toimintaa. 

Exploit tarkoittaa koodia tai menetelmää, jolla tietoturva-aukkoa käytetään hyväksi. Tässä tapauksessa hyökkääjä lähettää palvelimelle huolellisesti rakennettuja verkkopyyntöjä. Onnistuneessa hyökkäyksessä palvelin alkaa suorittaa hyökkääjän koodia ilman, että tämän tarvitsee ensin kirjautua sivustolle. 

Jos hyökkäys onnistuu, hyökkääjä voi esimerkiksi korvata sivun sisällön huijausviestillä, ohjata kävijät toiselle sivustolle tai lamauttaa palvelun. Kaikki murrot eivät kuitenkaan näy ulospäin. Sivusto voi näyttää ja toimia tavalliseen tapaan samalla, kun asiakastietoja kopioidaan tai palvelimelle jätetään takaovi myöhempää käyttöä varten. 

Se, mihin hyökkääjä pääsee käsiksi, riippuu sivuston oikeuksista ja siitä, miten palvelut on erotettu toisistaan. Sivuston haltuunotto voi olla yritykselle vakava vahinko, vaikka hyökkääjä ei saisi koko palvelimen ylimpiä ylläpito-oikeuksia. 

Kuinka suurta osaa verkosta tämä koskee 

W3Techsin 22.10.2026 tilaston mukaan PHP on käytössä 69,3 prosentissa sivustoista, joiden palvelinpuolen ohjelmointikieli tunnetaan. Luku kertoo PHP:n käytön yleisyydestä. Se ei tarkoita, että yhtä suuri osuus maailman sivustoista olisi murrettu. 

BuiltWithin samana päivänä tarkastellussa aineistossa oli noin 24 miljoonaa käytössä olevaa PHP-sivustoa. Sen Suomi-luokituksessa niitä oli noin 49 000. Nämä ovat PHP:tä käyttävien sivustojen määriä. Käytännön riski riippuu siitä, onko korjaus asennettu ja millaisessa ympäristössä sivusto toimii. 

Pelkästään näissä aineistoissa puhutaan siis miljoonista sivustoista maailmalla ja kymmenistä tuhansista Suomessa. Jokaisen ylläpitäjän on syytä varmistaa oman ympäristönsä tila. Näistä kahdesta haavoittuvuudesta käytetään myös nimeä PHP2Shell. Niiden avulla tehtyjen onnistuneiden murtojen kokonaismäärästä ei vielä ole kattavaa, luotettavaa tietoa. 

Vaara jatkuu korjauksen julkaisun jälkeen. Päivittämätön palvelin säilyy kohteena, ja jo tapahtunut murto voi jättää jälkeensä takaoven. Päivitys sulkee aukon, mutta mahdollinen takaovi pitää löytää ja poistaa erikseen. Siksi tarvitaan myös lokien tarkastamista ja jatkuvaa valvontaa.

Miksi korjauksen saaminen kesti niin pitkään 

PHP-säätiön mukaan ongelman ensimerkkejä löytyi jo vuonna 2024. Korjausvaihtoehtoihin liittyi vaikeita valintoja: muutokset saattoivat rikkoa olemassa olevia toimintoja tai heikentää suorituskykyä. Pieni asiantuntijajoukko ja yksimielisyyteen perustuva päätöksenteko jumittivat työtä. Säätiö kutsuu viivettä itse rakenteelliseksi epäonnistumiseksi. 

Loppuvaihetta sotkivat vielä tiedon vuotaminen, erehdyksessä julkaistu hyökkäysvideo ja yhden jakelijan korjauspakettien julkaisu sovittua aikaisemmin. PHP-säätiön mukaan yhteistä julkaisua aikaistettiin päivällä. Paketteja valmisteltiin kuitenkin vielä, joten välitön julkistus olisi jättänyt osan ylläpitäjistä ilman helppoa päivitysreittiä. 

Minusta tässä epäonnistui erityisesti päätöksenteon rakenne. Vaikealla korjauksella pitää olla vastuuhenkilö, määräaika ja selvä tapa viedä jumittunut asia päätettäväksi. Vakavaan muistivirheeseen pitää suhtautua riskinä silloinkin, kun kukaan ei vielä ole näyttänyt helppoa tapaa hyödyntää sitä. Toivon todella, että tästä otetaan opiksi ja korjausten päätöksentekoa parannetaan. 

Kymmenen vuotta sittenkin murrettiin nopeasti 

Olisi mukavaa sanoa, että vuonna 2016 ylläpitäjä ehti juoda kahvinsa rauhassa ja nykyään ei. Muistikuvat ovat tässä vähän liian armollisia. 

Jo vuonna 2016 Wordfence löysi WordPressin päivitysjärjestelmään liittyvän vakavan aukon. Se korjattiin noin viiden päivän kuluttua ilmoituksesta ja muutamassa tunnissa sen vastaanoton vahvistamisesta. Kymmenen vuoden takainenkin korjaustyö saattoi siis olla nopeaa. 

Helmikuussa 2017 WordPressin REST API -haavoittuvuuden hyökkäykset kiihtyivät parissa päivässä yksityiskohtien julkaisusta. Wordfence havaitsi myöhemmin yli 800 000 hyökkäystä 48 tunnissa. Kyse oli sen omassa seurannassa havaituista hyökkäyksistä, ei 800 000 murretusta sivustosta. 

Patchstackin vuoden 2025 aineistossa voimakkaimmin hyödynnettyihin WordPress-haavoittuvuuksiin kohdistettiin ensimmäisiä hyökkäysyrityksiä jo tuntien kuluessa julkistuksesta. Hyökkäysaktiivisuudella painotettu mediaani oli viisi tuntia. Mittaus koski erityisen paljon hyödynnettyä joukkoa, mutta kertoo hyvin siitä, kuinka lyhyeksi ylläpitäjän reagointiaika voi jäädä. 

PHP2Shellissä Cloudflare havaitsi hyökkäysliikennettä jo ennen koordinoitua julkaisua. Wiz puolestaan kertoo tekoälyn auttaneen sovittamaan toimivia hyökkäysketjuja eri sovelluksiin tunneissa. Kyse on tutkijoiden kuvauksesta omasta työstään. Se osoittaa, miten aiemmin hankalan hyökkäyksen rakentaminen voi onnistua aiempaa pienemmällä työmäärällä. 

Nopeita massahyökkäyksiä oli jo kymmenen vuotta sitten. Nyt tekoäly auttaa rakentamaan myös vaikeampia hyökkäyksiä ja automatisoimaan niiden työvaiheita. Puolustajien on saatava samat nopeusedut käyttöönsä. 

Googlen syyskuussa 2026 julkaisema uhkaraportti kuvaa, kuinka rikolliset käyttävät tekoälyagentteja haavoittuvien kohteiden etsimiseen ja tunnusten varastamisen automatisointiin. Eräässä havaitussa tapauksessa hyökkääjä suunnitteli, rakensi ja käynnisti laajan tunnusten keruukampanjan alle kuudessa tunnissa jo murretusta pilviympäristöstä. Agentit hoitivat kohteiden skannausta ja korjasivat ajon aikana syntyneitä virheitä ilman jatkuvaa käsin ohjausta. Kampanjassa saatiin haltuun tuhansia muiden palvelujen tunnuksia.

Tekoäly auttaa myös suojaamaan palveluita 

Olen kehittänyt Sollertiksella kokonaisuutta, jossa palvelinten ja palveluiden valvonta, tietoturvatieto ja ylläpidon työkalut toimivat yhdessä. Tavoitteena on parantaa asiakkaiden palveluiden toimintavarmuutta ja tehdä ylläpitotyö näkyväksi raportoinnin avulla. 

Autopilot-järjestelmämme kokoaa havaintoja ja päivitystarpeita, auttaa niiden priorisoinnissa ja ohjaa työt sovittujen sääntöjen mukaan. Server Update Plugin eli SUP tekee varsinaista palvelinten päivitystyötä ja tuottaa siitä raportit. Keskitetyn SOC-Menun kautta ylläpitotyöt käynnistetään sovituilla oikeuksilla ja tarkistuksilla. 

Yhteinen tietopankki säilyttää ratkaisuja ja varoittaa tutuista sudenkuopista. Kokonaisuuden tavoitteena on saada kiireelliset tietoturvakorjaukset käsittelyyn nopeasti ja tarkistaa palvelujen toiminta muutosten jälkeen. Lopputulos raportoidaan, ja epäonnistumiset tai epäselvät tilanteet nostetaan ihmisen ratkaistaviksi. 

Kehitän kokonaisuutta myös palvelinten suojauksen ja suorituskyvyn parantamiseen. Tavoitteena on, että järjestelmä tunnistaa havainnoistaan kehityskohteita ja ehdottaa parannuksia. Ehdotukset pitää arvioida ja muutosten vaikutukset tarkistaa ennen laajempaa käyttöönottoa. 

Tekoäly auttaa minua tutkimaan ongelmia, rakentamaan näitä työkaluja ja arvioimaan muutoksia. Kehitän myös omia kielimallipalveluja sekä lähteitä käyttävää tutkimus- ja hakuketjua. Parhaillaan keskityn siihen, että järjestelmä tunnistaa vanhentuneen tai puuttuvan tiedon, katkokset ja epäonnistuneet ajot. Tutkimuksen tuottamat ehdotukset kulkevat tarkistuksen kautta. 

Tavoitteena on, että kerran tehty virhe opettaa myös työkalua. Seuraavalla kerralla työkalu tunnistaa saman vaaran ja pysäyttää ajon ennen kuin virhe toistuu.

Mitä teimme kolmen päivän aikana

Lokakuun 20.–22. päivän työssä vahvistimme varmuuskopioinnin ympäristöä, siirsimme vanhoja PHP-versioita käyttäviä sivustoja uudemmille versioille ja tarkistimme sekä palvelinten että WordPress-lisäosien päivityksiä. 

Satojen tarkistettujen www-palvelimien lokien mukaan PHP:n korjauspaketit asentuivat julkaisupäivänä kello 17.00–17.26. Käyttöönottoa tarkistettiin myös PHP-prosessien käynnistysajoista. Tämä havainto koskee tarkasteltuja palvelimia. Palvelinten omat päivitysjärjestelmät, Autopilot ja SUP hoitavat kokonaisuudessa eri tehtäviä, joten tarkistimme erikseen, mitä palvelimilla oli tapahtunut. 

Tekoälyn avulla kehittämämme työkalut auttoivat kartoittamaan ympäristöjä, toistamaan samat tarkistukset ja vertaamaan tilannetta ennen muutosta ja sen jälkeen. Palautusmenettelyt auttoivat peruuttamaan epäonnistuneita muutoksia. Kun ylläpidettäviä sivustoja on paljon, automaatio jättää minulle enemmän aikaa poikkeusten selvittämiseen. 

Meilläkin meni asioita pieleen. Lokakuun 21. päivän aamun PHP-massasiirrossa teimme väärän oletuksen palvelimen toteutuksesta, ja osalle sivustoista aiheutui häiriö. Ensimmäiset tarkistukset näkivät osittain vanhaa tilaa ja välimuistista tarjoiltuja sivuja. Pysäytin massasiirrot, ja muutokset palautettiin välittömästi. Työ jatkui sivusto kerrallaan menetelmällä, jossa uuden PHP:n todellinen käyttö ja sivuston toiminta tarkistettiin ennen seuraavaa vaihtoa. Havaitut poikkeamat käynnistivät automaattisen palautuksen, jonka onnistuminen tarkistettiin erikseen. 

Myös Autopilotin havaintoketjusta löytyi parannettavaa. Palvelimen tieto saatavilla olevista päivityksistä saattoi olla vanhentunut. Silloin järjestelmä näytti, ettei päivitettävää ollut, vaikka korjaus oli jo julkaistu. Lisäsimme tiedon tuoreuden tarkistuksia, nostimme tietoturvapäivitysten etusijaa ja lisäsimme hälytyksen toistuvasti lykkääntyvistä töistä. 

Päivitysketjua tukee myös erillinen valvonta. Lisäksi ajastimme ohjelmistoille viikoittaisen varmistusajon täydentämään Autopilotin toimintaa. Näin päivitysten käsittelylle on toinenkin reitti, ja valvonta auttaa huomaamaan, jos töitä jää tekemättä. 

Toinen opetus liittyi Apacheen. Se on www-palvelinohjelmisto, joka vastaanottaa selaimen pyynnöt ja toimittaa verkkosivun sisällön kävijälle. Joissakin ympäristöissä PHP toimii suoraan Apachen sisällä. 

Uuden PHP-paketin asentaminen ei näissä ympäristöissä aina tarkoita, että palvelin käyttää jo uutta koodia. Vanha versio voi jäädä muistiin, kunnes Apache käynnistetään kokonaan uudelleen. Lisäsimme päivitystyökaluumme tätä varten Apachen uudelleenkäynnistyksen ja sen onnistumisen tarkistuksen. Päivityksen onnistuminen pitää todeta myös toimivasta verkkopalvelusta.

Mitä sivuston omistajan kannattaa varmistaa 

Oman sivuston ylläpitäjältä kannattaa pyytää varmistus siitä, että PHP:n korjaus on asennettu ja otettu käyttöön. Samalla on hyvä tarkistaa WordPressin tai muun käytössä olevan PHP-sovelluksen sekä sen lisäosien päivitykset ja sivuston toiminta muutosten jälkeen. Lisäksi tarvitaan toimiva varmuuskopio ja tieto siitä, miten se palautetaan. 

PHP:n 21.10.2026 julkaistut korjatut versiot ovat 8.2.35, 8.3.36, 8.4.27 ja 8.5.12. Jakelija voi tuoda saman korjauksen myös omaan pakettiversioonsa eri versionumerolla. Siksi ylläpitäjän on tarkistettava oman toimittajansa tieto. PHP:n päivitysohje. 

PHP julkaisi 23.10.2026 myös lisäohjeen harvinaista asetusten ja sovelluskoodin yhdistelmää koskevasta riskistä. Ylläpitäjän kannattaa tarkistaa myös tämä ohje oman ympäristönsä osalta. PHP:n lisäohje. 

Tämän viikon työ muistutti minua siitä, mihin tekoälyn tuoma vauhti kannattaa käyttää. Se auttaa tutkimaan ja rakentamaan, mutta samalla pitää kehittää tarkistuksia ja palautuskeinoja. Päivitystä pidän onnistuneena vasta, kun sen vaikutus näkyy myös asiakkaan toimivassa palvelussa. 

Silloin ehdimme huokaista ja ehkä juoda sen kahvinkin lämpimänä. 

Syysterveisin,
Mika Hoffren