Keskiviikkona 21. lokakuuta PHP-projekti julkaisi päivityksen kahteen kriittiseen haavoittuvuuteen, joiden avulla hyökkääjä pystyy ajamaan omaa koodiaan palvelimella ilman tunnuksia. Aukot koskivat käytännössä jokaista verkossa palvelevaa PHP-asennusta, ja tiedot vuotivat julkisuuteen ennen korjausta.

Mitä tapahtui

Drupalia, WordPressiä ja käytännössä suurimman osaa Internettiä pyörittävän PHP-ohjelmointikielen kehittäjäyhteisö PHP julkaisi 21. lokakuuta päivitetyt versiot, jotka korjaavat haavoittuvuudet CVE-2026-109618 ja CVE-2026-109619. Tietoturvayhteisö tuntee parin nimellä PHP2Shell. Molemmat saivat CVSS v4.0 -asteikolla arvosanan 9,2 eli kriittinen, ja molemmat mahdollistavat koodin etäsuorituksen ilman kirjautumista.

Haavoittuvuudet löysi tietoturvayhtiö Calif, joka ilmoitti niistä PHP:lle koordinoitua julkistusta varten. Julkistuksen piti tapahtua 22. lokakuuta, mutta yksityiskohdat vuotivat sosiaaliseen mediaan kaksi päivää etuajassa. PHP:n tietoturvatiimi siirsi julkaisun saman tien keskiviikolle ja ilmoitti siitä etukäteen, mitä se tekee harvoin.

PHP Foundationin oman jälkikatsauksen mukaan vuoto sai alkunsa, kun yksi aukoista ilmoittaneista tietoturvayrityksistä julkaisi vahingossa videon. Lisäksi yksi ohjelmistotoimittaja julkaisi korjatut konttikuvat yli kuusi tuntia ennen sovittua aikaa, jolloin hyökkääjät pystyivät tutkimaan korjausta muiden vielä odottaessa.

Tuetun PHP version käyttäjille ratkaisu oli yksinkertainen: päivitys. Hankalampi tilanne oli niillä, joiden palvelin pyörii PHP 8.1:llä tai vanhemmalla ja jotka eivät saaneet virallisia korjauksia.

Mistä haavoittuvuudet johtuivat

Vika ei ollut WordPressissä, Drupalissa tai missään muussa sovelluksessa, vaan PHP-tulkissa itsessään. Siksi sovelluskoodin laatu ei suojannut, jos alla oleva PHP oli päivittämättä.

Molemmat aukot liittyvät siihen, mitä PHP tekee, kun pyyntö kaatuu kesken. PHP:llä on jokaiselle pyynnölle muistiraja (memory_limit). Kun raja ylittyy, PHP keskeyttää pyynnön ja siivoaa jälkensä. Ajatus on, että kaatuminen on turvallinen pysähdys. Tutkijat osoittivat, ettei se ole:

• CVE-2026-109618: Kun muisti loppuu juuri oikealla hetkellä pyynnön alustuksen aikana, osa PHP:n sisäisistä tietorakenteista jää puolivalmiiksi. Siivouskoodi luottaa niihin silti, ja hyökkääjä pääsee korruptoimaan muistia.
• CVE-2026-109619: Kaatuminen ohittaa istunnon siivouksen, jolloin PHP-prosessiin jää osoittimia jo vapautettuun muistiin. Kun sama prosessi ottaa vastaan seuraavan pyynnön, se käsittelee tätä vanhentunutta tietoa. Tietoturva-alalla tätä kutsutaan nimellä use-after-free.

Käytännön hyökkäysreitti kulki PHP:n tiedostonlatauksen edistymisen seurannan (session.upload_progress) kautta. Ominaisuus on oletuksena päällä, ja PHP käsittelee sen jo ennen kuin sivuston oma koodi ehtii käynnistyä. Hyökkääjä lähettää tiedostonlatauspyynnön, pitää sen hetken auki ja ajaa samalla PHP:n muistirajan yli. Tämän jälkeen seuraava pyyntö samalle prosessille lukee vapautettua muistia, mikä paljastaa palvelimen muistin sisältöä ja johtaa lopulta koodin suoritukseen.

