Tiistai 20.10. ja keskiviikko 21.10. olivat jännittäviä päiviä näin palvelinylläpitäjän (eli sysadminin) näkökulmasta. PHP-ohjelmointikielestä, jonka päällä pyörii myös WordPress, paljastui 2 kriittistä haavoittuvuutta, joille annettiin lempinimi PHP2Shell. Tieto vuoti julkisuuteen ennen kuin korjausta oli saatavilla, ja aihe ylitti lopulta valtakunnallisen uutiskynnyksen, asiasta kirjoitti muun muassa Yle.
Ylen artikkelin yhteyteen upotetussa videossa sanotaan, että ”keskiviikkona netissä tapahtui jotain sellaista, jota ei ole aikoihin nähty”. Tämä on kuitenkin hieman virheellinen väittämä, sillä haavoittuvuuksia nähdään usein, jopa viikoittain, myös web-palvelimen keskeisissä komponenteissa kuten nginx tai Linux-kernel. Joskus ne ovat mittaluokassaan aivan yhtä vakavia kuin php2shell. Niistä ei vain uutisoida, koska ne ilmoitetaan vastuullisesti ja korjaus tulee nopeasti – tällä kertaa ei tapahtunut kumpaakaan ja uutinen levisi nopeasti.
Dude hostaa ja ylläpitää asiakkaidensa WordPress-sivustoja omilla palvelimillaan, joten haavoittuvuudet ja niiden paikkailu ovat meille tuttu osa arkea. Käyn tässä kirjoituksessa läpi, mistä PHP2Shellissä oli kyse, miksi se oli niin iso juttu ja miten haavoittuvuudet yleensä julkistetaan ja korjataan. Kerron myös, mitä teimme omalla palvelinkannallamme.
Mistä PHP2Shellissä oli kyse?
”PHP2Shell” on yhteisnimitys kahdelle haavoittuvuudelle, joiden tunnisteet ovat CVE-2026-109618 ja CVE-2026-109619. CVE (Common Vulnerabilities and Exposures) on julkinen tunnistejärjestelmä tietoturva-aukoille. Molemmat haavoittuvuudet saivat vakavuusluokituksessa pisteet 9,2/10.
Viat löytyivät PHP:n ytimestä, sen muistinhallinnasta ja virheenkäsittelystä. Siksi ne koskivat käytännössä kaikkia verkkopyyntöjä palvelevia PHP-asennuksia julkaisujärjestelmästä ja lisäosista riippumatta. Eli tämä ei ollut puhtaasti WordPressin ongelma, vaan PHP:tä käyttävät tunnetut palvelut kuten Wikipedia, Tumblr, Etsy, Mailchimp, jopa osa Facebookista. Alustoista PHP:tä käyttää mm. WordPress, Drupal, Joomla, Magento, Craft CMS, Kirby. Pilvipalveluista esimerkiksi Nextcloud. W3Techsin mukaan PHP:tä käyttää 60–70 % kaikista maailman verkkosivuista. Tätä reikää hyödyntämällä hyökkääjä pystyi ajamaan palvelimella omaa koodiaan ilman kirjautumista (ns. RCE eli remote code execution).
PHP julkaisi korjatut versiot 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 keskiviikkona 21.10. noin klo 17 Suomen aikaa. Versiot 8.1 ja sitä vanhemmat eivät enää saa PHP-projektilta virallisia päivityksiä, joten siksi edelleen tänä perjantaina moni palvelu on alhaalla, koska sysopeilla menee aikaa päivittää palvelimet. Vanhoille palvelimille ei nimittäin usein voi asentaa uudempaa softaa. Tätä kirjoittaessa esimerkiksi irc-galleria.net näyttää edelleen viestiä ”Päivitämme palvelua”.
Mielenkiintoinen yksityiskohta: PHP Foundationin mukaan ensimmäiset merkit toisesta haavoittuvuuteen liittyvästä bugista löytyivät jo vuonna 2024 PHP:n ulkoisessa tietoturva-auditoinnissa. Tuolloin konkreettista hyökkäysvektoria ei kuitenkaan osattu ajatella, eikä sopivasta korjaustavasta päästy yksimielisyyteen, joten korjaus jäi odottamaan. Elokuussa 2026 tietoturvayhtiö Calif raportoi saman juurisyyn kautta toimivan etäkoodin suorituksen, ja saman löysivät pian myös OpenAI ja Wiz. Vasta silloin vian koko vakavuus selvisi.
On hieman vähättelyä sanoa, että ”tekoäly löysi” tämän haavoittuvuuden. Tekoäly osasi vain todentaa ongelman.
Miksi juuri tämä haavoittuvuus ylitti uutiskynnyksen
Haavoittuvuuksia julkistetaan eri tavoin. Tyypillisesti löytäjä, usein tietoturvatutkija, kertoo viasta ensin yksityisesti ohjelmiston tekijöille. Korjaus (ns. patch) julkaistaan sovittuna päivänä samaan aikaan, kun tieto viasta tulee julkiseksi. Siihen asti tieto on salassa, eli embargossa.
PHP2Shellin kohdalla joku vuoti tiedon haavoittuvuudesta noin 2 päivää etuajassa. Huhuja aiheesta kierteli fediversumin tietoturvasyötteissä jo tiistai-iltana. PHP päätti aikaistaa julkaisuaan vuorokaudella ja kolmannen osapuolen pakettien maintainerit, kuten Ondrej, ryhtyivät hommiin. Keskiviikkoaamuna joku oli jo julkaissut konseptivideon siitä miten haavoittuvuutta voi hyödyntää. Tässä vaiheessa korjausta ei vielä ollut ja Dudella hakattiin refresh-nappia otsa hiessä seuraten Ondrejin työtä Codeberg-tiketissä. Tietoturvatutkija Kevin Beaumontin virtaa oli myös mielenkiintoista seurata ja sitä kautta sai tapoja rajata PHP:n komentoja ilman palveluiden täydellistä sulkemista (ns. mitigaatio).
Mitä tehdä, kun korjausta ei vielä ole?
Joskus vahinkoa voi rajata ennen korjausta (ns. mitigaatio), esimerkiksi estämällä hyökkäykselle tunnusomaiset pyynnöt tai rajaamalla oikeuksia niin, ettei murtautuja pääse ohjelman sisältä juuri mihinkään. Tässä tapauksessa auttaa hyvin tietoturvakovennettu palvelin ja AppArmor, joka määrittelee ohjelmalle tarkasti, mihin tiedostoihin ja toimintoihin sillä on lupa koskea.
PHP:n oman ohjeen mukaan väliaikaiset suojaukset kuitenkin vain pienentävät riskiä, ja ainoa täydellinen ratkaisu on päivitys. Aivan hyvä tapa vakavissa haavoittuvuustilanteissa on laittaa palvelut säppiin, eli koneet ja verkkopalvelut kiinni, kuten moni Suomessakin teki. Silloin niihin ei ainakaan voi kukaan hyökätä.
Amazonin mukaan ensimmäinen hyödyntämisyritys nähtiin jo 17.10., siis useita päiviä ennen julkistusta. Automaattiset skannerit käyvät koko internetin läpi tunneissa ja etsivät päivittämättömiä palvelimia. Meidän palvelimiamme haisteltiin probeilla (botit, jotka tarkistavat, onko haavoittuvuus olemassa) minuutteja tietovuodon jälkeen. Kun tieto vuotaa ennen korjausta, rikolliset pääsevät etsimään hyökkäystapaa samaan aikaan, kun ylläpitäjät vielä odottavat päivitystä.
Näin päivitimme palvelimemme
Seurasimme tilannetta tiiviisti keskiviikkoaamusta asti, teimme suunnitelman sysoptiimillä, kävimme läpi palvelinkannan ja mahdolliset hyökkäysreitit ja estimme ne. Korjatut versiot paketeista julkaistiin klo 17. Ensimmäiset palvelimet oli päivitetty noin 35 minuutissa, ja koko palvelinkanta oli päivitetty ja tarkistettu klo 19.16 mennessä. Päivityksen jälkeen auditoimme jokaisen palvelimen murron merkkien varalta. Tarkistimme muun muassa
- PHP-prosessien kaatumiset palvelimen lokeista
- uudet PHP-tiedostot sivustojen mediakansioissa
- muuttuneet PHP-tiedostot sivustojen koodissa
- PHP:n käynnistämät komentotulkit ja palvelimelta ulospäin lähtevät yhteydet
- uudet ajettavat tiedostot väliaikaishakemistoissa
- hyökkäystyökalujen jäljet palvelinlokeissa.
Merkkejä murroista ei löytynyt. Asiakkaille tiedotettiin tilanteesta, ja statussivulle päivitettiin tilanne.
Haavoittuvuudet ovat jatkuvaa arkea
PHP2Shell oli poikkeuksellinen lähinnä mittaluokaltaan. Web-palvelimiin tulee haavoittuvuuksia jatkuvasti, ja niiden paikkaaminen kuuluu ylläpitäjän normaaliin työhön. Tämä tapaus koski suurinta osaa verkkopalveluista ja sen vuotamisesta kesti poikkeuksellisen pitkään saada korjaus, joten se ylitti uutiskynnyksen. Yleensä jo korjatuista ja nopeista paikkauksista ei kukaan uutisoi. Tämäkin olisi voinut olla sellainen, josta vain nörtit ovat tietoisia, jos päivityspaketti ja haavoittuvuus olisivat ilmestyneet yhtä aikaa, kuten yleensä.
Mielenrauhaa tuo oma tietoturvaskannerimme, joka vertaa asiakassivustojen lisäosia mm. WPScanin ja Patchstackin haavoittuvuustietokantoihin. Suosimme mahdollisimman vähäisiä ja laadukkaasti koodattuja lisäosia, koska jokainen ylimääräinen riippuvuus on uusi mahdollinen reikä. Lisäksi tietoturvaskannerimme käyttää muita lukuisia tekniikoita varmistamaan, ettei kukaan pääse hyödyntämään aukkoja. Olisi kamalaa, jos kaikista suojauksista huolimatta palvelimella pyörisi jotain sinne kuulumatonta. Täytyy myös muistaa, että palvelimet ovat aina murrettavissa ilman tällaisia julkisia haavoittuvuuksia. Heikoin lenkki voi olla vaikkapa vanha tunnus, heikko salasana, huonolaatuinen tai päivittämätön WordPress-lisäosa. Me Dudella pidämme huolen, että nämä hyökkäysvektorit on eliminoitu, mutta tämä on syytä muistaa senkin lisäksi, että palvelin on itsessään tietoturvan näkökulmasta huippuluokkaa ja alan standardin mukaisesti kovennettu.
Tekoälyaikana on jännittävää, että vanhojakin bugeja löydetään nyt aiempaa nopeammin ja niille keksitään uusia käyttötarkoituksia. PHP Foundationin mukaan tekoälyavusteinen tutkimus on kasvattanut tietoturvaraporttien määrää selvästi. Pelottavin ajatus on, että nykyään kaiken voi takaisinmallintaa (ns. reverse engineering), joten vanhat haavat voidaan tietyissä olosuhteissa avata uudelleen.
Miten haavoittuvuuksia hyödynnetään?
Monen mieleen saattaa linkittyä uhkapelimainokset tai pyörivä pääkallon kuva kun puhutaan verkkosivujen hakkeroinnista, mutta nykyaikana tällainen ”scriptkiddieily” eli pelleily ja voimannäyttö on harvinaista, sillä tässä touhussa hakkerointi ja hakkeroija usein paljastuu. Moderni rikollinen verkossa ei jätä jälkiä. Useimmiten verkkopalveluiden haavoittuvuuksia hyödynnetään salaa ja piilossa siten, että verkkosivut laitetaan vaikkapa louhimaan kryptovaluuttaa (ns. cryptojacking) tai liitetään osaksi rikollisten bottiverkkoa ilman, että kukaan huomaa mitään.
Jos verkkosivujen omistaja tai ylläpitotaho ei ole kärryillä, voi käydä ikävästi. Siksi kannattaa luottaa laadukkaaseen ylläpitoon, jossa ihminen on kiinnostunut siitä, mitä palvelimella ajetaan, ja kaikki tekniikka päivitetään uusimpiin versioihin ajoissa. Jos haluat kuulla lisää Duden hostingista ja ylläpidosta, ota yhteyttä.
PS. Kirjoittelin aiheesta myös LinkedIniin.
