PHP2Shell: Mitä tapahtui ja mitä siitä opittiin

PHP:stä löytyi lokakuussa kaksi kriittistä tietoturva-aukkoa. Korjaukset julkaistiin 21.10.2026. Samana päivänä osa valtionhallinnon verkkopalveluista ajettiin alas varotoimena, ja aihe nousi uutisiin. Mistä PHP2Shell-haavoittuvuudessa oli kyse? Oliko koko internet vaarassa? Oliko sivustojen sulkeminen ennen korjauksen julkaisua oikeasuhtainen toimenpide vai ylireagointia? 

Kirjoittaja: Jukka Isokoski

26.10.2026

• Uutiset

Taustaa: Mikä PHP on?

PHP on ohjelmointikieli, jota käytetään verkkopalveluiden palvelimilla. Moni sisällönhallintajärjestelmä on tehty PHP:lla, esimerkiksi WordPress, Drupal ja Joomla.

PHP toimii verkkopalvelun backendissä eli palvelimella. Siellä pyörii palvelun toimintalogiikka, keskustelu tietokannan kanssa ja HTML-sivujen kokoaminen. Käyttäjän omalla laitteella PHP-koodia ei suoriteta. Selaimeen tulee vain PHP:n kokoama HTML sekä siihen liittyvät tyylit ja scriptit.

PHP-koodia ei käännetä etukäteen erilliseksi ohjelmaksi. Palvelimella oleva PHP-tulkki lukee ja suorittaa koodin aina pyynnön tullessa. Palvelimen PHP-versio määrittää, miten koodi tulkitaan ja mitä ominaisuuksia on käytössä. Se määrittää myös, mitkä tietoturvakorjaukset on palvelimella.

Kieltä kehittää avoimen lähdekoodin yhteisö. Vuonna 2021 perustettu PHP Foundation palkkaa ydinkehittäjiä ja tukee tietoturvatyötä. Rahoitus tulee yrityksiltä ja julkisilta toimijoilta.

W3Techsin mukaan PHP:tä käyttää 69,3 prosenttia niistä sivustoista, joiden palvelinpuolen kieli tiedetään. Kirjo on laaja: blogeja, verkkokauppoja, yritysten sivuja, intranettejä ja julkisen sektorin palveluja. Suosio selittyy sillä, että PHP on helppo ottaa käyttöön, sitä tukee lähes jokainen hosting-palvelu ja sen päälle on rakennettu suosituimmat julkaisujärjestelmät. Sama laajuus on myös riski. Paljon sivustoja on pystytetty kerran, eikä niitä ylläpidetä aktiivisesti.

Haavoittuvuus ja sen havainnointi

PHP2Shell on yhteinen nimi kahdelle haavoittuvuudelle. Molemmat ovat PHP-tulkissa itsessään, eivät WordPressissä tai muussa sovelluksessa. Molempien vakavuusluokitus on CVSS 9.2 asteikolla 0–10, eli kriittinen.

• CVE-2026-109618: PHP antaa jokaiselle pyynnölle muistirajan. Jos raja ylittyy, PHP keskeyttää pyynnön ja siivoaa jäljet. Keskeytys voi osua hetkeen, jolloin pyynnön tiedot ovat vasta puoliksi valmiita, mutta siivousvaihe käsittelee niitä silti valmiina. Hyökkääjä voi lähettää tarkoituksella raskaan pyynnön, ja käyttää syntyvää sekaannusta oman koodinsa ajamiseen palvelimella.
• CVE-2026-109619: Sama PHP-prosessi palvelee monta pyyntöä peräkkäin. Jokaisen pyynnön jälkeen sen tiedot pitäisi siivota pois. Jos pyyntö kaatuu virheeseen väärällä hetkellä, prosessiin jää viittauksia muistiin, joka on jo vapautettu muuhun käyttöön. Hyökkääjä voi lähettää ensin pyynnön, joka jättää tällaisen viittauksen, ja sitten toisen pyynnön, joka hyödyntää sitä oman koodinsa ajamiseen.

Pahimmillaan hyökkääjä voi ajaa omaa koodiaan palvelimella ilman tunnuksia. Hyökkäys tapahtuu ennen kuin sovelluksen omat suojaukset ehtivät toimia. Siksi edes hyvin rakennettu sovellus ei tässä tapauksessa riittänyt suojaamaan haavoittuvuudelta.

Riski oli suurin Apache-palvelimilla, joissa PHP on asennettu Apachen moduuliksi (mod_php). Kyberturvallisuuskeskuksen tiedotteen mukaan tälle yhdistelmälle oli tarjolla toimiva hyökkäystapa. redandbluen palvelinkumppani Seravolla on käytössä nginx-palvelimet, joissa PHP pyörii erillisenä PHP-FPM-palveluna. Myös tämä yhdistelmä kuului haavoittuvien piiriin, mutta hyökkäyksen toteuttaminen vaati enemmän ehtoja.

