PHP2Shell: kriittinen PHP-haavoittuvuus — onko verkkosivustosi vaarassa?

Haavoittuvuus koskee kaikkia PHP-versioita, jotka omassa haarassaan ovat vanhempia kuin 8.5.12, 8.4.27, 8.3.36 ja 8.2.35, ja se tarkoittaa lähes jokaista PHP-verkkosivustoa, jota kukaan ei ole tällä viikolla päivittänyt. Tämän päivän ensimmäinen työ on selvittää, mikä versio palvelee verkkosivustoasi, ja päivittää se — täydellistä kiertotietä ei ole, ja PHP:n oma tiedote sanoo, että päivittäminen on ainoa turvallinen valinta.

Keskiviikkona 21. lokakuuta PHP-tiimi julkaisi samanaikaisesti neljä hätäversiota. Haavoittuvuuspari, jonka ne korjaavat, on saanut nimen PHP2Shell, ja se kuvaa tuloksen tarkasti: verkkopyynnöstä koodin suorittamiseen palvelimella. Tämä artikkeli kertoo, mitä tarkalleen on löydetty, miten näet, koskeeko se sinua, ja missä järjestyksessä toimit — myös silloin, kun et voi päivittää heti.

Mikä on PHP2Shell ja mitä tapahtui 21. lokakuuta

Virallisessa tiedotteessa sanotaan, että 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 korjaavat kaksi kriittistä haavoittuvuutta, jotka voivat sallia tunnistautumattoman hyökkääjän suorittaa koodia etänä (RCE), ja että kaikkia PHP:n käyttäjiä kehotetaan painokkaasti päivittämään viipymättä. Samassa tiedotteessa on myös lause, joka määrää kaiken muun tässä artikkelissa: täydellistä kiertotietä ei ole, ja päivittäminen on ainoa turvallinen valinta.

PHP on antanut molemmille haavoittuvuuksille CVSS v4.0 -pisteet 9,2 / 10, mutta ne ovat kaksi erillistä virhettä, joilla on eri mekanismi ja, kuten jäljempänä näet, myös eri varmennuksen aste — ja juuri tämä jälkimmäinen ero ratkaisee käytännössä, mistä palvelimesta aloitat.

CVE-2026-109618 — vioittunut muisti out-of-memory (OOM) -tilan jälkeen. Kun PHP:ltä loppuu muisti, se käyttää funktiota longjmp() keskeyttääkseen pyynnön käsittelyn. Virallinen kuvaus toteaa, että joissakin kohdissa pyynnön muistiin pääsee käsiksi, ennen kuin se on täysin alustettu; jos muistin varaus epäonnistuu juuri silloin, keskeytystä ei käsitellä oikein ja jäljelle jää kelvoton muisti, jota lopetuskoodi vielä lukee tai jonka perusteella se tekee päätöksen.

Tärkeä yksityiskohta, joka muuttaa sitä, ketä tämä uhka koskee: out-of-memory (OOM) -tila saavutetaan erityisesti valmistellulla multipart-pyynnöllä, eikä siinä tarvitse olla yhtään ladattua tiedostoa. Virallinen kuvaus mainitsee useita multipart-käsittelyn ongelmia — pyynnön, jolla ei ole käyttökelpoista ilmoitettua pituutta, osan, jossa on rajoittamaton määrä otsakkeita, ja tyhjät tiedostokentät, joita ei lasketa rajoituksiin. Se tarkoittaa, että pyyntö voi olla aivan pieni ja mahtua tavallisiin post_max_size- ja memory_limit-rajoihin.

CVE-2026-109619 — vanhentunut globaali tila. PHP-prosessissa pyyntöjen välillä säilyy globaali tila: virheiden, istuntojen, objektien ja laajennusten tiedot. Virallinen kuvaus sanoo, että tämä tila on nollattava, ennen kuin pyynnön muisti vapautetaan. Jos nollauksen keskeyttää fataalivirhe tai jos diagnostiikka lopetushetkellä täyttää tilan uudelleen, muisti vapautetaan, mutta osoitin siihen jää. Tätä virheluokkaa kutsutaan kansainvälisesti nimellä Use-After-Free (UAF) — muistia käytetään sen jälkeen, kun se on jo vapautettu.

