Lyhyesti: Se, pitäisikö verkkosivusto ottaa pois käytöstä PHP-aukon vuoksi, riippuu yhdestä kysymyksestä: toimiiko PHP kyseisellä palvelimella todistettavasti korjatussa tilassa, ja onko kaikki prosessit käynnistetty uudelleen? Jos kyllä, sulkeminen ei ole tarpeen. Jos päivitystä ei voi tehdä heti, BSI (Saksan liittovaltion tietoturvavirasto) suosittelee ottamaan verkkopalvelimen tilapäisesti pois verkosta. Odottaminen on perusteltua vain, jos järjestelmä ei käytä PHP:tä, sitä ei voi tavoittaa julkisesti tai palveluntarjoaja on vahvistanut korjauksen kirjallisesti.
Tilanne, jossa teidän on päätettävä
PHP2Shell käsittää kaksi aukkoa itse PHP:ssä, CVE-2026-109618 ja CVE-2026-109619, kumpikin arvosanalla CVSS v4.0 9,2. Ne sallivat haittakoodin suorittamisen etänä ilman kirjautumista. Korjatut versiot ovat saatavilla 21.10.2026 alkaen: 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.1:lle ja vanhemmille ei enää ole virallisia päivityksiä.
BSI on antanut oranssin varoitustason ja neuvoo päivittämään heti, sen sijaan tilapäisesti sulkemaan. Mediaraporttien mukaan Mainzin kaupunki, Hessenin osavaltionhallituksen toimijat ja muut julkiset laitokset ovat ottaneet verkkosivustoja varotoimena pois verkosta; Hessenin osavaltion kanslia ei ilmoittanut hyökkäyksestä. Mitä yritykset voivat tästä päätellä, kerrotaan sivulla Viranomaiset ottavat verkkosivustoja pois verkosta.
Yritysten vastuuhenkilöille kysymys on käytännöllisempi: mitä teemme verkkokaupallemme, portaalillemme, yrityksen verkkosivustolle, tänään?
Sivusto pois käytöstä, päivitys vai odottaminen: kolme vaihtoehtoa vertailussa
Seuraava taulukko asettaa vaihtoehdot rinnakkain. Se ei korvaa yksittäistapauksenne arviointia, mutta tekee punninnan näkyväksi.
| Kriteeri | Päivitä heti | Sulje tilapäisesti | Odota |
|---|---|---|---|
| Suoja PHP2Shelliltä | Korkea, jos korjaus ja uudelleenkäynnistys on todistettu | Korkea sulkemisen ajan | Ei lainkaan niin kauan kuin ei päivitetty |
| Toiminnan keskeytys | Lyhyt, päivitystä ja uudelleenkäynnistystä varten | Tunneista päiviin | Ei lainkaan |
| Edellytys | Tuettu PHP-versio, pääsy, huoltoikkuna | Johdon päätös, staattinen korvaava sivu | Todistettu syy, miksi riskiä ei ole |
| Vaiva | Pieni tai keskisuuri | Teknisesti pieni, organisatorisesti suuri | Pieni, mutta todisteen tarkistustyö |
| Tyypillinen tapaus | Palvelin, jolla PHP 8.2–8.5 | Vanha järjestelmä PHP 8.1:llä tai vanhemmalla, epäselvä tila | Järjestelmä ilman PHP:tä tai vain sisäisesti tavoitettava |
| Jäännösriski | Aiempi tunkeutuminen mahdollinen | Aiempi tunkeutuminen mahdollinen | Täysi |
Yksi rivi ansaitsee huomion: Ei päivitys eikä sulkeminen selvitä, onko jotain jo tapahtunut aiemmin. Mediaraporttien mukaan ensimmäinen havaittu hyökkäysyritys tapahtui 17.10.2026, siis ennen korjausta. Mahdollisten jälkien tarkastus kuuluu siksi jokaiseen vaihtoehtoon.
Päätökseen viidellä kysymyksellä
Käykää kysymykset läpi järjestyksessä. Ensimmäinen selvä vastaus johtaa yleensä päätökseen.
- Toimiiko järjestelmässä ylipäätään PHP, ja onko se tavoitettavissa internetistä? Jos ei, PHP2Shell ei koske järjestelmää suoraan. Dokumentoikaa, miten sen totesitte.
- Onko korjaustila todistettu? Todistettu tarkoittaa: korjattu versio tai backport CVE-numeroineen paketin muutoslokissa ja kaikkien PHP-prosessien uudelleenkäynnistys. Paneelin versionäyttö ei riitä. Miten sen tarkistatte, selviää sivulta PHP-version ja korjaustilan tarkistaminen oikein.
- Voiko päivityksen tehdä lähitunteina? Jos voi: päivittäkää, käynnistäkää uudelleen, tarkistakaa. Siihen asti väliaikaiset toimenpiteet voivat auttaa.
- Ellei se ole mahdollista, esimerkiksi PHP 8.1:n tai puuttuvan pääsyn vuoksi? Silloin tilapäinen sulkeminen on BSI:n mukaan tie. php.netin mukaiset väliaikaiset toimenpiteet pienentävät riskiä mutta eivät suojaa täysin; yksityiskohdat löytyvät sivulta Pikatoimenpiteet, kun ette voi vielä päivittää.
- Onko merkkejä vaarantumisesta? Silloin kysymys ei enää ole ”päivitys vai sulkeminen” vaan ”häiriön käsittely”. Sulkekaa, turvatkaa todisteet, älkää poistako ennenaikaisesti.
Jos suljette: sulkekaa oikein
Sulkemisen on poistettava hyökkäyspinta-ala, ei vain piilotettava etusivua. Huoltosivu, jota tuotetaan yhä PHP:llä, ei täytä tarkoitusta. Parempi on staattinen HTML-sivu, jonka verkkopalvelin toimittaa ilman PHP:tä, tai uudelleenohjaus toiselle palvelimelle.
Ajatelkaa kaikkea, mikä riippuu samasta PHP:stä: alasivut, rajapinnat sovelluksille tai tavarahallintaan, ylläpitoalueet, maksujen paluukutsut. Puhukaa etukäteen maksupalveluntarjoajan ja logistiikan kanssa, jos verkkokauppa on kohteena. Ja tiedottakaa työntekijöille ja asiakkaille selkein sanoin: sivusto on varotoimena pois käytöstä, yhteydenotto onnistuu puhelimitse ja sähköpostilla. Se on parempi kuin vaikeneminen, joka ruokkii spekulaatioita.
Tärkeää on myös sulkemisen päättyminen. Määrittäkää, millä ehdolla sivusto palaa verkkoon, esimerkiksi ”PHP korjatussa tilassa, uudelleenkäynnistys tarkistettu, ensimmäinen jälkitarkastus ilman löydöksiä”. Näin hätäjarrusta tulee järjestetty kulku.
Sulkeminen ei ole tappio. Useat julkiset tahot ovat mediaraporttien mukaan tehneet juuri niin ilman, että hyökkäystä oli tapahtunut. Varotoimena tehty sulkeminen ei automaattisesti tarkoita, että verkkosivusto olisi murrettu.
Milloin ette tarvitse palveluntarjoajaa
Kaikki päätökset eivät vaadi ulkopuolista apua. Jos verkkosivustonne on hosting-yrityksellä, joka vahvistaa korjaustilan ja uudelleenkäynnistyksen kirjallisesti, eikä poikkeamia ole, olette hyvässä asemassa lyhyen dokumentaation kanssa. Sama pätee, jos oma IT:nne pystyy itse päivittämään palvelimen tuetulla PHP-versiolla ja hallitsee tarkastuksen.
Apu kannattaa, jos käytössä on järjestelmiä vanhalla PHP-versiolla, tila on epäselvä, kohteena on useita palvelimia tai on merkkejä tunkeutumisesta.
Miten PHP SOS auttaa konkreettisesti?
- Selvitämme kanssanne lyhyessä ajassa, mitkä järjestelmät ovat kohteena ja mikä korjaustila on todistettu.
- Toimitamme johdolle yhden sivun päätösperustan: vaihtoehdot, riskit, suositeltu tie.
- Toteutamme valitun tien, siis päivityksen uudelleenkäynnistyksineen, väliaikaiset toimenpiteet tai siistin sulkemisen staattisella korvaavalla sivulla, osana PHP2Shell-pikaapuamme.
- Tarkistamme jäljet 17.10.2026 alkaen ja dokumentoimme tuloksen.
Yhteenveto
Päivitys on normaalitapaus, sulkeminen oikea hätäjarru, odottaminen perusteltua vain todisteella. Joka vastaa viiteen kysymykseen rehellisesti ja kirjaa päätöksen kirjallisesti, toimii BSI:n suosituksen hengessä ja voi myöhemmin osoittaa, miksi.
Usein kysytyt kysymykset
Onko minun otettava verkkosivustoni pois käytöstä PHP2Shellin vuoksi?
Ei, jos PHP toimii jo korjatussa tilassa ja kaikki prosessit on käynnistetty uudelleen. BSI suosittelee tilapäistä sulkemista siltä varalta, ettei välitön päivitys ole mahdollinen.
Kumpi maksaa sulkemisessa enemmän: liikevaihto vai riski?
Siihen voi vastata vain yksittäistapauksessa. Tuntien katko on yleensä paremmin suunniteltavissa kuin murto, jonka seurauksia ja kestoa kukaan ei tiedä. Kirjatkaa punninta kirjallisesti riippumatta siitä, mihin se johtaa.
Saako huoltosivu toimia samalla palvelimella?
Kyllä, jos se toimitetaan staattisena tiedostona ilman PHP:tä. Jos huoltosivu tuotetaan yhä PHP:llä, hyökkäyspinta-ala säilyy.
Onko odottaminen koskaan oikea valinta?
Kyllä, selkeästi rajatuissa tapauksissa: jos järjestelmässä ei toimi PHP:tä, jos sitä ei voi tavoittaa internetistä tai jos palveluntarjoaja on vahvistanut korjauksen ja uudelleenkäynnistyksen kirjallisesti. Odottaminen ilman tällaisia todisteita ei ole vaihtoehto vaan riski.
Kenen pitäisi tehdä päätös?
Henkilön, joka vastaa liiketoimintariskistä, yleensä johdon tai omistajan. IT toimittaa tosiasiat. Se, kuka päättää, pitäisi olla kirjattuna etukäteen hätäsuunnitelmaan.