Lyhyesti: Päivityksen ja hyökkäyksen välinen aikaikkuna oli PHP2Shellin kohdalla negatiivinen: mediaraporttien mukaan ensimmäinen hyökkäysyritys tehtiin jo 17. lokakuuta 2026, neljä päivää ennen päivityksiä. Ylläpitäjille ratkaisevaa ei siksi ole kysymys ”Kuinka paljon aikaa on?” vaan ”Kuinka kauan palvelimeni on auki?”. Tämä henkilökohtainen ikkuna päättyy vasta, kun päivitys on asennettu ja kaikki PHP-prosessit on käynnistetty uudelleen.
Lähtökohta: hyökkäykset ennen korjausta
Pitkään vallitsi mukava oletus: tietoturvapäivityksen ja ensimmäisten hyökkäysten välillä kuluu joitakin päiviä, riittävästi seuraavaan huoltoikkunaan. PHP2Shell kumosi tämän oletuksen. Amazoniin vedoten mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin jo 17. lokakuuta. Myös Cloudflare raportoi varhaisista hyökkäyksistä. Korjaukset tulivat 21. lokakuuta kello 14.00 UTC.
Tämä artikkeli selittää, miten tällaiset aikaikkunat syntyvät ja miten lyhennätte omaanne. Tarkan päivämäärien kulun löydätte PHP2Shellin aikajanalta.
Päivityksen ja hyökkäyksen välinen aikaikkuna vaiheittain
Tietoturva-aukon ympärillä voi erottaa useita vaiheita. PHP2Shellin kohdalla ne olivat tällaiset:
| Vaihe | Yleisesti | PHP2Shellin kohdalla |
|---|---|---|
| Ennen tietoon tuloa | aukko tiedossa vain löytäjillä ja valmistajalla | korjauksen kehitys embargon alaisena |
| Ensimmäiset hyökkäykset ilman päivitystä | hyökkääjät käyttävät aukkoa ennen kuin päivitystä on | mediaraporttien mukaan ensimmäinen yritys 17.10. |
| Ennakkoilmoitus | valmistaja ilmoittaa päivityksestä | 20.10., php.net ilmoittaa julkaisusta |
| Päivitys saatavilla | päivitys ja tietoturvailmoitus ilmestyvät | 21.10., 14.00 UTC |
| Päivityksen analysointi | tutkijat ja hyökkääjät analysoivat muutokset | watchTowr on omien tietojensa mukaan toistanut CVE-2026-109618:n |
| Laaja hyväksikäyttö | automaattiset kampanjat päivittämättömiä palvelimia vastaan | BSI:n odottama; vahvistettuja onnistuneita hyökkäyksiä laajasti ei aluksi tiedossa |
| Teidän päivityksenne | päivitys ja uudelleenkäynnistys palvelimillanne | yksilöllinen |
Viimeinen rivi on ainoa, johon voitte vaikuttaa. Kaiken sitä edeltävän määräävät muut.
Miksi päivitys itse lisää painetta
Tietoturvapäivitys sulkee aukon mutta tekee siitä samalla näkyvän. Avoimen lähdekoodin projektien, kuten PHP:n, lähdekoodimuutokset ovat julkisia. Joka vertaa vanhan ja uuden version eroja, saa selville, missä virhe oli. Se ei ole moite PHP-projektille vaan avoimen ohjelmiston normaalitila ja perusta sille, että jakelut voivat rakentaa backportteja.
Ylläpitäjille tästä seuraa: jokaisen päivityksen jälkeisen päivän myötä niiden määrä kasvaa, jotka tietävät, miten aukko toimii. Samalla päivittämättömien palvelimien määrä vähenee. Jäljelle jääneistä tulee ilmeisiä kohteita. Miten PHP toimittaa tietoturvapäivityksiä versionhuoltonsa puitteissa, selittää artikkeli PHP:n julkaisusyklistä.
Jos palvelimenne oli tavoitettavissa 17. lokakuuta ja päivityksenne välisenä aikana, jälkien tarkistus kuuluu asiaan. Tallentakaa lokit 20. lokakuuta alkaen, ennen kuin ne katoavat rotaation myötä.
Oman aikaikkunanne mittaaminen
Henkilökohtainen aikaikkunanne alkaa viimeistään päivitysten julkaisusta ja päättyy viimeisen PHP-prosessin uudelleenkäynnistykseen. Kirjatkaa jokaisesta palvelimesta:
- Tieto: Milloin joku yrityksessä sai tietää aukosta?
- Saatavuus: Milloin jakelunne tai hosting-yrityksenne paketti oli saatavilla?
- Asennus: Milloin se asennettiin?
- Uudelleenkäynnistys: Milloin vanhoja PHP-prosesseja ei enää ollut käynnissä?
Juuri uudelleenkäynnistys unohtuu usein. Asennettu päivitys vaikuttaa vasta, kun vanhat prosessit on lopetettu. Miten sen tarkistatte, kuvaa PHP-FPM:n ja kaikkien PHP-prosessien uudelleenkäynnistys. Se, toimiiko vielä prosesseja ajalta ennen päivitystä, näkyy käynnistysajoista:
# Näytä kaikkien PHP-prosessien käynnistysaika
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Jos käynnistysaika on ennen päivityksen asennusta, ikkuna on yhä auki.
Miksi ikkunanne riippuu hankintatiestä
Se, kuinka nopeasti voitte päivittää, ei riipu vain teistä vaan myös siitä, mistä PHP:nne tulee. Jakelut toimittivat raporttien mukaan backportteja osin jo 21. lokakuuta. Joka hankkii PHP:n kolmannen osapuolen repositoriosta, on sen tahdin varassa. Joka käyttää kontteja, joutuu rakentamaan ja ottamaan käyttöön kuvat uudelleen; pelkkä päivitys käynnissä olevassa kontissa ei riitä. Ja jaetussa verkkohotellissa hosting-yritys määrää ajankohdan.
Kun tunnette jokaisen palvelimen hankintatien, tiedätte myös, missä kohtaa ikkunanne pysyy pisimpään auki. Juuri siellä valmistautuminen kannattaa eniten, esimerkiksi sopimalla hosting-yrityksen kanssa tai testatulla kululla uusille konttikuville.
Näin lyhennätte aikaikkunaa ensi kerralla
- Tilatkaa ilmoitukset: Vastaanottakaa php.netin ja jakelunne tietoturvailmoitukset suoraan, älkää vasta lehdistön kautta.
- Määritelkää vastuu: Jokaiselle palvelimelle yksi vastuuhenkilö sijaisineen.
- Käyttäkää automatiikkaa, missä se sopii: Jakelun tietoturvapäivitykset voi asentaa automaattisesti. Mikä puhuu puolesta ja mikä vastaan, kuvaa Automaattiset tietoturvapäivitykset.
- Varatkaa uudelleenkäynnistys: PHP-palveluiden uudelleenkäynnistys kuuluu kiinteästi kulkuun, ei jälkitöihin.
- Valmistelkaa hätäreitti: hätäsivu ja päätös väliaikaisesta sulkemisesta, jos päivitys ei ole heti mahdollinen.
- Pitäkää todisteet: Dokumentoikaa asennuksen ja uudelleenkäynnistyksen ajankohdat, jotta voitte myöhemmin todistaa ikkunanne.
Näitä kohtia yhdistävä pysyvä prosessi on kuvattu artikkelissa päivityshallinnan prosessista.
Miten PHP SOS auttaa konkreettisesti?
- Päivitys ja uudelleenkäynnistys: Asennamme päivityksen ja varmistamme, ettei vanhoja PHP-prosesseja enää toimi.
- Aikaikkunan todistaminen: Dokumentoimme asennuksen ja uudelleenkäynnistyksen ajankohdan palvelin kerrallaan.
- Jälkien tarkistus: Ajalta, jolloin palvelimenne oli auki, tallennamme lokit ja tarkistamme poikkeamat.
- Prosessi tulevaisuutta varten: Määrittelemme kanssanne ilmoitusreitit, vastuut ja päivityskulut.
Lisää kohdassa PHP-päivityspalvelu.
Yhteenveto
PHP2Shellin kohdalla armonaikaa ei ollut. Päivityksen ja hyökkäyksen välinen aikaikkuna on kriittisissä aukoissa nykyään usein nolla tai jopa negatiivinen. Se, mitä voitte ohjata, on oma ikkunanne: se päättyy uudelleenkäynnistykseen, ja valmistautumalla sen voi lyhentää päivistä tunteihin.
Usein kysytyt kysymykset
Kuinka paljon aikaa tietoturvapäivityksen jälkeen on hyökkäyksiin?
Kiinteää määräaikaa ei ole. PHP2Shellin kohdalla havaittiin mediaraporttien mukaan ensimmäinen hyökkäysyritys jo 17. lokakuuta eli neljä päivää ennen korjauksia. Laajalle levinneen ohjelmiston kriittisissä aukoissa kannattaa lähteä siitä, ettei armonaikaa käytännössä ole.
Mikä on zero-day?
Aukko, jota hyökätään ennen kuin päivitys on saatavilla. Valmistajalla oli ikään kuin nolla päivää aikaa korjata se. Sen jälkeen puhutaan usein tunnetusta tai N-day-aukosta, jolle on jo päivitys.
Miksi hyökkäykset usein yleistyvät päivityksen jälkeen?
Päivityksen myötä tulee julkiseksi, missä kohtaa virhe oli. Tietoturvatutkijat ja hyökkääjät voivat analysoida muutokset. Samalla monet palvelimet pysyvät vielä päiviä tai viikkoja päivittämättöminä ja siten houkuttelevina kohteina.
Milloin palvelimeni on todella suojattu?
Kun päivitys on asennettu ja kaikki PHP-prosessit on käynnistetty uudelleen. Uudet tiedostot eivät yksin vaikuta, niin kauan kuin vanhat prosessit toimivat muistissa. Henkilökohtaisen aikaikkunanne päätepiste on siis uudelleenkäynnistys, ei lataus.