Edelleen on ehto, joka tekee tästä haavoittuvuudesta vaikeamman kuin miltä se kuulostaa: vanhentunutta osoitinta voi käyttää vain toiminto, joka tapahtuu ennen tavallista pyynnön alustusta, ja virallinen kuvaus nimeää kaksi vahvistettua tällaista tapausta — INI-diagnostiikan ja istunnon latauksen etenemisen käsittelyn. Lisäksi hyökkääjän myöhemmän pyynnön on osuttava juuri siihen samaan prosessiin, jossa vioittunut tila syntyi, joten yksittäinen yritys onnistuu harvoin, ja kuvaus toteaa suoraan, että useat prosessit ja niiden vaihtaminen pienentävät todennäköisyyttä mutta eivät poista itse ehtoa.

Kuinka helppoa tätä on hyödyntää ja mitä vastaan se on osoitettu

Tässä kannattaa olla täsmällinen, koska juuri tässä kohdassa suurin osa verkossa olevista artikkeleista liioittelee suuntaan tai toiseen.

Salasanaa ei tarvita, eikä tarvita sitäkään, että joku painaa sivustolla jotakin — CVSS-vektorissa se näkyy koodeina PR:N ja UI:N. Samassa vektorissa on kuitenkin AC:H ja AT:P: hyökkäyksen monimutkaisuus on arvioitu korkeaksi, ja sillä on lisäedellytyksiä. Käytännössä se tarkoittaa toistuvia yrityksiä, ja onnistuminen riippuu PHP-käännöksestä, laajennuksista, frontendin käyttäytymisestä ja muistin asettelusta. Ei siis — yksi tavallinen pyyntö ei riitä; mutta se ei maksa hyökkääjälle mitään, koska yritysten määrää ei rajoita mikään.

Varmennuksen aste eroaa virheiden välillä, ja tämä ero on tärkeä, kun päätät, kuinka kovaa kiirehtiä. CVE-2026-109618:n tapauksessa täysi RCE on vahvistettu mod_php:tä vastaan oletusarvoisilla syöte- ja muistirajoilla; PHP-FPM:n osalta sama kuvaus sanoo, että lähdekoodianalyysi pitää sitä haavoittuvana, mutta täyttä PHP-FPM-hyökkäystä ei ole osoitettu. FrankenPHP mainitaan siinä mod_php:n vastineena ja LSAPI PHP-FPM:n vastineena, kummassakaan tapauksessa ilman tarkistettua hyökkäystä.

CVE-2026-109619:n tapauksessa istunnon elinkaaren polku on tarkistettu sekä mod_php:tä että PHP-FPM:ää vastaan, kun taas toinen polku, joka kulkee fataalivirheen jäljityksen kautta, on vahvistettu vain mod_php:tä vastaan.

Tästä seuraa käytännön järjestys: jos verkkosivustosi toimii mod_php:llä, olet ensimmäisenä jonossa, koska juuri siellä molemmat virheet on vahvistettu. PHP-FPM:n ja LiteSpeedin tapauksessa riski on todellinen, mutta toistaiseksi vain osittain vahvistettu. Yhdessäkään näistä tapauksista se ei ole syy odottaa — se on syy tietää, mistä palvelimesta aloitat.

Miltä tämä viikko näytti tunti tunnilta

Aikajärjestys ei ole kuriositeetti — se selittää, miksi ensimmäisten tuntien suositukset erosivat nyt voimassa olevista ja miksi osa verkossa olevista artikkeleista on yhä vanhentuneita.

20. lokakuuta illalla tiedettiin, että jotakin on tulossa, mutta ei tiedetty, mitä tarkalleen: PHP oli ilmoittanut tulevasta hätäjulkaisusta, ja CloudLinuxin tilasivu kirjasi samana iltana, että tekniset tiedot ja altistuneet versiot on suunniteltu julkaistaviksi seuraavan päivän julkaisuhetkellä. Tekninen kuvaus ei silloin ollut vielä julkinen.

