PHP:n vakavat haavoittuvuudet osoittivat, miksi tietoturvassa nopeus ei yksin riitä

PHP:n tietoturva nousi lokakuussa jälleen otsikoihin. Keskiviikkona 21.10.2026 julkaistu päivitys korjasi kaksi vakavaa haavoittuvuutta, joiden onnistunut hyödyntäminen voi mahdollistaa hyökkääjän oman koodin suorittamisen verkkopalvelua pyörittävällä palvelimella ilman kirjautumista.

Verkkosivuston omistajalle tämä voi kuulostaa tekniseltä ongelmalta. Käytännössä seuraukset voivat kuitenkin osua suoraan liiketoimintaan. Hyökkääjä voi esimerkiksi muuttaa verkkosivuston sisältöä, ohjata kävijöitä muualle, varastaa tietoja tai häiritä koko palvelun toimintaa. Onnistunut hyökkäys ei myöskään välttämättä näy ulospäin. Sivusto voi jatkaa toimintaansa samalla, kun palvelimelta kopioidaan tietoja tai sinne rakennetaan pääsyä myöhempää käyttöä varten.

Siksi 21. lokakuuta julkaistu korjaus käynnisti nopeasti toimenpiteitä myös meidän ylläpitämissämme ympäristöissä.

Tapahtumat osoittivat samalla jotain laajempaa: nykyisessä tietoturvaympäristössä päivityksen asentaminen nopeasti on tärkeää, mutta se ei yksin riitä. Pitää myös pystyä varmistamaan, että korjaus on todella käytössä, palvelu toimii muutoksen jälkeen ja mahdollisiin virhetilanteisiin voidaan reagoida hallitusti.

PHP jää useimmille verkkosivustojen käyttäjille täysin näkymättömäksi, vaikka se tekee taustalla paljon töitä. Sitä käytetään esimerkiksi WordPress-sivustojen toiminnassa, lomakkeiden käsittelyssä ja verkkokauppojen palvelinpuolen toiminnallisuuksissa.

PHP:n maailmanlaajuinen käyttö tekee sen tietoturvaongelmista erityisen merkittäviä.

W3Techsin 22.10.2026 tilaston mukaan PHP:tä käytti 69,3 prosenttia niistä sivustoista, joiden palvelinpuolen ohjelmointikieli tunnettiin. BuiltWithin samana päivänä tarkastellussa aineistossa oli puolestaan noin 24 miljoonaa käytössä olevaa PHP-sivustoa. Suomen luokituksessa määrä oli noin 49 000.

Luvut eivät tarkoita, että nämä sivustot olisivat automaattisesti haavoittuvia tai joutuneet hyökkäyksen kohteeksi. Todellinen riski riippuu muun muassa käytössä olevasta PHP-versiosta, asennetuista korjauksista ja palvelinympäristön toteutuksesta.

Mittakaava kertoo kuitenkin olennaisen: kun näin laajasti käytetystä teknologiasta löytyy vakava haavoittuvuus, päivitystarve koskettaa hyvin suurta joukkoa verkkopalveluita.

Lokakuussa julkistettuja haavoittuvuuksia on kutsuttu myös nimellä PHP2Shell.

Ensimmäisessä haavoittuvuudessa ongelma liittyy tilanteeseen, jossa PHP:n käytettävissä oleva muisti loppuu. Virhetilanteen käsittelyssä keskeneräiseksi jäänyttä tietoa voidaan käsitellä ikään kuin se olisi valmis. Hyökkääjä voi pyrkiä hyödyntämään tätä lähettämällä palvelimelle tarkoitusta varten muodostettuja verkkopyyntöjä.

Toisessa tapauksessa PHP yrittää käyttää edellisen verkkopyynnön tietoja muistialueelta, joka on jo vapautettu muuhun käyttöön. Muistipaikka on edelleen sama, mutta sen sisältö on voinut muuttua. Sopivissa olosuhteissa hyökkääjä voi vaikuttaa sisältöön ja sitä kautta ohjelman toimintaan.

Haavoittuvuuteen rakennettua hyväksikäyttömenetelmää kutsutaan exploitiksi. Jos hyökkäys onnistuu, palvelin voidaan saada suorittamaan hyökkääjän ohjelmakoodia ilman normaalia kirjautumista.

Se ei automaattisesti tarkoita koko palvelimen täydellistä hallintaa. Vahingon laajuus riippuu esimerkiksi verkkosivustolle annetuista oikeuksista ja siitä, kuinka hyvin eri palvelut on erotettu toisistaan. Yksittäisen verkkopalvelunkin haltuunotto voi silti aiheuttaa yritykselle vakavia seurauksia.