Kiinnostava yksityiskohta on, että samantyyppinen muistin loppumiseen liittyvä ongelma raportoitiin jo vuonna 2020 ja sitä tarkasteltiin uudelleen vuoden 2024 auditoinnissa. Silloin kukaan ei kuitenkaan osoittanut, että sitä voisi hyödyntää luotettavasti (tiivistelmä Califin tutkimuksesta). Löydöstä kreditoidaan Califin lisäksi Wiz Researchia ja OpenAI:n Codex Security -työkalua, joten myös tekoäly oli mukana kaivamassa bugeja esiin.

Miksi vaikutus oli niin iso

Kriittisiä haavoittuvuuksia julkaistaan joka viikko, mutta PHP2Shellissa yhdistyi neljä asiaa, jotka harvoin osuvat samaan aikaan.

1. Kohteena oli lähes koko verkko. PHP on noin 70 prosentin osuudellaan selvästi yleisin palvelinpuolen kieli niiden sivustojen joukossa, joiden tekniikka on tunnistettavissa. WordPress, Drupal, Laravel, Symfony ja lukemattomat sisäiset työkalut toimivat sen päällä.

2. Hyökkääjä ei tarvinnut tunnuksia eikä sovelluksen virhettä. Hyökkäys toimi jo ennen kuin sivuston oma koodi käynnistyi. Tavallisesti kriittinenkin aukko vaatii jonkin tietyn lisäosan, kirjautumisen tai harvinaisen asetuksen. Tässä riitti, että palvelin otti vastaan lomakepyyntöjä.

3. Hyökkäyskoodi oli liikkeellä ennen korjausta. Vuodon takia ylläpitäjillä ei ollut tavanomaista etumatkaa. Hyökkäyksiä havaittiin samana päivänä, kun korjaus julkaistiin, ja CISA vahvisti aktiivisen hyödyntämisen viisi päivää myöhemmin.

4. Vika ulottui yli 20 vuoden taakse. Haavoittuvuudet koskevat PHP-versioita aina vuodesta 2004 alkaen. W3Techsin mukaan noin kolmannes PHP-sivustoista käyttää yhä PHP 7:ää tai 5:tä. Niille ei ole tullut virallista korjausta, joten päivittämättömät ja unohdetut palvelimet jäävät hyökkääjien saaliiksi pitkäksi aikaa.

Mittakaava näkyi myös uutisissa. Palo Alto Networks löysi yli 22 miljoonaa mahdollisesti haavoittuvaa verkkoon kytkettyä PHP-asennusta, ja Suomessa, Alankomaissa, Belgiassa ja Ranskassa verkkosivuja otettiin varotoimena pois käytöstä.

Väliaikaisia kiertoteitäkin oli, kuten upload progress -ominaisuuden poistaminen käytöstä. PHP kuitenkin totesi, etteivät ne estä kaikkia hyökkäysmuunnelmia ja että vain päivitys korjaa ongelman.

Miten PHP2Shell vertautuu aiempiin

PHP2Shell kuuluu samaan sarjaan kuin viime vuosien pahimmat verkkopalvelujen aukot. Yhteinen kaava toistuu: kun korjaus julkaistaan, hyökkääjät lukevat sen yhtä tarkasti kuin ylläpitäjät, ja aikaa on tunteja, ei viikkoja.