Seuraavaan päivään mennessä tilanne oli muuttunut, eikä parempaan: 21. lokakuuta aamulla CloudLinux kirjasi, että julkisessa kierrossa on jo hyökkäysmalli, ja kello 9.08 UTC se jakoi palomuurisääntöjoukon, joka estää tunnetun hyväksikäyttöpyynnön mallin. Kahdeksantoista minuuttia myöhemmin samalle sivulle ilmestyi lause, joka kuvaa tätä viikkoa parhaiten — tätä mallia vastaavia yrityksiä havaitaan jo, joten joku etsi jo palvelimia, joilla korjausta ei vielä ole.

PHP:n korjaukset ilmestyivät kello 14.00 UTC, mikä tarkoittaa, että julkisesti saatavilla olevan hyökkäysmallin ja julkisesti saatavilla olevan korjauksen väliin jäi useita tunteja, ja näinä tunteina hyökkäysyrityksiä jo tapahtui.

Yksi varauma on tässä rehellistä sanoa: maailma ei ollut täysin ilman korjausta, sillä PHP:n tiedotteessa sanotaan, että Linux-jakelut ja pitkäaikaisen tuen toimittajat saivat korjaukset etukäteen, joten osalla palvelimista päivitys oli saatavilla aiemmin kuin muilla — julkisesti saatavilla se ei kuitenkaan ollut kenellekään.

Sen jälkeen alkoi pitempi osa, joka jatkuu yhä: pakettien jakelu. Käyttöjärjestelmien ylläpitäjät ja hosting-alustat rakentavat pakettinsa erikseen, ja ne ilmestyvät tuntien tai päivien kuluessa, kukin omaan tahtiinsa. Juuri tässä vaiheessa on suuri osa webhotellin käyttäjistä, ja juuri siksi kysymys ”onko tietoturvakorjaus ilmestynyt” ja kysymys ”onko tietoturvakorjaus omalla palvelimellani” ovat tällä viikolla kaksi eri kysymystä, joilla on eri vastaukset.

Onko verkkosivustosi vaarassa

Virallisissa varoituksissa altistuneiden versioiden alueet on kirjoitettu näin: kaikki, mikä on vanhempaa kuin 8.2.35, kaikki, mikä on vanhempaa kuin 8.3.36, kaikki, mikä on vanhempaa kuin 8.4.27, ja kaikki, mikä on vanhempaa kuin 8.5.12 — kukin omassa haarassaan.

Tärkeä yksityiskohta, jossa on helppo erehtyä: luku, jonka php -v näyttää, ei aina kerro kaikkea. Linux-jakelut ja hosting-alustat siirtävät tietoturvakorjauksen usein vanhempaan versioon numeroa muuttamatta — muuttuu vain paketin julkaisunumero. Silloin 8.4.26 voi olla jo korjattu, mutta voi myös olla korjaamatta. Ainoa tapa tietää se on katsoa paketin kuvausta tai kysyä toimittajalta; pelkkä versionumero ei vastaa tähän kysymykseen.

Erikseen vanhemmista versioista. PHP 8.1 ja sitä vanhemmat eivät enää saa PHP-projektilta säännöllisiä päivityksiä, mutta vakavuuden vuoksi tietoturvatiimi on valmistellut minimaaliset lähdekoodikorjaukset versioille 7.4, 8.0 ja 8.1 — niille, jotka kääntävät lähdekoodista tai joilla ei ole ylläpitäjän tukea. Tiedote suosittelee samassa olemaan yhteydessä omaan toimittajaan, koska osa jakeluista ja pitkäaikaisen tuen toimittajista siirtää korjaukset. Jos verkkosivustosi toimii PHP 7.x:llä, oikea ongelma ei ole tämä viikko — oikea ongelma on, että seuraavalla kerralla korjausta ei välttämättä ole. Ja PHP 8.2, joka tällä kertaa sai tietoturvakorjauksen, tulee elinkaarensa päähän 31. joulukuuta 2026 (elinkaaren päättyminen, EOL).