Korjatut versiot PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 julkaistiin 21.10.2026 kello 17 Suomen aikaa. Asetusmuutoksilla riskiä pystyi pienentämään, mutta ainoa täydellinen korjaus oli päivitys. Suurin riski on siis palvelimilla, joita ei päivitetä.

Korjausten asentamisen aikaikkuna oli kriittinen. Kun korjaus julkaistaan, päivitys on tehtävä nopeasti. Korjauksesta näkee, mitä se muuttaa. Sen jälkeen hyökkääjän on helpompi rakentaa toimiva hyökkäys ja kohdistaa se päivittämättömiin palvelimiin. Turvattomin hetki on siis aika korjauksen julkaisun jälkeen, ennen kuin päivitykset on asennettu. Luotettava ja aktiivinen palvelinkumppani asentaa kriittiset päivitykset palvelimille välittömästi. Seravo aloitti päivitysten asentamisen redandbluen asiakkaiden palvelimille heti kun korjatut versiot olivat saatavilla. Kaikki palvelimet oli päivitetty muutamassa tunnissa.

PHP 8.2:n tietoturvapäivitykset päättyvät 31.12.2026. Sen jälkeen versio ei saa vastaavia kriittisiä korjauksia. PHP 8.1 ja vanhemmat eivät saaneet tällä kertaa virallista päivitystä lainkaan. Kaikki redandbluen ylläpitämät sivustot ovat PHP 8.2:ta uudemmissa versioissa.

Miksi haavoittuvuus aiheutti niin suuren keskustelun?

Haavoittuvuudet löytyivät tekoälyn avulla. Tietoturvatutkijat käyttävät nyt tehokkaimpia kielimalleja haavoittuvuuksien etsimiseen ja korjaamiseen ennakoivasti. PHP Foundationin mukaan saman juurisyyn raportoi kesällä kolme tahoa toisistaan riippumatta. Heinäkuun alun jälkeen PHP:lle on julkaistu 15 CVE-tunnistetta. Havaintojen määrä on kasvanut, kun kielimallit ovat tehostuneet.

Kun haavoittuvuus löytyy, sitä ei julkaista ennen kuin korjaus on valmis. Etukäteen tiedetään vain, että korjaus on tulossa. Ei tiedetä, mitä se tarkalleen koskee tai miten hyökkäys toimisi. Siksi ennakoiva reagointi on vaikeaa. Suljetaanko palvelu varmuuden vuoksi vai odotetaanko päivitystä? Jälkikäteen arvio on helpompi tehdä.

Tällä kertaa tilannetta vaikeutti vuoto. Haavoittuvuuksien tunnisteet levisivät verkkoon 20.10., eli päivää ennen suunniteltua julkaisua, ja PHP aikaisti korjauksia. 21.10. Valtori ajoi alas osan valtion julkisista verkkopalveluista. Ylen mukaan syynä oli varotoimi, ei hyökkäys tai tietomurto. Vastaavia kehotuksia antoivat viranomaiset muun muassa Ruotsissa, Isossa-Britanniassa ja Japanissa.

Kaikki toimijat eivät kuitenkaan sulkeneet sivustojaan. Palvelinkumppanimme Seravo ajoi alas vain ne sivustot, joiden omistajat sitä erikseen pyysivät. Linja vastasi ENISAn ja muiden EU:n kyberturvallisuustoimijoiden yhteistä suositusta: ensisijaisesti päivitetään, ja palvelu eristetään julkisesta verkosta vain, jos päivittäminen ei onnistu heti. Sulkeminen on itsessään riski kriittisille palveluille, ja asiakas tuntee parhaiten oman organisaationsa tilanteen. Odotusaikana Seravo muutti PHP-asetuksia riskin pienentämiseksi, tehosti valvontaa ja lokitusta sekä piti valmiuden sulkea kaikki sivustot, jos tilanne olisi sitä vaatinut. Merkkejä haavoittuvuuksien hyödyntämisestä ei havaittu.

Mitä tästä opittiin? Voiko PHP-sivustoihin edelleen luottaa?

1. Tietoturvapäivitysten nopeus korostuu. Aikaa suojaamiseen on aiempaa vähemmän, ja tahti kiristyy. Valitse kumppani, jolla päivitysprosessi on hallussa.

2. Kriittisiä aukkoja löytyy enemmän kielimallien avulla, eikä tämä koske vain PHP:ta. Node.js julkaisi 21.10. korjaukset kymmeneen haavoittuvuuteen, joista yksi voi mahdollistaa koodin ajamisen palvelimella. F5 julkaisi edellisellä viikolla ylimääräiset korjaukset kolmeen kriittiseen nginx-haavoittuvuuteen. Iso-Britannian kyberturvallisuuskeskus ennakoi jo toukokuussa tällaista päivitysten aaltoa.

3. PHP pystyi korjaamaan aukot. Korjaukset tarjotaan versioille, jotka ovat tuen piirissä. Vanhalla PHP-versiolla on vaarallista ylläpitää mitään palvelua. Uudet versiot ovat turvallisempia ja saavat tukea. Päivityksiä ei ole varaa ohittaa.