• Shellshock (CVE-2014-6271), 2014. Bash-komentotulkin vika, joka oli ollut koodissa yli 20 vuotta. Hyökkäykset alkoivat tunneissa julkistuksesta, ja hyökkääjät rakensivat murretuista palvelimista bottiverkkoja. Lähin vertailukohta PHP2Shellille: vuosikymmeniä vanha vika peruskomponentissa, jota moni ei edes tiennyt käyttävänsä.
• Log4Shell (CVE-2021-44228), 2021. Javan Log4j-lokikirjaston vika, jota hyödynnettiin jo ennen julkistusta. Laajin vertailukohta, koska kirjasto oli piilossa tuhansissa tuotteissa ja pelkkä löytäminen oli työlästä. PHP:n kohdalla tiedät yleensä, missä se pyörii.
• regreSSHion (CVE-2024-6387), 2024. OpenSSH-etähallintapalvelimen vika, joka mahdollisti kirjautumattoman etäsuorituksen pääkäyttäjän oikeuksin. Haavoittuvia palvelimia arvioitiin olevan yli 14 miljoonaa. Kuten PHP2Shellissa, kyse oli vanhasta, jo kertaalleen korjatusta virheestä, joka palasi koodiin myöhemmän muutoksen mukana.
• CVE-2024-4577, 2024. Edellinen kriittinen PHP:n ydinvika. Hyökkäykset alkoivat päivän päästä korjauksesta, ja kiristyshaittaohjelmaryhmät ottivat sen käyttöön. Se koski kuitenkin vain harvinaista Windows- ja CGI-yhdistelmää, kun PHP2Shell koskee jokaista web-asennusta.

PHP2Shell ei ole laajuudeltaan Log4Shellin veroinen, koska PHP on helpompi paikantaa kuin syvälle tuotteisiin upotettu kirjasto. Silti se yhdistää Shellshockin ja regreSSHionin pahimmat piirteet: vuosia vanha vika peruskomponentissa, kirjautumaton etäsuoritus, julkinen hyökkäyskoodi heti alussa ja pitkä häntä päivittämättömiä palvelimia. Suurin ero on kohteen koko, sillä yksi vika koski yhtä aikaa noin 70 prosenttia verkon tunnistetuista palvelinsovelluksista.

Näin Druidilla toimittiin: päivitykset valmiina ennen kahta yöllä

Päivitimme ylläpidossamme olevien verkkopalvelujen PHP:n saman illan ja yön aikana. Viimeiset ympäristöt valmistuivat keskiviikon ja torstain välisenä yönä vähän ennen kello kahta.

Tieto tulevasta hätäjulkaisusta oli tiimillämme jo keskiviikkoaamuna seitsemän jälkeen, ja Drupalin tietoturvatiimi suositteli samana aamuna kaikkia Drupal-sivustojen omistajia varaamaan aikaa päivitykselle (Drupal PSA-2026-10-20). Päivän ja alkuillan aikana teimme kolme asiaa:

• Valmistelimme ympäristöjä etukäteen päivitystä varten. Näin illalla jäi mahdollisimman pitkälti jäljelle vain tarkistus ja julkaisu.
• Pystytimme tilannehuoneen. Avasimme julkaisun alla yhteisen päivystyspalaverin, jossa kehittäjät ja ylläpitäjät pystyivät sopimaan päätöksistä ja hyväksynnöistä ilman viivettä.
• Lisäsimme väliaikaisia suojauksia. Osassa palveluja rajoitimme tiedostonlatauslomakkeiden käsittelyä väliaikaisesti, koska tunnettu hyökkäysreitti kulki niiden kautta. Suojaukset eivät korvanneet päivitystä, mutta ne pienensivät riskiä odotuksen ajan.

Itse päivitys ei ollut yhden napin painallus. PHP ajetaan palvelimilla konttikuvina, eli valmiiksi paketoituina ajoympäristöinä, ja jokainen kuva piti rakentaa uudelleen korjatulla PHP-versiolla. Päivitykset valuivat ympäristöstä riippuen saataville illan mittaan ja niiden saavuttua julkaisuja vietiin tuotantoon tasaisena virtana kehitys-, testaus- ja tuotantoympäristöihin.