Miten version tarkistat sen mukaan, missä sivusto asuu

Tarkistus vie minuutteja, ja se kannattaa tehdä jokaiselle sivustolle erikseen, ei jokaiselle palvelimelle: yhdellä palvelimella asuu usein sivustoja, joilla on eri PHP-versiot, ja yleensä juuri se vanhin, jonka kaikki ovat unohtaneet, on julkisesti saavutettavissa.

Jaettu hosting ja cPanel. Version näyttää MultiPHP Manager -osio, jossa jokaisella verkkotunnuksella on oma rivinsä; Plesk käyttää samaan asiaan PHP Settings -näkymää kunkin tilauksen sisällä. Molemmissa tapauksissa kannattaa varmistaa, että katsot sitä verkkotunnusta, josta on puhe, etkä palvelimen oletusta.

Oma palvelin tai VPS (virtuaalipalvelin). Komentorivillä sen näyttää php -v, mutta yhdellä olennaisella varauksella: komentorivin PHP on usein aivan eri versio kuin se, joka palvelee verkkopyyntöjä. Luotettavimman vastauksen antaa sama polku, jota sivusto käyttää — PHP-FPM-asetusten pool-kohdassa ilmoitettu suoritettava tiedosto.

Kontit. Jos sivusto toimii Docker-ympäristössä, version määrää konttikuva, ei isäntäkone, joten vaiheita on kaksi: rakenna konttikuva uudelleen päivitetyllä pohjakuvalla ja käynnistä sen jälkeen kontit uudelleen. Konttikuva, joka on rakennettu ennen 21. lokakuuta, ei sisällä korjausta, riippumatta siitä, kuinka usein kontti on käynnistetty uudelleen.

Jos pääsyä ei ole yhteenkään näistä. Silloin kysymys kuuluu hosting-palveluntarjoajalle, ja tällä viikolla se on täysin tavallinen kysymys, johon vastaus on jo valmiina. Muotoilu, joka säästää viestittelyä: ”Mikä PHP-versio palvelee verkkotunnustani, onko siinä PHP2Shell-korjaus, ja jos ei vielä ole, minä päivänä se on?”

Mitä tänään tehdään

Tämän päivän järjestys on tämä: päivitä ensin PHP ja käynnistä uudelleen kaikki, mikä suorittaa sitä, varmista sitten, että kävijöitä todella palvelee uusi versio, tarkista sen jälkeen, onko käyttämäsi pakettivarasto julkaissut korjauksen lainkaan, ja etsi jälkiä vasta sen jälkeen. Ensimmäinen askel vie minuutteja, viimeinen voi viedä päiviä, ja juuri siksi niitä ei kannata sekoittaa keskenään.

Ensiksi, päivitä. Hallitussa hostingissa sen tekee palveluntarjoaja, ja sinun työsi on esittää kysymys ja saada päivämäärä. Jos hallitset palvelinta itse, pakettien päivityksen jälkeen on käynnistettävä uudelleen se, mikä suorittaa PHP:tä: Apache, PHP-FPM tai LSAPI. Tämä askel jää yllättävän usein väliin — paketti on vaihdettu, mutta vanhat prosessit jatkavat vanhalla koodilla, niin että tarkistus näyttää uuden version, kun kävijöitä palvelee yhä vanha.

Toiseksi, tarkista, että päivitys on todella käytössä — samaa polkua, jota sivusto käyttää, ei komentorivin kautta.

Kolmanneksi, jos käytät vapaaehtoisesti ylläpidettyä pakettivarastoa, tarkista, onko se julkaissut korjauksen. PHP:n tiedotteessa on erillinen varoitus osoitteesta rpms.remirepo.net: sen käyttäjiä kehotetaan siirtymään jakelun paketteihin tai kääntämään lähdekoodista.