Tietoturvakorjauksen julkaiseminen sulkee tunnetun haavoittuvuuden, mutta se ei poista mahdollisen aikaisemman hyökkäyksen jälkiä.

Jos palvelimelle on ehditty rakentaa takaovi ennen korjausta, pelkkä PHP:n päivittäminen ei poista sitä. Siksi haavoittuvuuksien yhteydessä tarvitaan päivitysten lisäksi lokien tarkastamista ja palveluiden jatkuvaa valvontaa.

Tämä on tärkeä ero: korjattu haavoittuvuus ei ole sama asia kuin varmasti puhdas ympäristö.

PHP2Shell-haavoittuvuuksien avulla onnistuneesti tehtyjen murtojen kokonaismäärästä ei ole vielä kattavaa ja luotettavaa tietoa. Sen sijaan tiedetään, että haavoittuvuuksiin liittyvää hyökkäysliikennettä havaittiin jo ennen koordinoitua julkaisua.

Tapauksesta tekee erityisen kiinnostavan myös se, mitä tapahtui ennen päivityksen julkaisua.

PHP-säätiön mukaan ensimmäisiä merkkejä ongelmasta havaittiin jo vuonna 2024. Korjauksen tekeminen osoittautui vaikeaksi, sillä vaihtoehtoihin liittyi riskejä nykyisten toimintojen rikkoutumisesta tai suorituskyvyn heikkenemisestä. Työtä vaikeuttivat myös pieni asiantuntijajoukko ja yksimielisyyteen perustunut päätöksentekotapa.

PHP-säätiö on itse kuvannut viivettä rakenteelliseksi epäonnistumiseksi.

Tilannetta vaikeuttivat lopulta myös tiedon vuotaminen, vahingossa julkaistu hyökkäysvideo ja yhden jakelijan sovittua aikaisemmin julkaisemat korjauspaketit. Yhteistä julkaisua aikaistettiin päivällä, vaikka kaikkien pakettien valmistelu oli vielä kesken.

Minulle tapauksesta nousee erityisesti yksi huomio: vakavan tietoturvaongelman ratkaisemisella täytyy olla selkeä omistaja, aikataulu ja tapa viedä jumittunut päätös eteenpäin.

Vakavaa muistivirhettä ei myöskään pitäisi pitää vähäisenä vain siksi, ettei sille vielä tunneta helposti toteutettavaa hyökkäystapaa. Toivottavasti tästä tapauksesta otetaan opiksi myös tulevien korjausten päätöksenteossa.

Tietoturvakeskustelussa on helppo ajatella, että ennen kaikki tapahtui rauhallisemmin. Historia ei kuitenkaan täysin tue tätä ajatusta.

Jo vuonna 2016 Wordfence löysi WordPressin päivitysjärjestelmään liittyvän vakavan haavoittuvuuden. Korjaus valmistui noin viidessä päivässä ilmoituksesta ja vain muutamassa tunnissa sen vastaanoton vahvistamisesta.

Vuoden 2017 WordPress REST API -haavoittuvuuden kohdalla hyökkäykset kiihtyivät parissa päivässä teknisten yksityiskohtien julkaisun jälkeen. Wordfence raportoi myöhemmin havainneensa yli 800 000 hyökkäystä 48 tunnin aikana. Kyse oli hyökkäysyrityksistä Wordfencen seurannassa, ei 800 000 onnistuneesti murretusta verkkosivustosta.

Tuoreempi Patchstackin aineisto kertoo samasta kehityksestä. Vuoden 2025 voimakkaimmin hyödynnettyihin WordPress-haavoittuvuuksiin nähtiin ensimmäisiä hyökkäysyrityksiä jo tuntien kuluessa niiden julkistamisesta. Hyökkäysaktiivisuudella painotettu mediaani oli viisi tuntia.

Nopeus ei siis itsessään ole uusi asia. Muutos on siinä, millaisia työkaluja hyökkääjillä nykyään on käytössään.

PHP2Shell-tapauksessa Cloudflare havaitsi haavoittuvuuksiin liittyvää hyökkäysliikennettä jo ennen koordinoitua julkaisua. Wiz puolestaan kuvasi, kuinka tekoäly auttoi tutkijoita sovittamaan toimivia hyökkäysketjuja erilaisiin sovelluksiin vain tunneissa.

Google kuvasi syyskuussa 2026 julkaisemassaan uhkaraportissa myös tapausta, jossa hyökkääjä suunnitteli, rakensi ja käynnisti laajan tunnusten keruukampanjan alle kuudessa tunnissa jo murretusta pilviympäristöstä. Tekoälyagentit osallistuivat muun muassa kohteiden skannaukseen ja toiminnan aikana syntyneiden virheiden korjaamiseen. Kampanjassa saatiin haltuun tuhansia muiden palvelujen tunnuksia.

