Lühidalt: Pärast PHP2Shelli ei tõesta kuvatud PHP versioon üksi eriti midagi, sest veebimajutajad portivad parandusi sageli tagasi. Nõudke seetõttu veebimajutajalt kirjalikku PHP uuenduse kinnitust: paketi seis iga PHP haru kohta, paigaldamise ajahetk ja kõigi PHP protsesside taaskäivitamine. Kopeeritava malli leiate allpool.
Miks on kirjalik kinnitus just praegu oluline
21.10.2026 avaldas PHP projekt paigad kahele kriitilisele turvaaugule, mis on tuntud nime all PHP2Shell. Mõlemad võimaldavad kahjuliku koodi kaugkäivitamist ilma sisselogimata. BSI on välja kuulutanud hoiatustaseme 3 / oranž ja soovitab uuendada kohe.
Kes oma veebisaiti veebimajutaja juures peab, ei saa uuendust sageli ise paigaldada. Samal ajal vastutate haldajana oma klientide andmete eest. Veebimajutaja kirjalik ja konkreetne kinnitus on seetõttu enamat kui vormiasi. See on osa teie dokumentatsioonist, näiteks andmekaitsespetsialistide, kindlustajate või juhatuse ees.
Lisaks: paik ei eemalda kahjutarkvara, mis toodi sisse enne seda. Meediaraportite kohaselt täheldati esimest rünnakukatset juba 17.10. Täpne ajahetk, millest alates teie server oli kaitstud, on seetõttu oluline küsimuses, kas peate kontrolli jätkama.
Miks kuvatud PHP versioonist ei piisa
Parandatud on PHP 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Paljud distributsioonid ja veebimajutajad võtavad parandused aga oma paketti üle tagasiportimisena (backport). Siis näitab haldusliides, näiteks Plesk, jätkuvalt versiooni 8.2.34, kuigi server on paigatud.
Vastupidi võib ka õige versiooninumber eksitada. Uued failid üksi ei kaitse, kuni mälus töötavad vanad PHP protsessid. Uus seis on aktiivne alles kõigi töötajate (worker) taaskäivitamise järel. Lisateavet leiate artiklist PHP versiooni ja paigaseisu õige kontrollimine.
| Veebimajutaja väide | Mida see tõendab | Mis veel puudub |
|---|---|---|
| „Kõik süsteemid on ajakohased.“ | vähe | versioon või paketi seis, kuupäev, taaskäivitus |
| „PHP 8.3.36 on paigaldatud.“ | versioon | kuupäev, taaskäivitus, mõjutatud serverid |
| „Backport paketis xy, taaskäivitus …“ | paik ja aktiveerimine | vajaduse korral andmed PHP 8.1 ja vanemate kohta |
Milliseid andmeid veebimajutajalt vaja on
Paluge vastuseid neile punktidele, võimaluse korral iga veebisaidi või lepingu kohta:
- Millised PHP harud ja versioonid on teie veebisaitidel aktiivsed, ka vanemad, mis töötavad ainult üksikutes kataloogides?
- Kas CVE-2026-109618 ja CVE-2026-109619 parandused on sisaldatud, ametliku versioonina või tagasiportimisena?
- Millal uuendus paigaldati ja millal kõik PHP protsessid (FPM-poolid, Apache, LiteSpeed) taaskäivitati?
- Kas
session.upload_progress.enabledon CVE-2026-115560 tõttu keelatud? - Millist töörežiimi teie tariif kasutab, näiteks PHP-FPM või Apache koos mod_php-ga? mod_php puhul näeb PHP meeskond suurimat riski.
- Milliseid juurdepääsu- ja vealogisid alates 20.10.2026 säilitatakse ja kuidas te need kätte saate?
Kui veebisait töötab veel PHP 8.1 või vanemal versioonil, küsige eraldi. Nende harude jaoks ametlikke uuendusi enam ei ole, on vaid minimaalsed lähtekoodi tagasiportimised versioonidele 7.4, 8.0 ja 8.1.
Mall: PHP uuenduse kinnituse nõudmine veebimajutajalt
Kopeerige tekst tugipiletisse või e-kirja oma veebimajutajale. Täiendage nurksulgudes olevad andmed.
Teema: Palve PHP paigaseisu kinnituseks (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Tere,
haldame teie juures järgmisi veebisaite / lepinguid:
[Kliendinumber, leping, domeenid]
Seoses PHP turvaaukudega CVE-2026-109618 ja CVE-2026-109619 (PHP2Shell,
paigad 21.10.2026) ning 23.10.2026 antud teatega CVE-2026-115560 kohta
palume kirjalikku kinnitust järgmistes punktides:
1. Millised PHP versioonid või paketi seisud on meie veebisaitidel aktiivsed?
2. Kas need sisaldavad parandusi (ametlik versioon või backport)?
3. Paigaldamise kuupäev ja kellaaeg.
4. Kõigi PHP protsesside (FPM, Apache, LiteSpeed vms) taaskäivitamise
kuupäev ja kellaaeg.
5. Kas session.upload_progress.enabled on serveri poolel keelatud?
6. Millist PHP töörežiimi kasutatakse (nt PHP-FPM, mod_php)?
7. Kas juurdepääsu- ja vealogisid säilitatakse alates 20.10.2026 ja
kuidas me neid kätte saame?
8. Kui mõni veebisait kasutab veel PHP 8.1 või vanemat: milline kaitse
seal on ja millist üleminekut te soovitate?
Neid andmeid vajame oma sisemise dokumentatsiooni jaoks.
Täname ja ootame vastust
[Nimi, ettevõte, ametikoht]
Vastuse õige hindamine ja ise kontrollimine
Hea vastus nimetab konkreetseid seise, kuupäevi ja kellaaegu. Üldised sõnastused nagu „oleme reageerinud“ ei piisa teie toimiku jaoks. Küsige sel juhul viisakalt puuduvate punktide kohta.
Kui teie tariif seda lubab, kontrollige lisaks ise. SSH-juurdepääsu korral piisab tavaliselt neist käskudest:
# Käsurea versioon (võib veebiversioonist erineda)
php -v
# Paketi seis Debianis/Ubuntus
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Paketi seis RHEL-is, Almas, Rockys
rpm -qa | grep -i php
# Alates millal PHP-FPM protsessid töötavad?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Kui PHP protsesside käivitusaeg on varasem kui kinnitatud paigaldamise kuupäev, ei olnud taaskäivitus täielik.
Kui veebimajutaja ei vasta või vastab kõrvalepõiklevalt
Kui vastust ei tule või otsustavad andmed puuduvad, ei tohiks te olukorda pidada selgitatuks. BSI soovitab veebiserverid ajutiselt võrgust maha võtta, kui uuendus ei ole kohe võimalik. Kas see on teie veebisaidi puhul proportsionaalne, otsustab juhatus, ideaalis kirjalikult ja kuupäevaga.
Samal ajal tasub otsida võimalikke ründejälgi, sest paigamise ajahetk jääb lahtiseks. Kinnitusi pakub artikkel Kas mind on juba kompromiteeritud?. Ilma SSH-juurdepääsuta jääb kirjalik kinnitus teie tähtsaimaks tõendiks. Millised kohustused on veebimajutajal ja millised teil, selgitab leht Jagatud veebimajutus: mida veebimajutaja teeb; hallatud serverite puhul aitab Hallatav server: vastutuse selgitamine.
Hoidke päring, vastus ja oma kontrollitulemused kuupäevaga ühes kaustas. See toimik aitab hiljem kindlustajate või andmekaitsespetsialistide küsimuste korral.
Kuidas PHP SOS konkreetselt aitab?
- Sõnastame koos teiega päringu veebimajutajale ja hindame vastust erialaselt.
- Kus juurdepääs on olemas, kontrollime ise paketi seisu, aktiivset töörežiimi ja PHP protsesside taaskäivitust.
- Kui lüngad jäävad, rakendame üleminekumeetmed või planeerime ülemineku toetatud versioonile.
- Fikseerime tulemuse ja ajahetked tõendina, mida saate sisemiselt edasi anda.
Kuidas uuendus koos taaskäivituse ja tõendiga kulgeb, kirjeldab meie PHP paigateenus.
Korduma kippuvad küsimused
Kas piisab, kui mu veebimajutaja kirjutab, et kõik on ajakohane?
Teie dokumentatsiooni jaoks pigem mitte. Paluge konkreetseid andmeid: paketi seis või versioon iga PHP haru kohta, paigaldamise kuupäev ja kõigi PHP protsesside taaskäivitamise kuupäev. Alles nende põhjal saate piiritleda haavatavuse ajaakna.
Miks näitab minu majutuse haldusliides endiselt PHP 8.2.34?
Distributsioonid ja veebimajutajad portivad turvaparandusi sageli tagasi (backport), muutmata versiooninumbrit. Siis võib Plesk näidata edasi 8.2.34, kuigi server on paigatud. Selguse annab ainult pakkuja kinnitus paketi seisu kohta.
Mida teha, kui veebimajutaja ei vasta?
Dokumenteerige oma päring kuupäevaga ja küsige mõistliku aja pärast uuesti. Kontrollige samal ajal, kas saate üleminekumeetmed ise rakendada, ning leppige juhatusega kokku, kas veebisait läheb kuni selgumiseni võrgust maha, nagu BSI paigata serverite puhul soovitab.
Kas WordPressi või poe uuendus sulgeb turvaaugu samuti?
Ei. PHP2Shell asub PHP-s endas. Sisuhaldussüsteemi või poetarkvara uuendus ei muuda serveris töötavat PHP interpretaatorit.