Neljänneksi, vasta sen jälkeen tarkista, onko sivustolla jälkiä. Päivitys sulkee oven, mutta ei vastaa siihen, onko joku jo tullut siitä sisään.

Jos et voi päivittää heti

Tämä osio kannattaa lukea niin, että on selvää: yksikään tässä mainituista askeleista ei korvaa päivitystä — PHP:n tiedote sanoo sen suoraan.

CVE-2026-109618:aa vastaan tiedote mainitsee muistirajan poistamisen: memory_limit=-1, ja vielä niin, ettei sovellus voi kirjoittaa sitä yli — esimerkiksi asetuksella php_admin_value PHP-FPM:n tai Apachen asetuksissa, niin ettei mikään muu asetus palauta lopullista rajaa takaisin. On ymmärrettävä, mitä tämä valinta maksaa: jaetulla palvelimella se vaihtaa yhden riskin toiseen, koska yksi pyyntö voi nyt syödä kaiken käytettävissä olevan muistin. Haavoittuvuuden kuvauksessa varoitetaan myös käyttämästä rajoja RLIMIT_AS ja RLIMIT_DATA, koska ne voivat saada muistin varauksen epäonnistumaan ja johtaa siten juuri haavoittuvaan polkuun.

CVE-2026-109619:ää vastaan tiedote mainitsee asetuksen session.upload_progress.enabled=0 ja PHP 8.5:n tapauksessa asetuksen fatal_error_backtraces=0 — molemmissa tapauksissa huomautuksella, että kaikki prosessit käynnistetään sen jälkeen uudelleen. Itse haavoittuvuuden kuvauksessa on myös pm.max_requests=1, joka pakottaa PHP-FPM:n vaihtamaan PHP-FPM-workerin jokaisen pyynnön jälkeen; se on PHP-FPM-poolin asetus, ja siinä se mainitaan varauksella ”jos suorituskyky ei ole tekijä”. Samassa sanotaan myös se, mikä pitää tämän toimen oikeissa rajoissaan: prosessin vaihtaminen pienentää todennäköisyyttä yhtä pyyntöä kohti, mutta ei poista itse ehtoa.

Hyödyllistä on myös se, mikä ei ole kiertotie mutta pienentää hyökkäyspintaa: maltillinen post_max_size, kohtuullinen syötteen sisäkkäisyyden syvyys ja rajoitettu latausten määrä. Ne ovat hyviä arvoja minä tahansa viikkona, ei vain tällä.

Miten tunnistat, onko sivustoosi jo kajottu

Päivityksen jälkeen kannattaa käydä läpi verkkopalvelimen lokit viime päiviltä. Etsittävä on poikkeuksellisen suuri määrä multipart-pyyntöjä yhteen ja samaan osoitteeseen — ja tässä on helppo etsiä väärin: ne ovat usein pieniä ja mahtuvat tavallisiin rajoihin, joten niitä ei löydä koon perusteella. Paljastavampia ovat äkilliset 500-virheiden sarjat, jotka alkavat ja loppuvat ilman näkyvää syytä: hyökkäys, joka nojaa out-of-memory (OOM) -tilaan, epäonnistuu paljon useammin kuin onnistuu, ja jokainen epäonnistunut yritys jättää virheen.

Tiedostojärjestelmässä merkitystä on muutosajoilla: PHP-tiedosto, jota on muutettu yöllä, kun kukaan ei työskennellyt, on selitettävä. Kannattaa tarkistaa myös ajastetut tehtävät ja merkinnät, jotka käynnistävät ohjelman automaattisesti uudelleenkäynnistyksen jälkeen — hyökkääjälle, joka pystyy suorittamaan koodia, ensimmäinen työ on vakiinnuttaa asema, jotta pääsy selviää juuri siitä päivityksestä, jonka juuri asensit.

Erikseen kannattaa tarkistaa ylläpitäjätilien luettelo sekä sovellusten salasanat ja avaimet. Jos koodia on suoritettu, kaikkea, minkä palvelin tietää, on pidettävä luettuna — myös tietokannan kirjautumistietoja ja API-avaimia asetustiedostossa.