Hyökkääjien kehittyessä puolustajat eivät voi jäädä pelkästään käsityön varaan.

Tämä on yksi syy siihen, miksi olen käyttänyt tänä vuonna paljon aikaa tekoälyn ja ylläpidon automaation kehittämiseen.

Olen kehittänyt Sollertiksella kokonaisuutta, jossa palvelinten ja palveluiden valvonta, tietoturvatieto sekä ylläpidon työkalut yhdistyvät toisiinsa. Tavoitteena on parantaa asiakkaiden palveluiden toimintavarmuutta ja samalla tehdä tehty ylläpitotyö näkyväksi raportoinnin kautta.

Autopilot-järjestelmä kokoaa havaintoja ja päivitystarpeita, tukee niiden priorisointia ja ohjaa töitä ennalta määriteltyjen sääntöjen perusteella. Server Update Plugin eli SUP huolehtii varsinaisista palvelinpäivityksistä ja niiden raportoinnista. SOC-Menun kautta ylläpitotöitä puolestaan voidaan käynnistää keskitetysti sovituilla oikeuksilla ja tarkistuksilla.

Kokonaisuuteen kuuluu myös yhteinen tietopankki. Sen tehtävä on säilyttää aikaisempia ratkaisuja ja auttaa tunnistamaan jo tunnettuja ongelmatilanteita.

Ajatus ei ole poistaa ihmistä prosessista. Päinvastoin.

Automaatio sopii hyvin toistuviin tarkistuksiin ja rutiineihin. Epäonnistuneet tai epäselvät tilanteet täytyy pystyä nostamaan ihmisen arvioitaviksi. Samoin järjestelmän ehdottamat muutokset pitää arvioida ja niiden vaikutukset tarkistaa ennen laajempaa käyttöönottoa.

Tekoäly toimii apuna myös ongelmien tutkimisessa, työkalujen rakentamisessa ja muutosten arvioinnissa. Kehitän lisäksi omia kielimallipalveluita sekä lähteisiin perustuvaa tutkimus- ja hakuketjua.

Yksi keskeisistä tavoitteista on tunnistaa puuttuva tai vanhentunut tieto, katkokset sekä epäonnistuneet ajot nykyistä paremmin.

Parhaassa tapauksessa kerran tehty virhe ei jää vain ikäväksi muistoksi, vaan siitä muodostuu uusi tarkistus. Kun samanlainen tilanne tulee eteen seuraavan kerran, järjestelmä voi tunnistaa riskin ennen kuin virhe ehtii toistua.

PHP-haavoittuvuus osui keskelle 20.–22. lokakuuta tekemäämme ylläpitotyötä.

Kolmen päivän aikana vahvistimme varmuuskopiointiympäristöä, siirsimme vanhoja PHP-versioita käyttäviä verkkosivustoja uudempiin versioihin ja tarkistimme sekä palvelinten että WordPress-lisäosien päivityksiä.

Satojen tarkistettujen www-palvelinten lokit osoittivat, että PHP:n korjauspaketit asentuivat julkaisupäivänä kello 17.00–17.26. Käyttöönottoa tarkastettiin myös PHP-prosessien käynnistysajoista. Havainto koskee tarkasteltuja palvelimia.

Tekoälyn avulla kehitetyt työkalut helpottivat ympäristöjen kartoittamista, samojen tarkistusten toistamista ja tilanteen vertailua ennen muutoksia ja niiden jälkeen. Kun ylläpidettävänä on suuri määrä verkkopalveluita, automaation hyöty näkyy siinä, että enemmän ihmisen aikaa voidaan käyttää poikkeustilanteiden selvittämiseen.

Mutta samalla saimme hyvän muistutuksen siitä, ettei automaatioonkaan pidä luottaa sokeasti.

21. lokakuuta aamulla tehdyssä PHP-massasiirrossa oletimme palvelinympäristön toteutuksesta väärin. Seurauksena osassa sivustoja ilmeni häiriöitä. Ensimmäiset tarkistukset myös näkivät osittain vanhaa tilannetta ja välimuistista toimitettuja sivuja.

Massasiirrot pysäytettiin ja muutokset palautettiin välittömästi.

Sen jälkeen työskentelytapaa muutettiin. Sivustot käsiteltiin yksi kerrallaan, ja uuden PHP-version todellinen käyttö sekä verkkosivuston toiminta varmistettiin ennen seuraavaa vaihtoa. Havaitut poikkeamat käynnistivät automaattisen palautuksen, jonka onnistuminen tarkastettiin erikseen.