Lopuksi kävimme vielä ympäristöt läpi. Tarkistuksessa löytyi kuuden sivuston kokonaisuus, josta päivitys puuttui, ja se päivitettiin saman tien. Viimeiset päivitykset valmistuivat vähän ennen kahta yöllä.

Tämä ei ollut sankaritarina vaan ylläpitotyön ydin. Kriittisessä tilanteessa ratkaisee kolme asiaa: tiedät tarkalleen, mitä ympäristöjä ja versioita sinulla on, päivityksen voi rakentaa ja julkaista automaattisesti, ja paikalla on ihmiset, jotka tuntevat palvelut. Nämä rakennetaan rauhallisina viikkoina, ei kriisi-iltana.

Mitä tästä kannattaa ottaa opiksi

PHP2Shell ei jää viimeiseksi laatuaan. PHP Foundation kertoo, että tekoälyavusteinen tietoturvatutkimus on moninkertaistanut sille tulevien haavoittuvuusilmoitusten määrän. Sama kehitys koskee kaikkia avoimen lähdekoodin projekteja: vikoja löytyy nopeammin, ja ylläpitäjän reaktioaika lyhenee. Näin varmistat, että verkkopalvelusi kestää seuraavankin kerran:

1. Selvitä, millä PHP-versiolla palvelusi pyörii. Jos vastaus on 8.1 tai vanhempi, palvelusi on nyt ilman virallista korjausta. PHP 8.2:n tietoturvatuki päättyy 31.12.2026, joten senkin päivitys kannattaa aikatauluttaa nyt.
2. Kysy ylläpitäjältäsi, milloin palvelusi päivitettiin. Hyvä kumppani kertoo päivämäärän ja kellonajan ilman, että sitä pitää selvittää. Jos vastaus on epämääräinen, se on tärkeä tieto sekin.
3. Älä unohda sivuprojekteja. Kampanjasivut, vanhat intranetit ja testiympäristöt ovat tyypillisiä paikkoja, joihin hyökkääjät pääsevät vuosien päästä. Shellshockin opetus pätee edelleen: päivittämättömiä laitteita hyödynnettiin vielä vuosia myöhemmin.
4. Varaudu jälkiaaltoon. Laajan haavoittuvuuden jälkeen liikkeellä on usein kiristysviestejä, joissa väitetään tietojen päätyneen hyökkääjälle. Älä maksa äläkä vastaa, vaan ole yhteydessä poliisiin ja seuraa Kyberturvallisuuskeskuksen ohjeita.

Tietoturvassa ei ole tarjolla täydellistä suojaa, mutta reaktioaika on asia, johon voit vaikuttaa. Druidilla ylläpito tarkoittaa sitä, että palveluasi seurataan myös silloin, kun kello on yli puolenyön. Jos haluat keskustella verkkopalvelusi ylläpidosta tai PHP-version päivityssuunnitelmasta, ota yhteyttä.

Lähteet ja lisälukemista

Viralliset tiedotteet

• PHP:n ennakkoilmoitus hätäjulkaisusta
• PHP 8.2.35 -julkaisu ja tietoturvatiedote
• PHP Foundation: jälkikatsaus julkaisuun
• Drupal PSA-2026-10-20

Tekninen analyysi

• watchTowr: PHP2Shell FAQ
• Akamai: Understanding PHP2Shell
• Safe Security: PHP2Shell Explained
• TryHackMe: The PHP Patch Is Out

Uutisia

• Computing: PHP rushes out emergency fixes
• The National News Desk: Critical PHP flaws put millions of websites at risk
• Anadolu Agency: NSA, FBI urge fixes
• OfficeChai: PHP Rushes Out Emergency Patch

Vertailukohdat

• Wikipedia: Shellshock
• CISA: Log4Shell
• SecurityWeek: regreSSHion
• BleepingComputer: CVE-2024-4577