Jos jokin tästä ei näytä oikealta, puhdistus on erillinen työ, jolla on oma järjestyksensä, ja se kannattaa tehdä menetelmällisesti eikä poistamalla epäilyttäviä tiedostoja yksi kerrallaan. Olemme kuvanneet sen erikseen — miten hakkeroidun verkkosivuston palauttaminen etenee, ja jos haluat, että sen tekee joku muu, hakkeroidun sivuston palautus on erillinen palvelu, jolla on kiinteä järjestys: eristäminen, puhdistus, syyn poistaminen ja tarkistus, että sivusto on poistettu hakukoneiden turvallisuusvaroituksista.

Milloin tapahtumasta tulee ilmoitettava henkilötietojen tietoturvaloukkaus

Jos on aihetta ajatella, että hyökkääjä on päässyt käsiksi henkilötietoihin, teknisestä kysymyksestä tulee myös oikeudellinen. Yleinen tietosuoja-asetus (asetus (EU) 2016/679) asettaa määräajan, joka ei ala hyökkäyksestä vaan siitä hetkestä, kun rekisterinpitäjä on saanut tietää henkilötietojen tietoturvaloukkauksesta: ilmoitus valvontaviranomaiselle, Suomessa tietosuojavaltuutetun toimistolle, on tehtävä mahdollisuuksien mukaan viimeistään 72 tunnin kuluessa. Velvollisuutta ei synny, jos henkilötietojen tietoturvaloukkauksesta ei todennäköisesti aiheudu luonnollisten henkilöiden oikeuksiin ja vapauksiin kohdistuvaa riskiä, ja jos riski on korkea, myös henkilöille itselleen on ilmoitettava — tälläkin velvollisuudella on asetuksessa omat poikkeuksensa.

Tämän osion käytännön merkitys on yksi: hetki, jolloin lokeista on löytynyt jotakin epäilyttävää, ei ole hetki, jolloin 72 tuntia alkaa kulua — se on hetki, jolloin on selvitettävä, onko loukkaus ylipäätään tapahtunut. Yksittäinen 500-virheiden sarja, joka, kuten edellä kuvattiin, on useimmiten epäonnistunut yritys, ei itsessään ole loukkaus. Juuri siksi tätä selvitystä ei kannata lykätä siihen, ”kun on vähemmän töitä”, ja juuri siksi lokit on säilytettävä, ennen kuin lokikierto kirjoittaa ne yli: ne ovat ainoa todiste sekä siitä, mitä tapahtui, että siitä, mitä ei tapahtunut.

Jos vastuullasi on useita sivustoja

Toimistoille ja yrityksille, joilla on useita sivustoja, tämä viikko on vähemmän tekninen kuin organisatorinen tehtävä, ja järjestys, joka toimii, on yksinkertainen: ensin luettelo, sitten versiot, sitten päivittäminen tärkeysjärjestyksessä.

Tärkeysjärjestystä ei määrää sivuston tärkeys vaan se, onko sivusto julkisesti verkosta tavoitettavissa ja mikä sitä palvelee. Ylimpänä ovat julkisesti saatavilla olevat sivustot, jotka toimivat mod_php:llä, koska juuri siellä molemmat haavoittuvuudet on vahvistettu; sitten muu julkinen, ja vasta sen jälkeen sisäiset järjestelmät palomuurin takana. Testi- ja kehitysympäristöt, jotka kaikki unohtavat, on ehdottomasti otettava luetteloon — ne toimivat usein vanhemmalla PHP-versiolla ja ovat usein saavutettavissa internetistä, koska joskus se oli helpompaa.

Sivustot, joita joku muu hallitsee, jäävät luetteloon, mutta eri sarakkeella: kenelle kysymys on lähetetty ja minä päivänä vastaus on saatu. Tämä sarake osoittautuu myöhemmin arvokkaammaksi kuin muut, koska juuri se näyttää, mikä palveluntarjoaja reagoi ja mikä ei.

