Lyhyesti: Plesk PHP -päivitys on valmis vasta, kun jokainen asennettu PHP-versio on korjatussa tilassa, kaikki PHP-FPM-palvelut on käynnistetty uudelleen ja voit todistaa sen pakettitilalla ja prosessien käynnistysajalla. Paneelissa näkyvä versionumero ei yksin riitä, koska backport-korjaukset jättävät sen usein ennalleen.
Mistä PHP2Shellissä on kyse Plesk-palvelimilla
PHP2Shell tarkoittaa kahta kriittistä haavoittuvuutta itse PHP:ssä (CVE-2026-109618 ja CVE-2026-109619, kumpikin CVSS v4.0 9.2). Niiden avulla hyökkääjät voivat suorittaa koodia palvelimella ilman kirjautumista. Haavoittuvuudet koskevat muun muassa PHP-FPM:ää ja Apachea mod_php:n kanssa, eli juuri niitä toimintatapoja, jotka Plesk ottaa verkkosivustoille käyttöön.
PHP-projekti julkaisi 21.10.2026 korjatut versiot 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. PHP 8.1:lle ja sitä vanhemmille ei ole enää virallisia päivityksiä. Plesk-palvelimilla on yksi erityispiirre: täällä toimii usein useita PHP-versioita rinnakkain, osa Pleskin omina ja osa käyttöjärjestelmän. Jokainen niistä on tarkistettava erikseen.
Paneelissa tehty päivitys korvaa tiedostoja levyllä. Niin kauan kuin vanhat PHP-prosessit pyörivät muistissa, haavoittuvuus on auki. Ilman kaikkien worker-prosessien uudelleenkäynnistystä korjaus ei ole voimassa.
Plesk PHP -päivitys: kartoita ensin kanta
Ennen päivittämistä kokoa luettelo kaikista PHP-käsittelijöistä ja niitä käyttävistä verkkotunnuksista. Se onnistuu paneelin kautta (Työkalut ja asetukset, PHP-asetukset) tai komentoriviltä. Seuraavat komennot eivät muuta mitään, ne vain lukevat.
# Kaikki rekisteröidyt PHP-käsittelijät versioineen ja polkuineen
plesk bin php_handler --list
# Jokaisen Pleskin asentaman PHP-version versio (polku esimerkkinä)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done
Kirjaa jokaisesta käsittelijästä versio, toimintatapa (FPM, FastCGI, Apache-moduuli) ja verkkotunnusten määrä. Käsittelijä ilman verkkotunnusta ei ole merkki turvallisuudesta. Se voidaan määrittää myöhemmin tai se voi pyöriä testialiverkkotunnuksilla.
Tarkista pakettitila, ei näyttöä
Plesk näyttää sen versionumeron, jonka PHP itse ilmoittaa. Jos Plesk tai jakelu toimittaa korjauksen backport-korjauksena, kohdassa voi yhä lukea esimerkiksi 8.2.34, vaikka korjaus on mukana. Toisin päin viimeisimmältä näyttävä numero voi johtaa harhaan, jos pakettia ei ole vielä päivitetty. Ratkaisevia ovat asennettu pakettitila ja palveluntarjoajan kirjallinen vahvistus.
# Debian/Ubuntu (pakettien nimet esimerkkinä)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'
# AlmaLinux/Rocky/RHEL (pakettien nimet esimerkkinä)
rpm -qa | grep -E 'plesk-php|^php' | sort
Vertaa pakettiversioita Pleskin muutoslokien ja jakelunne ohjeiden tietoihin. Jos niissä ei ole yksiselitteisesti kirjattu, että CVE-2026-109618 ja CVE-2026-109619 on korjattu, kysy palveluntarjoajalta. Pohjan siihen löydät sivulta Kysy hosting-yritykseltä korjauksen tila.
Asenna päivitys ja käynnistä kaikki worker-prosessit uudelleen
Varsinainen päivitys tehdään Plesk-asennusohjelmalla tai järjestelmän paketinhallinnalla. Sen jälkeen tulee vaihe, joka useimmin jää väliin: uudelleenkäynnistys. Jokaisella PHP-versiolla on Pleskissä oma FPM-palvelunsa. Käynnistä kaikki uudelleen, älä vain pääverkkotunnuksen palvelua.
# Luettele kaikki PHP-FPM-palvelut (palvelujen nimet esimerkkinä)
systemctl list-units --type=service | grep -i 'php.*fpm'
# Käynnistä jokainen palvelu uudelleen, esim.:
systemctl restart plesk-php84-fpm
# Tarkista käynnissä olevien PHP-prosessien käynnistysaika
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep
Jos verkkotunnus toimii Apachella ja mod_php:llä, käynnistä Apache kokonaan uudelleen. Jos PHP-prosessin käynnistysaika on ennen päivitystä, sitä ei ole vielä uusittu. Lisää tästä vaiheesta sivulla PHP-FPM ja kaikki worker-prosessit uudelleen.
Väliaikainen suoja, jos päivitys vielä puuttuu
Jos jollekin versiolle ei ole vielä korjausta, php.net suosittelee väliaikaisia toimenpiteitä. Ne eivät ole täydellinen suoja. Pleskissä arvot, joita sovellusten ei pidä voida ylikirjoittaa, asetetaan php_admin_value-arvoina verkkotunnuksen lisä-FPM-direktiiveissä tai palvelinlaajuisesti kyseisen version php.ini-tiedostossa.
; Esimerkki Pleskin lisä-PHP-FPM-direktiiveistä
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
Latausten kanssa php.net:n mukaan tarkoitettu arvo on post_max_size = 32M, ja upload_max_filesize sen alapuolella. PHP 8.5:ssä lisätään fatal_error_backtraces=0. Muistin rajoitus asetuksella memory_limit=-1 kuuluu käyttää vain yhdessä kontti- tai cgroup-tason rajan kanssa. Sen jälkeen kaikki worker-prosessit käynnistetään taas uudelleen. Yksityiskohdat ovat sivulla Pikatoimet ilman korjausta. BSI (Saksan liittovaltion tietoturvavirasto) suosittelee, että verkkopalvelimet otetaan tilapäisesti pois verkosta, jos päivitystä ei voi tehdä heti.
Korjauksen jälkeen: turvaa lokit ja tarkista jäljet
Korjaus sulkee haavoittuvuuden tulevaisuudessa. Se ei poista haittaohjelmaa, joka on ehditty asentaa aiemmin, eikä todista, ettei mitään ole tapahtunut. Säilytä siksi verkkopalvelimen lokit 20.10.2026 alkaen. Plesk tallentaa ne verkkotunnuskohtaisesti logs-hakemistoon; älä lyhennä säilytysaikaa tässä tilanteessa.
Kiinnitä huomiota uusiin tai muuttuneisiin PHP-tiedostoihin latauskansioissa, tuntemattomiin ajastettuihin tehtäviin ja uusiin ylläpitäjätileihin. Julkaistuja, vahvistettuja Indicators of Compromise -tunnisteita ei toistaiseksi ole; havaitseminen perustuu käyttäytymisanalyysiin. Jos löydät poikkeavaa, älä jatka omin päin vaan tallenna ensin tila.
Miten PHP SOS auttaa konkreettisesti?
- Kartoitamme Plesk-palvelimenne kaikki PHP-käsittelijät, yhdistämme verkkotunnukset niihin ja tarkistamme todellisen pakettitilan versiokohtaisesti.
- Osana PHP-korjauspalveluamme asennamme päivitykset, käynnistämme kaikki palvelut uudelleen ja dokumentoimme prosessien käynnistysajat todisteeksi.
- Missä korjaus puuttuu, asetamme php.net:n mukaiset väliaikaiset toimenpiteet palvelinlaajuisesti ja ylikirjoittamattomina.
- Turvaamme lokit ja etsimme jälkiä murrosta, ja löydön tapauksessa toimimme poikkeamien hallinnan kanssa.
- Sen jälkeen koventamme palvelimen pysyvästi ja poistamme tarpeettomat PHP-versiot.
Usein kysytyt kysymykset
Miksi Plesk näyttää päivityksen jälkeen yhä PHP 8.2.34:ää?
Jakelut ja palveluntarjoajat asentavat tietoturvakorjauksia osittain backport-korjauksina muuttamatta versionumeroa. Ratkaisevia ovat silloin pakettitila ja palveluntarjoajan vahvistus. Pelkkä näyttö ei todista korjausta eikä sen puuttumista.
Riittääkö, että napsautan Plesk-paneelissa Päivitä?
Päivitys tallentaa uudet tiedostot, mutta käynnissä olevat PHP-prosessit käyttävät muistissa yhä vanhaa koodia. Uusi tila on käytössä vasta, kun kaikki PHP-FPM-palvelut ja verkkopalvelin on käynnistetty uudelleen. Tarkista sen jälkeen prosessien käynnistysaika.
Pitääkö myös sellaiset PHP-versiot korjata, joita mikään verkkotunnus ei käytä?
Kyllä, jos ne pysyvät asennettuina. Käyttämätön käsittelijä voidaan myöhemmin määrittää vahingossa jollekin verkkotunnukselle, tai se voi olla tavoitettavissa testiympäristöjen kautta. Tarpeettomat versiot kannattaa poistaa kokonaan.
Auttaako WordPress-päivitys Pleskin Toolkitissa PHP2Shelliä vastaan?
Ei. PHP2Shell koskee itse PHP:tä, ei sisällönhallintajärjestelmää. CMS-päivitys on silti järkevä, mutta se ei sulje tätä haavoittuvuutta.