Lyhyesti: PHP2Shellin jälkeen pelkkä näytetty PHP-versio todistaa vähän, koska hosting-yritykset tuovat korjaukset usein backporttina. Pyytäkää siksi kirjallinen vahvistus hostingin PHP-päivityksestä: paketin tila kutakin PHP-haaraa kohden sekä asennuksen ja kaikkien PHP-prosessien uudelleenkäynnistyksen ajankohta. Kopioitavan mallipohjan löydätte alta.
Miksi kirjallinen vahvistus on tärkeä juuri nyt
PHP-projekti julkaisi 21.10.2026 korjaukset kahteen kriittiseen haavoittuvuuteen, jotka tunnetaan nimellä PHP2Shell. Molemmat sallivat haittakoodin suorittamisen etänä ilman kirjautumista. BSI (Saksan liittovaltion tietoturvavirasto) on julistanut varoitustason 3 / oranssi ja suosittelee välitöntä päivitystä.
Jos verkkosivustonne toimii hosting-yrityksen palvelimella, ette useinkaan voi asentaa päivitystä itse. Samalla te ylläpitäjänä vastaatte asiakkaidenne tiedoista. Hosting-yrityksen kirjallinen, konkreettinen vahvistus on siksi enemmän kuin muodollisuus. Se on osa dokumentaatiotanne esimerkiksi tietosuojavastaaville, vakuutusyhtiöille tai johdolle.
Lisäksi: korjaus ei poista haittaohjelmaa, joka on ehditty lisätä aiemmin. Mediaraporttien mukaan ensimmäinen hyökkäysyritys havaittiin jo 17.10. Tarkka ajankohta, jolloin palvelimenne oli suojattu, on siksi tärkeä, kun ratkaistaan, onko tarkistusta jatkettava.
Miksi näytetty PHP-versio ei riitä
Korjattuja ovat PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Monet jakelut ja hosting-yritykset ottavat korjauksen kuitenkin omaan pakettiinsa backporttina. Silloin Plesk-tyyppinen hallintapaneeli näyttää yhä 8.2.34, vaikka palvelin on korjattu.
Toisaalta oikea versionumero voi myös johtaa harhaan. Pelkät uudet tiedostot eivät suojaa, niin kauan kuin vanhat PHP-prosessit pyörivät muistissa. Uusi tila on käytössä vasta kaikkien worker-prosessien uudelleenkäynnistyksen jälkeen. Lisää aiheesta artikkelissa PHP-version ja korjaustilan tarkistaminen oikein.
| Hosting-yrityksen ilmoitus | Mitä se todistaa | Mitä vielä puuttuu |
|---|---|---|
| ”Kaikki järjestelmät ovat ajan tasalla.” | vähän | Versio tai paketin tila, päivämäärä, uudelleenkäynnistys |
| ”PHP 8.3.36 on asennettu.” | Versio | Päivämäärä, uudelleenkäynnistys, koskettavat palvelimet |
| ”Backport paketissa xy, uudelleenkäynnistys …” | Korjaus ja käyttöönotto | tarvittaessa tiedot PHP 8.1:stä ja vanhemmista |
Mitä tietoja tarvitsette hosting-yritykseltä
Pyytäkää vastauksia näihin kohtiin, mahdollisuuksien mukaan sivustoa tai sopimusta kohden:
- Mitkä PHP-haarat ja versiot ovat käytössä sivustoillanne, myös vanhemmat, jotka toimivat vain yksittäisissä hakemistoissa?
- Sisältyvätkö korjaukset haavoittuvuuksiin CVE-2026-109618 ja CVE-2026-109619, virallisena versiona vai backporttina?
- Milloin päivitys asennettiin ja milloin kaikki PHP-prosessit (FPM-poolit, Apache, LiteSpeed) käynnistettiin uudelleen?
- Onko
session.upload_progress.enabledpoistettu käytöstä CVE-2026-115560:n vuoksi? - Mitä ajotapaa tilauksenne käyttää, esimerkiksi PHP-FPM vai Apache mod_php:n kanssa? PHP-tiimi näkee suurimman riskin mod_php:ssä.
- Mitä pääsy- ja virhelokeja säilytetään 20.10.2026 alkaen ja miten saatte ne?
Jos jokin sivusto toimii yhä PHP 8.1:llä tai vanhemmalla, kysykää asiasta erikseen. Näille haaroille ei ole enää virallisia päivityksiä, vain vähäisiä lähdekoodin backporteja versioille 7.4, 8.0 ja 8.1.
Mallipohja: hostingin PHP-päivityksen vahvistuksen pyytäminen
Kopioikaa teksti tukipyyntöön tai sähköpostiin hosting-yrityksellenne. Täydentäkää hakasulkeissa olevat tiedot.
Aihe: Pyyntö PHP-korjaustilan vahvistamisesta (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Hei,
ylläpidämme teillä seuraavia verkkosivustoja / sopimuksia:
[Asiakasnumero, sopimus, verkkotunnukset]
PHP-haavoittuvuuksiin CVE-2026-109618 ja CVE-2026-109619 (PHP2Shell,
korjaukset 21.10.2026) sekä CVE-2026-115560:tä koskevaan tiedotteeseen
23.10.2026 liittyen pyydämme kirjallista vahvistusta seuraaviin kohtiin:
1. Mitkä PHP-versiot tai paketin tilat ovat käytössä sivustoillamme?
2. Sisältävätkö ne korjaukset (virallinen versio tai backport)?
3. Asennuksen päivämäärä ja kellonaika.
4. Kaikkien PHP-prosessien (FPM, Apache, LiteSpeed tms.)
uudelleenkäynnistyksen päivämäärä ja kellonaika.
5. Onko session.upload_progress.enabled poistettu käytöstä palvelinpuolella?
6. Mitä PHP:n ajotapaa käytetään (esim. PHP-FPM, mod_php)?
7. Säilytetäänkö pääsy- ja virhelokit 20.10.2026 alkaen, ja miten
voimme saada ne?
8. Jos jokin sivusto käyttää yhä PHP 8.1:tä tai vanhempaa: mikä suojaus
siellä on, ja minkä siirtymän suosittelette?
Tarvitsemme tiedot sisäistä dokumentaatiotamme varten.
Kiitos ja ystävällisin terveisin
[Nimi, yritys, tehtävä]
Vastauksen arviointi ja oma vastatarkistus
Hyvä vastaus mainitsee konkreettiset tilat, päivämäärät ja kellonajat. Yleiset ilmaukset kuten ”olemme reagoineet” eivät riitä aineistoonne. Kysykää tällöin ystävällisesti puuttuvia kohtia.
Jos tilauksenne sallii, tarkistakaa lisäksi itse. SSH-yhteydellä riittävät yleensä nämä komennot:
# Komentorivin versio (voi poiketa verkkoversiosta)
php -v
# Paketin tila Debianissa/Ubuntussa
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Paketin tila RHEL-, Alma- ja Rocky-järjestelmissä
rpm -qa | grep -i php
# Milloin PHP-FPM-prosessit ovat käynnistyneet?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Jos PHP-prosessien käynnistysajankohta on ennen vahvistettua asennuspäivää, uudelleenkäynnistys ei ollut täydellinen.
Jos hosting-yritys ei vastaa tai vastaa kiertelevästi
Jos vastausta ei tule tai ratkaisevat tiedot puuttuvat, tilannetta ei pidä katsoa selvitetyksi. BSI suosittelee irrottamaan verkkopalvelimet väliaikaisesti verkosta, jos päivitys ei onnistu heti. Johto päättää, onko se sivustonne kannalta oikeasuhtaista, mieluiten kirjallisesti ja päivämäärän kera.
Kannattaa samalla katsoa mahdollisia hyökkäyksen jälkiä, sillä korjauksen ajankohta on yhä avoin. Viitteitä antaa artikkeli Onko järjestelmäni jo vaarannettu?. Ilman SSH-yhteyttä kirjallinen vahvistus on tärkein todisteenne. Mitä velvoitteita hosting-yrityksellä on ja mitä teillä, selittää sivu Jaettu hosting: mitä hosting-yritys tekee; hallinnoiduille palvelimille apua tarjoaa Hallinnoitu palvelin: vastuun selvittäminen.
Tallentakaa pyyntö, vastaus ja omat tarkistustulokset päivämäärineen yhteen kansioon. Tämä aineisto auttaa myöhemmin vakuutusyhtiöiden tai tietosuojavastaavien kysymyksissä.
Miten PHP SOS auttaa konkreettisesti?
- Muotoilemme kanssanne pyynnön hosting-yritykselle ja arvioimme vastauksen asiantuntijana.
- Siellä, missä meillä on pääsy, tarkistamme itse paketin tilan, käytössä olevan ajotavan ja PHP-prosessien uudelleenkäynnistyksen.
- Jos aukkoja jää, otamme käyttöön väliaikaisia toimia tai suunnittelemme siirtymän tuettuun versioon.
- Kirjaamme tuloksen ja ajankohdat todisteeksi, jonka voitte antaa sisäisesti eteenpäin.
Päivityksen, uudelleenkäynnistyksen ja todisteen kulun kuvaa PHP-korjauspalvelumme.
Usein kysytyt kysymykset
Riittääkö, että hosting-yritys kirjoittaa kaiken olevan ajan tasalla?
Dokumentaatiotanne varten ei yleensä. Pyytäkää konkreettisia tietoja: paketin tila tai versio kutakin PHP-haaraa kohden, asennuspäivä ja kaikkien PHP-prosessien uudelleenkäynnistyksen päivä. Vasta niillä voitte rajata haavoittuvuusikkunan.
Miksi hosting-hallintapaneelini näyttää yhä PHP 8.2.34?
Jakelut ja hosting-yritykset tuovat tietoturvakorjaukset joskus backporttina muuttamatta versionumeroa. Plesk voi silloin näyttää yhä 8.2.34, vaikka palvelin on korjattu. Selvyyden tuo vain palveluntarjoajan vahvistus paketin tilasta.
Mitä teen, jos hosting-yritys ei vastaa?
Dokumentoikaa pyyntönne päivämäärineen ja kysykää uudelleen kohtuullisen ajan kuluttua. Selvittäkää samalla, voitteko ottaa väliaikaiset toimet itse käyttöön, ja sopikaa johdon kanssa, otetaanko verkkosivusto pois verkosta selvityksen ajaksi, kuten BSI suosittelee korjaamattomille palvelimille.
Sulkeeko WordPress- tai verkkokauppapäivitys haavoittuvuuden myös?
Ei. PHP2Shell on PHP:ssä itsessään. CMS:n tai verkkokauppaohjelmiston päivitys ei muuta palvelimella toimivaa PHP-tulkkia.