Mitä hallittu hosting tässä tapauksessa tarkoitti

Tämä viikko näyttää hyvin, missä kulkee raja alustan ja sovelluksen välillä, joten on rehellistä kertoa, miltä se näytti meidän puoleltamme.

Palvelimemme toimivat CloudLinuxilla, ja niissä on sisäänrakennettu Imunify360. Kun hyökkäysmalli alkoi kiertää julkisesti, CloudLinux kirjasi tilasivullaan, että palomuurisääntöjoukko, joka estää tunnetun hyväksikäyttömallin, jaettiin kello 9.08 UTC — useita tunteja ennen kuin PHP julkaisi itse korjauksen kello 14.00, ja ennen kuin samalle sivulle ilmestyi merkintä, että yrityksiä jo havaitaan. Päivän mittaan seurasi vielä kaksi täydennystä, joista jälkimmäinen estää jo julkisesti saatavilla olevan hyväksikäyttötyökalun. Kaikki tämä tapahtui automaattisesti, ilman asiakkaan osallistumista. Alalla tällaista toimea kutsutaan nimellä virtual patching: verkkosovelluspalomuurin (WAF) sääntö estää haavoittuvuuden hyväksikäytön muuttamatta itse haavoittuvaa koodia.

Ja nyt se, mitä tällainen lause ei tarkoita, koska juuri tässä kohdassa alalla myytiin tällä viikolla eniten liioittelua. Palomuurisääntö estää tunnettuja hyökkäysmalleja — samaa sanaa käyttää myös CloudLinux. Sama sivu kutsuu tätä toimea väliaikaiseksi ratkaisuksi, ei täydelliseksi korjaukseksi. Se ei ole haavoittumattomuutta, ja CloudLinux itse suosittelee yhä päivittämään PHP:n heti, kun paketit ovat saatavilla. Ero sanojen ”suojattu” ja ”korjattu” välillä on tällä viikolla aivan konkreettinen, ja yhden myyminen toisena olisi epärehellistä.

Miltä itse korjaus näyttää, on hyvä havainnollistus siitä, mistä varoitimme aiemmin. Palvelimemme saivat uuden ea-php84-käännöksen saman päivän iltana, muutama tunti PHP:n julkaisun jälkeen. Versionumero ei muuttunut — php -v kirjoittaa yhä 8.4.26, ei 8.4.27, ja ainoa, mikä ulkoa kertoo muutoksesta, on käännöksen päiväys, joka hyppäsi lokakuun 9. päivästä 21. päivään. Juuri tältä siirretty korjaus näyttää, ja juuri siksi kysymys hosting-palveluntarjoajalle on hyödyllisempi kuin luku, jonka näyttö näyttää.

Siksi arvo, jonka hallittu hosting tässä osti, ei ollut haavoittumattomuus vaan kaventunut aikaväli: tunnit, jolloin hyökkäysmalli jo kiersi ja yrityksiä jo tapahtui, katettiin estämällä tunnettu malli, eikä niitä jääty odottamaan. Ja sen jälkeen se, että joku seuraa paketteja ja käynnistää prosessit uudelleen eikä odota, että asiakas huomaa. Hallittu hostingimme alkaa 45 €:sta kuukaudessa, ja juuri tällaiset viikot ovat se, mistä tässä summassa maksetaan.

Jos verkkosivustosi toimii nyt jossakin, jossa kysymykseen PHP-versiosta ja päivityksen päivämäärästä ei saa vastausta, se on itsessään vastaus. Puhutaan siirrosta — siirto onnistuu yleensä ilman käyttökatkoa.

Päivityksen jälkeen on käynnistettävä uudelleen enemmän kuin miltä näyttää

Prosessi, joka pysyy käynnissä pyyntöjen välillä, ei ole mitään eksoottista — juuri näin toimii tavallinen PHP-FPM-pool ja mod_php, ja juuri niitä vastaan koodin suorittaminen on vahvistettu. Siksi CVE-2026-109619 ei ole jonkin erikoiskokoonpanon uhka; se on tavallisen kokoonpanon ongelma.

