Lyhyesti: Jos haluatte PHP2Shell-haavoittuvuuden suljettua vielä tänään, tarvitsette neljä asiaa: oikean päivityksen, kaikkien PHP-prosessien uudelleenkäynnistyksen, jo lisätyn haittakoodin tarkistuksen ja todisteen. Koskeeko tämä teitä? Soittakaa. Autamme. Hoidamme tämän etänä ensimmäisestä viestistä alkaen.
Älkää nyt poistako mitään äläkä asentako palvelinta uudelleen. Korjattaessakin pätee: ensin varmistus, sitten muutokset. Jos jotain on jo päässyt sisään, tarvitsemme tiedostojen ja lokien tilan. Ilmoittakaa hätätilanne, niin sovimme kanssanne järjestyksestä.
Miksi haavoittuvuus ei voi odottaa
Molemmat haavoittuvuudet, CVE-2026-109618 ja CVE-2026-109619, ovat itse PHP:ssä ja sallivat haittakoodin suorittamisen etänä ilman kirjautumista. BSI (Saksan liittovaltion tietoturvavirasto) on julistanut varoitustason 3 (oranssi) ja suosittelee päivitystä heti. Jos se ei onnistu heti, verkkopalvelimet on otettava tilapäisesti pois verkosta. Mediatietojen mukaan ensimmäisiä hyökkäysyrityksiä havaittiin jo ennen korjausten julkaisua 21.10.2026. Cloudflare on havainnut yrityksiä ja ottanut käyttöön suojasääntöjä, mutta varoittaa, etteivät pelkkiin pyyntötietoihin perustuvat säännöt riitä.
Tärkeää ylläpitäjille: CMS-päivitys ei sulje PHP-haavoittuvuutta. Myöskään WordPress.org ei raporttien mukaan suunnittele päivitystä sitä vastaan, koska haavoittuvuus on tulkissa. Se suljetaan vain PHP-tasolla, eli siinä, mitä palvelimenne todella suorittaa.
Mitä teette heti
- Tuntekaa kohdeversio. Korjattu on PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.2:n tuki päättyy 31.12.2026, huomioikaa se suunnittelussa.
- Kootkaa kaikki järjestelmät. Myös testipalvelimet, konttien imaget ja vanhat järjestelmät, jotka ovat tavoitettavissa internetistä.
- Selvittäkää vastuu. Hosting-paketeissa ja hallinnoiduissa palvelimissa päivityksen tekee palveluntarjoaja. Kysykää kirjallisesti versiota ja uudelleenkäynnistystä.
- Säilyttäkää lokit. Alan lehdistön mukaan 20.10.2026 alkaen.
- Sopikaa ikkuna. Uudelleenkäynnistys keskeyttää käynnissä olevat pyynnöt hetkeksi. Päättäkää ajankohta, jolloin joku voi tehdä päätöksiä.
- Älkää odottako, jos haavoittuvuus on auki. Jos korjausta ei voi asentaa heti, tarkistakaa kanssamme eristäminen tai väliaikaiset toimet.
Miten PHP SOS auttaa konkreettisesti?
- Tilanteen kartoitus: Kartoitamme järjestelmät, PHP-versiot, ajotavat, hosting-yritykset ja tavoitettavuuden sekä päätämme järjestyksen: ensin ne järjestelmät, jotka ovat eniten esillä.
- Varmistus ja sulkeminen: Varmistamme nykytilan, asennamme päivityksen tai saamme hostingin todennetusti korjattuun tilaan ja käynnistämme kaikki prosessit uudelleen. Konteissa rakennamme imagen uudelleen ja otamme sen käyttöön.
- Tarkistus ja puhdistus: Koska korjaus ei poista haittakoodia, tarkistamme aiemman murron merkit ja puhdistamme tarvittaessa.
- Koventaminen ja raportointi: Saatte kirjallisen todisteen järjestelmittäin sekä suosituksia, jotta seuraava päivitys sujuu nopeammin. Palvelun sisällön kuvaa PHP-korjauspalvelu.
Päivitys, uudelleenkäynnistys, todiste: mikä on olennaista
Yleisin virhe on päivitys ilman uudelleenkäynnistystä. Niin kauan kuin vanhat prosessit pyörivät muistissa, haavoittuva koodi pysyy aktiivisena, vaikka tiedostot olisivat uusia. Ohjeen löydätte sivulta PHP-FPM ja kaikkien worker-prosessien uudelleenkäynnistys. Toinen virhe on uskoa näyttöä: jakelut ja hosting-yritykset toimittavat usein backporteja, jolloin versionumero pysyy samana. Luotettava on pakettien muutosloki CVE-numeroineen, Debian-perheessä komennolla apt-get changelog <paketti>.
Lisäksi PHP-käsikirjan mukaan tietoturvapäivitysten myötä on voimassa uusi direktiivi memory_hard_limit_percent. Jos PHP-versio ei tunne sitä, se on haavoittuva. Testi on lyhyt:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Se on ajettava versio- ja ajotapakohtaisesti, koska komentorivi voi käyttää eri PHP-versiota kuin verkkopalvelin. Lopuksi kirjaamme tuloksen, jotta voitte näyttää sen hosting-yritykselle, vakuutusyhtiölle tai tilaajalle.
Kun päivitystä ei voi tehdä heti
On syitä, joiden vuoksi päivitys ei ole mahdollinen tänään: vanha sovellus, joka ei toimi uudemmilla PHP-versioilla, hosting-yritys ilman vapautusta tai konttiimage kiinteässä putkessa. Näitä tapauksia varten php.net mainitsee väliaikaisia toimia, jotka eivät nimenomaisesti ole täydellinen suoja: memory_limit=-1 asetettuna niin, etteivät sovellukset voi ylikirjoittaa sitä, post_max_size rajattuna, session.upload_progress.enabled=0 ja PHP 8.5:ssä fatal_error_backtraces=0, kukin uudelleenkäynnistyksen kanssa. Lisäksi tulevat reunalla toimivat suojasäännöt, jotka eivät korvaa päivitystä. Kiertävän neuvon estää kaikki PHPSESSID-pyynnöt asiantuntijakirjoittajat torjuvat nimenomaisesti.
Mitkä toimet sopivat järjestelmäänne ja mitä ne voivat rikkoa, käymme läpi etukäteen. Lisää sivulla Pikatoimet, kun ette voi vielä korjata ja aiheessa WAF ja virtuaalinen korjaus. PHP 8.1:lle ja vanhemmille pätee oma tilanteensa, joka on kuvattu sivulla PHP 8.1 ja vanhemmat: mikä nyt pätee.
Mitä teidän kannattaa lähettää meille
- Luettelo palvelimista ja hosting-yrityksistä, jos sellainen on
php -v-komennon tuloste järjestelmittäin ja maininta ajotavasta- Tieto siitä, onko käytössä kontteja, Plesk, cPanel tai hallinnoitu palvelu
- Toivottu aikaikkuna ja yhteyshenkilö uudelleenkäynnistyksiä varten
- Huomiot poikkeavasta 17.10.2026 alkaen
Miksi PHP SOS
Työmme on Saksassa tehtyä (Made in Germany), ja olemme yli 25 vuoden ajan erikoistuneet tietoturvaan kumppaniverkostomme kyberammattilaisten kanssa. Teillä on yksi yhteyshenkilö, joka saattaa päivityksen läpi, tarkistaa uudelleenkäynnistyksen ja toimittaa todisteen. Työskentelemme etänä, ilman matkustamista, ja dokumentoimme jokaisen vaiheen. Emme lupaa ihmeitä: korjaus sulkee haavoittuvuuden, mutta se ei todista, ettei aiemmin ole tapahtunut mitään, ja kerromme sen teille juuri niin.
Koskeeko tämä teitä? Soittakaa. Autamme.
Älkää antako haavoittuvuuden olla auki enää hetkeäkään. Soittakaa tai kirjoittakaa WhatsAppilla. Otamme tilanteen hoitoon ensimmäisestä viestistä alkaen ja pysymme mukana, kunnes tapaus on käsitelty loppuun ja dokumentoitu. Ilmoittakaa hätätilanne nyt.
Usein kysytyt kysymykset
Voinko sulkea PHP-haavoittuvuuden itse vai tarvitsenko apua?
Päivitys on ylläpitäjälle tehtävissä, mutta virheherkkä: päivityksen on koskettava sitä versiota, joka todella palvelee sivuja, ja kaikkien prosessien on käynnistyttävä uudelleen. Jos teillä on useita palvelimia, konttien imageja tai erityispiirteinen hosting-yritys, tuki säästää aikaa ja virheitä.
Pitääkö PHP käynnistää uudelleen päivityksen jälkeen?
Kyllä. Uudet tiedostot eivät yksin riitä, jos vanhat PHP-prosessit pyörivät yhä muistissa. Kaikki worker-prosessit tai prosessit on käynnistettävä uudelleen, mod_php:n tapauksessa verkkopalvelin.
Mitä tehdä, jos PHP-versiolleni ei vielä ole päivitystä?
Versioille 8.1 ja vanhemmat PHP-projekti ei enää julkaise virallisia päivityksiä. Silloin tarvitaan palveluntarjoajan todennetusti korjattu backport, siirtyminen ylläpidettyyn versioon tai väliaikaisia toimia, jotka eivät kuitenkaan tarjoa täydellistä suojaa.
Riittääkö, että asetan session.upload_progress.enabled-arvoksi 0?
Ei. Asiantuntijaraporttien mukaan asetus yksin ei sulje kumpaakaan haavoittuvuutta, ja PHP-päivitys on pakollinen. Asettakaa se vain php.ini:ssä, FPM-poolissa tai palvelimen asetuksissa, älkää ini_set()-funktiolla tai .user.ini-tiedostossa.
Mistä tiedän, että haavoittuvuus on sen jälkeen todella suljettu?
Todisteesta käynnissä olevalla järjestelmällä: versio tai paketin muutosloki, uuden direktiivin memory_hard_limit_percent testi sekä vahvistus siitä, että kaikki prosessit on käynnistetty päivityksen jälkeen uudelleen.