Tämä oli oikeastaan yksi koko viikon tärkeimmistä opeista: automaation arvo ei ole siinä, että sillä tehdään mahdollisimman monta muutosta mahdollisimman nopeasti. Arvo syntyy siitä, että muutos, tarkistus ja tarvittaessa palautus muodostavat yhden hallitun ketjun.

Samalla havaitsimme ongelman Autopilotin käyttämässä tiedossa.

Palvelimella oleva tieto saatavilla olevista päivityksistä saattoi olla vanhentunut. Tällöin järjestelmä saattoi päätellä, ettei päivityksiä ollut, vaikka uusi tietoturvakorjaus oli jo julkaistu.

Tämän seurauksena järjestelmään lisättiin tiedon tuoreuden tarkistuksia. Tietoturvapäivityksiä nostettiin priorisoinnissa ylemmäs ja toistuvasti lykkääntyvistä töistä lisättiin hälytyksiä.

Päivitysketjun rinnalla toimii myös erillinen valvonta. Ohjelmistoille ajastettiin lisäksi viikoittainen varmistusajo täydentämään Autopilotin toimintaa. Näin päivitysten käsittely ei ole yhden mekanismin varassa.

Yksi konkreettinen oppi koski Apachea.

Apache on verkkopalvelinohjelmisto, joka vastaanottaa selaimesta tulevia pyyntöjä ja toimittaa verkkosivuston sisältöä käyttäjälle. Joissakin ympäristöissä PHP toimii suoraan Apachen sisällä.

Tällaisessa toteutuksessa uuden PHP-paketin asentaminen ei välttämättä vielä tarkoita, että palvelu käyttää korjattua ohjelmakoodia. Vanha versio voi säilyä muistissa siihen asti, että Apache käynnistetään kokonaan uudelleen.

Lisäsimme siksi ylläpitotyökaluun Apachen uudelleenkäynnistyksen ja sen onnistumisen tarkistamisen.

Tästäkin seuraa yksinkertainen mutta tärkeä periaate: päivityksen onnistumista ei pitäisi todeta pelkästään siitä, että asennuskomento meni läpi. Korjauksen pitää näkyä myös siinä palvelussa, jota asiakas oikeasti käyttää.

Jos yrityksesi verkkosivusto käyttää PHP:tä, ylläpidolta kannattaa varmistaa ainakin kolme asiaa.

Ensinnäkin PHP:n tietoturvakorjauksen täytyy olla asennettu ja todella käytössä. Toiseksi WordPressin tai muun PHP-sovelluksen sekä sen lisäosien päivitysten pitää olla kunnossa. Kolmanneksi sivuston toiminta pitäisi tarkistaa muutosten jälkeen, ja käytettävissä pitää olla toimiva varmuuskopio sekä testattu tapa palauttaa se.

21.10.2026 julkaistut korjatut PHP-versiot ovat 8.2.35, 8.3.36, 8.4.27 ja 8.5.12. On kuitenkin mahdollista, että Linux-jakelun tai muun toimittajan korjaus toimitetaan eri versionumerolla. Siksi oman ympäristön tilanne täytyy varmistaa käytetyn toimittajan tiedoista. Tarkemmat tiedot löytyvät PHP:n 21.10.2026 julkaisemasta päivitysohjeesta.

PHP julkaisi 23.10.2026 lisäksi ohjeen harvinaiseen asetusten ja sovelluskoodin yhdistelmään liittyvästä riskistä. Myös sen merkitys kannattaa tarkistaa oman ympäristön osalta. Katso PHP:n 23.10.2026 julkaisema lisäohje.

Lokakuun tapahtumista jäi minulle ennen kaikkea yksi ajatus.

Tekoäly ja automaatio voivat nopeuttaa ylläpitoa merkittävästi. Samat teknologiat kuitenkin nopeuttavat myös hyökkääjien toimintaa. Siksi puolustuksessa ei riitä, että pystymme tekemään asioita aiempaa nopeammin.

Meidän pitää pystyä tekemään ne nopeasti ja hallitusti.

Korjaus pitää löytää, priorisoida ja asentaa. Sen käyttöönotto täytyy todentaa. Palvelun on toimittava muutoksen jälkeen. Jos jotain menee pieleen, muutoksen pitää olla palautettavissa. Ja jos järjestelmä tekee virheen, seuraavan version pitäisi osata tunnistaa sama riski paremmin.

Minulle päivitys ei ole valmis silloin, kun uusi paketti näkyy palvelimella.

Se on valmis vasta silloin, kun korjaus on varmasti käytössä ja asiakkaan palvelu toimii kuten pitääkin.

Sen jälkeen voi ehkä viimein palata sen kahvikupin ääreen.