Tästä seuraa askel, joka useimmin jää väliin: paketin vaihto ei vaikuta prosessiin, joka jo on käynnissä. Päivityksen jälkeen on käynnistettävä uudelleen jokainen prosessi, joka suorittaa PHP:tä, ja se koskee myös niitä, joihin kukaan ei yleensä koske. Pitkään käynnissä olleet PHP-prosessit jäävät usein käynnistämättä uudelleen viikoiksi, joten päivityksen jälkeen ne kannattaa luetteloida erikseen ja varmistaa, että jokainen niistä on todella käynnistetty uudelleen.

Oikea tarkistuskysymys ei siksi ole ”mitä php -v näyttää”, vaan ”onko jokainen prosessi, joka suorittaa PHP:tä, käynnistetty sen jälkeen, kun paketti vaihdettiin”.

Miksi ei riitä, että ”emmehän me lataa mitään”

Tavallinen vastaväite kuuluu suunnilleen näin: sivustomme on käyntikorttisivusto, siinä ei ole latauslomaketta eikä käyttäjätiliä, joten tämä ei koske meitä. Valitettavasti koskee, ja syy on juuri se, mikä kuvattiin edellä: hyökkäys ei tarvitse ladattua tiedostoa, riittää erityisesti muotoiltu multipart-pyyntö, ja sen voi lähettää mihin tahansa osoitteeseen, joka vastaa PHP:llä. Lomakkeen olemassaolo sivulla ei ole edellytys, koska hyökkääjä ei täytä lomaketta.

Samoin ei ole merkitystä sillä, onko sivusto pieni. Tällaisia haavoittuvuuksia hyödynnetään laajamittaisesti ja automaattisesti, eikä valintaa kävijämäärän mukaan tee kukaan. Palo Alto Networks -yksikkö Unit 42 julkaisupäivänä raportoi yli 22,6 miljoonasta internetistä saavutettavasta PHP-instanssista, jotka ovat mahdollisesti altistuneita; yhtäkään niistä ei ole valittu erikseen.

Toinen vastaväite koskee WordPressiä ja lisäosia. Sekin on tällä kertaa väärä, vain vastakkaiseen suuntaan: haavoittuvuus on itse PHP:ssä, ei WordPressissä, Laravelissa eikä missään lisäosassa. Se tarkoittaa, että lisäosien päivittäminen ei ratkaise tätä ongelmaa, ja samalla että altis on jokainen PHP-verkkosivusto riippumatta siitä, mille se on rakennettu.

Mitä tästä viikosta kannattaa pitää mukana

Niitä, joilla kaikki oli kunnossa, ei auttanut nopea reagointi vaan kolme asiaa, jotka oli hoidettu aiemmin: tiedettiin, mikä sivusto millä PHP-versiolla toimii, tiedettiin, kuka vastaa päivittämisestä, ja oli varmuuskopiot, joista oli todella tarkistettu, että sivuston voi palauttaa.: tiedettiin, mikä sivusto millä PHP-versiolla toimii, tiedettiin, kuka vastaa päivittämisestä, ja oli varmuuskopiot, joista on todella tarkistettu, että sivuston voi palauttaa. Yhtäkään niistä ei voi tehdä sinä päivänä, kun varoitus on jo julkaistu, ja juuri siksi tämä viikko oli joillekin tiimeille puoli tuntia työtä ja toisille kaksi päivää.

Jos tästä viikosta on otettava yksi tehtävä, jotta ensi kerralla olisi helpompaa, se on luettelo: jokainen sivusto, sen PHP-versio, tapa, jolla se suoritetaan, sen hosting-palveluntarjoaja ja ihminen, joka saa painaa ”päivitä”. Seuraava tällainen varoitus tulee, ja ainoa kysymys on, kuinka kauan silloin kestää vastata kysymykseen ”koskeeko tämä meitä”.