Lühidalt: Pärast PHP2Shelli on PHP kohta täiendavad teated tõenäolised, sest juba kaks päeva pärast paika tuli kolmas märkus, täielik teade (advisory) on veel puudu ja distributsioonid tarnivad oma pakette etapiviisiliselt. Kes seab nüüd sisse kindla käigu seireks, hindamiseks, uuenduseks ja taaskäivituseks, reageerib järgmisele uuele PHP turvaaugule tundidega, mitte päevadega.
Paik ei olnud loo lõpp
- oktoobril 2026 sulges PHP projekt kaks kriitilist turvaauku CVE-2026-109618 ja CVE-2026-109619 versioonidega 8.5.12, 8.4.27, 8.3.36 ja 8.2.35. Paljud vastutajad panid pärast seda linnukese. Kaks päeva hiljem, 23. oktoobril, järgnes aga veel üks php.net-i märkus CVE-2026-115560 kohta.
See kolmas märkus puudutab ainult ebatavalist sessioonide seadistust. See näitab aga mustrit, mida suurte turvajuhtumite puhul tuntakse: kui mõni komponent satub äkki valgusvihku, vaatavad paljud spetsialistid samal ajal täpsemalt. Kas sellest tekib täiendavaid turvauke, ei tea täna keegi. Tõenäoline on aga, et uudiste voog ei katke.
Teie kui käitaja jaoks tähendab see: planeerige järgnevad teated ette, selle asemel et igaühest üllatuda. Sündmuste senise käigu võtab kokku meie PHP2Shelli kronoloogia.
Miks täiendavad teated on tõenäolised
Järgnev hinnang põhineb avalikult teadaolevatel faktidel. See ei ole konkreetsete turvaaukude prognoos.
- Teade (advisory) on veel puudu. php.net käsitleb CVE-2026-115560 korralises väljalasketsüklis ja on teatanud, et avaldab täieliku teate järgmise väljalaskega. Seni kehtib abinõuna
session.upload_progress.enabled=0. - Üksikasjad olid vara avalikud. Mitme aruande kohaselt said üksikasjad teatavaks enne embargo lõppu. Aruannete kohaselt on watchTowr CVE-2026-109618 oma andmetel järele teinud. Selline töö viib sageli järelküsimusteni naabruses asuvate koodikohtade kohta.
- Distributsioonid tarnivad etapiviisiliselt. Ubuntu varustas 21. oktoobril USN-8948-1-ga praegused väljalasked ja andis USN-8948-2-ga Ubuntu Pro kaudu hiljem parandused versioonidele 14.04 kuni 20.04. Red Hat kirjutas oma bülletäänis, et mõned uuendused on saadaval, teised töös.
- Arendusversioon on mõjutatud. php.net-i andmetel sisaldab parandusi ka PHP 8.6.0 RC4. Kes katsetab eelversioone, peab ka need keskkonnad järele tõmbama.
- Vanad versioonid jäävad lahti. PHP 8.1 ja vanemate jaoks on olemas ainult minimaalsed lähtekoodi tagasiportimised. Iga pakkuja, kes selliseid versioone tarnib, teatab oma seisust iseseisvalt ja omal ajal.
Kuidas uus PHP turvaauk teieni jõuab
Teated tulevad erinevaid teid pidi ja erineva usaldusväärsusega. Järjekord on peaaegu alati sama: kõigepealt PHP projekt, siis distributsioonid ja veebimajutajad, seejärel ametiasutused ja meedia.
| Allikas | Mida seal teada saate | Kui usaldusväärne |
|---|---|---|
| php.net | Mõjutatud harud, parandatud versioonid, ajutised meetmed | Esmaallikas |
| Ubuntu, Debian, Red Hat | Pakettide seis väljalaske kaupa, tarneaeg | Esmaallikas teie süsteemi jaoks |
| Veebimajutajad ja paneelipakkujad | Oma PHP ehituste seis | Siduv ainult kirjalikult |
| BSI, CERT-Bund | Olukorra hinnang, hoiatustase, soovitused | Ametiasutuse hinnang |
| Erialaajakirjandus ja turvafirmad | Rünnakute vaatlused, arvud, taustad | Abiks, märkida aruandena |
Oluline on erinevus „paik on olemas“ ja „minu süsteemis on paik“ vahel. Esimene väide seisab php.net-is. Teise peate iga serveri kohta ise tõendama.
Tellige php.net-i ja oma distributsiooni teated RSS-i või e-posti loendi kaudu ning suunake need ühisesse postkasti või kanalisse, mida loeb rohkem kui üks inimene. Puhkus ja haigus on kõige sagedasemad hilinenud uuenduste põhjused.
Mida peaksite enne järgmist teadet ette valmistama
PHP2Shelli kogemus näitab, kus aeg kaob: serverite otsimisel, vastutuse selgitamisel ja unustatud taaskäivitusel. Seda kõike saab ette ära teha.
- Inventar: Kõigi serverite ja veebisaitide loend PHP haru, töörežiimi (PHP-FPM, mod_php, LiteSpeed) ja pakettide allikaga. Ilma selle loendita algab iga teade otsimisega. Kuidas see õnnestub, kirjeldab artikkel Kõigi veebisaitide ja serverite inventar.
- Vastutus: Iga süsteemi kohta on kindel, kes paikab, kes uuesti käivitab ja kes annab loa. Veebimajutajate ja agentuuride puhul kuulub see lepingusse.
- Hindamisraster: Esmaseks liigitamiseks piisab kolmest küsimusest. Kas meie haru on mõjutatud? Kas kasutame mõjutatud funktsiooni või töörežiimi? Kas paik on olemas või ainult ajutised meetmed?
- Testitee: Staging-keskkond, kus PHP uuendust saab lühikese ajaga kontrollida.
- Tõend: Kindel vorm, milles fikseeritakse paketi seis, muudatuslogi tabamus ja taaskäivituse aeg.
Kuidas selline käik toimib rutiinina, mitte tuletõrjeoperatsioonina, seisab lehel Paikamise haldus protsessina. Tausta PHP projekti käsitlusest turvaaukudega annab leht Kuidas PHP projekt turvauke käsitleb.
Oma seadistus varajase hoiatussüsteemina
Osa järgnevatest teadetest puudutab ainult kindlaid sätteid. CVE-2026-115560 on selle näide: php.net nimetab eeldusena, et rakendus lülitab sessiooni serialiseerija töö ajal ümber, kui Upload-Progress on aktiivne. Rakendused, mis seda kunagi ei tee, ei ole php.net-i andmetel mõjutatud.
Kes tunneb oma toimivat seadistust, oskab selliseid teateid kiiremini hinnata. Pange seetõttu iga haru kohta kirja, millised väärtused on serveri poolel seatud ja millised rakendused neid üle kirjutada tohivad. Juba aktiivsete sätete lihtne võrdlus aitab:
# Käsurea toimivad väärtused (veebiseadistus võib erineda)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# FPM-poolides seatud väärtused (tee on distributsiooniti erinev)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Käsurida ei näita tingimata, mis veebikontekstis kehtib. Selguse annavad poolide või VirtualHosti seadistus ja ajutiselt ning kaitstult phpinfo-leht.
Veel üks eelis: kes teab, millised ajutised väärtused PHP2Shelli nädalast veel seatud on, saab neid pärast järgmist korralist väljalaset teadlikult üle vaadata. Mõned sätted, näiteks väljalülitatud Upload-Progress, võivad jääda püsivalt mõistlikuks. Teised, nagu väga napid üleslaadimise piirid, tuleks pärast konsulteerimist erialaosakondadega taas tegelikule vajadusele kohandada.
Kuidas PHP SOS konkreetselt aitab?
- Jälgime php.net-i, distributsioonide ja BSI teateid ning hindame uusi märkusi teie konkreetsete süsteemide jaoks.
- Koostame teiega kõigi PHP paigaldiste inventari ja määrame serverite kaupa vastutuse.
- Turvahoolduslepingu raames paigaldame uuendused, käivitame kõik protsessid uuesti ja dokumenteerime seisu.
- Teadete puhul, mille jaoks paika ei ole, seame ajutised meetmed üle kirjutamatult ja kontrollime neid hiljem.
Korduma kippuvad küsimused
Kas pärast PHP2Shelli on juba uus PHP turvaauk?
23. oktoobril 2026 avaldas php.net märkuse CVE-2026-115560 kohta. Koodi käivitamine on selle kohaselt võimalik ainult ebatavalise sessioonide seadistuse korral. Täielik teade (advisory) peaks järgnema järgmise korralise väljalaskega.
Kas pean pärast iga uut teadet kohe tegutsema?
Mitte iga teade ei nõua sama kiirust. Otsustavad on tõsidus, teie seadistuse mõjutatus ja küsimus, kas paik on olemas. Kindlaks määratud käik aitab seda minutitega, mitte päevadega hinnata.
Kust ma uutest PHP turvaaukudest esimesena teada saan?
Esmaallikad on php.net-i teated ja teie distributsiooni turvamärkused, näiteks Ubuntu Security Notices, Debian Security Tracker või Red Hat. BSI teavitab hoiatusteadetest. Meediaaruanded on abiks, kuid sageli hilisemad ja vähem täpsed.
Miks distributsioonid vahel teatavad päevi hiljem kui php.net?
Distributsioonid peavad paranduse oma pakettidesse üle võtma, ehitama ja testima. Vanemate väljalasete puhul võib see kauem aega võtta või toimuda ainult lisapakkumiste kaudu. Seetõttu tasub mõlemat allikat eraldi jälgida.