Lyhyesti: Joka haluaa PHP-päivityksen asennettuna, tarvitsee muutakin kuin uudet paketit: ratkaisevia ovat oikea paketin tila, kaikkien PHP-prosessien uudelleenkäynnistys ja todiste niistä. Juuri sen PHP-korjauspalvelumme toimittaa. Saatte kirjallisen todisteen jokaisesta palvelimesta, ja voitte esittää sen sisäisesti tai kolmansille osapuolille.
Miksi pelkkä PHP-päivitys ei usein riitä
Korjaukset PHP2Shell-haavoittuvuuksiin CVE-2026-109618 ja CVE-2026-109619 ovat olleet saatavilla 21.10.2026 alkaen. BSI (Saksan liittovaltion tietoturvavirasto) suosittelee päivittämään välittömästi. Käytännössä näemme kolme tyypillistä kompastuskiveä.
Ensinnäkin versionumero ei aina kerro todellista tilaa. Jakelut ja hosting-yritykset asentavat osin backporteja; silloin esimerkiksi Plesk näyttää yhä versiota 8.2.34, vaikka paketti on korjattu. Toiseksi asennuksen jälkeen vanhat PHP-prosessit jäävät usein käyntiin. Levylle tulleet uudet tiedostot eivät suojaa, kunhan vanhat workerit toimivat muistissa. Kolmanneksi samalla palvelimella toimii usein useita PHP-versioita rinnakkain, ja yksi niistä unohtuu.
PHP-päivitys asennettuna: korjatut versiot
| Haara | Korjattu alkaen | Edellinen tila | Huomautus |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | tarkista lisäksi fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | tuki päättyy 31.12.2026 |
| PHP 8.1 ja vanhemmat | ei virallisia päivityksiä | – | vain vähäisiä lähdekoodin backporteja versioille 7.4, 8.0, 8.1 |
Jakelujen tai hosting-yritysten paketeissa ratkaisevaa ei ole „PHP“-sanan perässä oleva luku vaan paketin tila, jonka toimittaja vahvistaa korjatuksi. Miten tarkistatte sen itse, kerrotaan sivulla PHP-version ja korjaustilan tarkistaminen oikein.
Miten PHP SOS auttaa konkreettisesti?
- Inventaario: Kokoamme kaikki palvelimen PHP-asennukset, ajotavan (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) ja sen, mikä verkkosivusto käyttää mitäkin versiota.
- Päivityksen asennus: Asennamme korjatut versiot jakelunne, paneelinne tai viralliseen projektin pakettilähteestä. Konteille rakennamme kanssanne uudet imaget.
- Kaikkien prosessien uudelleenkäynnistys: Käynnistämme PHP-FPM:n, Apachen, LiteSpeedin tai kyseiset workerit kokonaan uudelleen ja tarkistamme, ettei yksikään prosessi ole päivitystä vanhempi. Taustatiedot löytyvät sivulta PHP-FPM ja kaikkien workerien uudelleenkäynnistys.
- Toimintatarkistus: Avaamme tärkeimmät sivut ja toiminnot, kuten etusivun, kirjautumisen, lomakkeet ja kassan, ja tarkistamme virhelokit.
- Todiste: Saatte jokaisesta palvelimesta pöytäkirjan, jossa on versio, paketin tila, uudelleenkäynnistyksen ajankohta ja avoimet kohdat.
Tyypillinen tarkistusvaihe uudelleenkäynnistyksen jälkeen näyttää tältä:
# PHP CLI:n ja FPM-binäärin versio (polku riippuu järjestelmästä)
php -v
php-fpm8.3 -v
# FPM-prosessien käynnistysaika: sen on oltava päivityksen jälkeen
ps -o pid,lstart,cmd -C php-fpm8.3
Erikoistapaukset: paneelit, kontit ja useat PHP-versiot
Plesk- tai cPanel-palvelimilla PHP-versiot tulevat usein paneelin pakettilähteistä eivätkä jakelusta. Siellä tarkistamme jokaisen asennetun version erikseen, myös ne, jotka eivät kuulu mihinkään verkkosivustoon juuri nyt. Käyttämättömät, vanhentuneet versiot poistamme sovittuamme asiasta, jotta niitä ei oteta vahingossa uudelleen käyttöön.
Docker- ja Kubernetes-ympäristöissä isännän päivitys ei riitä. PHP on levykuvassa (image), ja vasta uudelleen rakennettu image, jonka pohja on korjattu ja joka on viety kaikkiin käynnissä oleviin kontteihin, sulkee haavoittuvuuden. Tarkistamme samalla, käytetäänkö vanhempia imageja yhä rekistereissä tai käyttöönotoissa. Yksityiskohdat löytyvät sivulta PHP:n korjaus Docker-konteissa.
mod_php:ssä PHP toimii suoraan Apache-prosessissa. PHP-tiimi arvioi riskin siellä suurimmaksi. Päivityksen jälkeen Apache on siksi käynnistettävä kokonaan uudelleen; pelkkä asetusten uudelleenlataus ei kaikissa tapauksissa riitä.
Mitä saatte meiltä
- korjauspöytäkirja jokaisesta palvelimesta: asennetut paketit, versiot, lähde, ajankohta
- todiste siitä, että kaikki PHP-prosessit on käynnistetty uudelleen
- luettelo tarkistetuista verkkosivustoista ja toiminnoista
- ilmoitus järjestelmistä, joita ei voitu korjata, perusteluineen
- suositus jatkosta, esimerkiksi PHP 8.2:n osalta tuen lähestyvän päättymisen vuoksi
Mitä tarvitsemme teiltä
- Pääsy: SSH ylläpitäjän oikeuksin tai paneelitunnukset (Plesk, cPanel tms.)
- Huoltoikkuna: milloin lyhyt uudelleenkäynnistys saa tapahtua
- Yhteyshenkilö: kysymyksiä varten ja toimintatarkistuksen jälkeistä hyväksyntää varten
- Varmuuskopiot: vahvistus siitä, että ajantasainen kopio on olemassa, tai toimeksianto luoda sellainen ensin
- Tiedot omista kehitystöistä: erityiset PHP-laajennukset tai asetukset, jotka on otettava huomioon
Jaetussa hostingissa ilman omaa palvelinpääsyä emme voi korjata itse. Autamme silloin esittämään hosting-yritykselle oikeat kysymykset ja arvioimaan vastauksen.
Mitä emme lupaa
Korjauspalvelu sulkee tunnetun haavoittuvuuden. Se ei vastaa siihen, oliko palvelin vaarantunut jo ennen päivitystä, eikä se poista asennettua haittaohjelmaa. Jos haluatte tietää sen, sopiva toimeksianto on PHP2Shell-pikaapu jälkien etsintöineen.
PHP 8.1:lle ja vanhemmille ei ole enää virallisia päivityksiä. Siihen otamme käyttöön väliaikaisia toimenpiteitä ja suosittelemme siirtymää tuettuun versioon. Yhteensopivuuslupausta CMS:llenne emme anna muistinvaraisesti, vaan tarkistamme sen valmistajan järjestelmävaatimuksista.
Usein kysytyt kysymykset
Miksi palvelimeni näyttää päivityksen jälkeen yhä vanhaa PHP-versiota?
Syitä voi olla kaksi. Joko jakelu on asentanut backportin, jolloin versionumero pysyy samana, vaikka paketti on korjattu. Tai vanhat PHP-prosessit ovat yhä muistissa ja ne on käynnistettävä uudelleen.
Mitkä PHP-versiot sulkevat PHP2Shellin?
Haavoittuvuus on korjattu versioissa PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35, jotka julkaistiin 21.10.2026. Jakelupaketeissa ratkaisee paketin tila, jonka toimittaja vahvistaa korjatuksi.
Voiko päivitys kaataa verkkosivustoni?
Saman pääversion sisäinen päivitys, esimerkiksi 8.3.35:stä 8.3.36:een, on yleensä vähäriskinen. PHP-prosessien lyhyt uudelleenkäynnistys on kuitenkin tarpeen. Sovimme ajankohdasta kanssanne ja tarkistamme sivut sen jälkeen.
Onko korjauksen jälkeen kaikki valmista?
Haavoittuvuuden osalta kyllä, kun kaikki prosessit on käynnistetty uudelleen. Korjaus ei kerro, oliko joku päässyt sisään jo ennen sitä. Siihen tarvitaan oma tarkistus.