Röviden: A PHP2Shell után további PHP-közlemények valószínűek, mert már két nappal a javítás után jött egy harmadik közlemény, a teljes advisory még várat magára, és a disztribúciók lépcsőzetesen szállítják utólag a csomagjaikat. Aki most rögzített folyamatot alakít ki a megfigyelésre, értékelésre, frissítésre és újraindításra, a következő új PHP biztonsági résre órák alatt reagál napok helyett.
A javítás nem volt a történet vége
- október 21-én a PHP-projekt bezárta a két kritikus rést, a CVE-2026-109618-at és a CVE-2026-109619-et, a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziókkal. Sok felelős ezután pipát tett. Két nappal később, október 23-án azonban újabb közlemény következett a php.net-től a CVE-2026-115560-ról.
Ez a harmadik közlemény csak egy szokatlan session-konfigurációt érint. Megmutat azonban egy mintát, amelyet a nagy biztonsági esetekből ismerünk: ha egy komponens hirtelen reflektorfénybe kerül, sok szakember egyszerre néz pontosabban. Hogy ebből adódnak-e további rések, azt ma senki sem tudja. Valószínű viszont, hogy a hírhelyzet nem szakad meg.
Üzemeltetőként ez azt jelenti: számoljon további közleményekkel, ahelyett hogy mindegyik meglepné. Az események eddigi menetét a PHP2Shell kronológiánk foglalja össze.
Miért valószínűek további közlemények
Az alábbi értékelés nyilvánosan ismert tényeken alapul. Nem konkrét rések előrejelzése.
- Egy advisory még várat magára. A php.net a CVE-2026-115560-at a rendes kiadási ciklusban kezeli, és bejelentette, hogy a teljes advisoryt a következő kiadással teszi közzé. Addig a
session.upload_progress.enabled=0számít megoldásnak. - A részletek korán nyilvánosak voltak. Több beszámoló szerint az embargó lejárta előtt részletek ismertté váltak. Beszámolók szerint a watchTowr saját közlése szerint reprodukálta a CVE-2026-109618-at. Az ilyen munkák gyakran szomszédos kódrészeket érintő további kérdésekhez vezetnek.
- A disztribúciók lépcsőzetesen szállítanak. Az Ubuntu október 21-én a USN-8948-1-gyel ellátta az aktuális kiadásokat, és a USN-8948-2-vel a 14.04-től a 20.04-ig terjedő javításokat az Ubuntu Pro-n keresztül pótolta. A Red Hat a közleményében azt írta, hogy egyes frissítések elérhetők, továbbiak készülnek.
- A fejlesztői verzió érintett. A php.net szerint a PHP 8.6.0 RC4 is tartalmazza a javításokat. Aki előzetes verziókat tesztel, annak ezeket a környezeteket is fel kell zárkóztatnia.
- A régi verziók nyitva maradnak. A PHP 8.1-hez és a régebbiekhez csak minimális forrásszintű backportok léteznek. Minden szolgáltató, amely ilyen verziókat szállít, önállóan és saját időpontokban jelenti az állapotát.
Hogyan ér el egy új PHP biztonsági rés
A közlemények különböző utakon és különböző megbízhatósággal érkeznek. A sorrend szinte mindig ugyanaz: először a PHP-projekt, aztán a disztribúciók és a tárhelyszolgáltatók, utána a hatóságok és a média.
| Forrás | Mit tudhat meg ott | Mennyire megbízható |
|---|---|---|
| php.net | Érintett ágak, javított verziók, átmeneti intézkedések | Elsődleges forrás |
| Ubuntu, Debian, Red Hat | Csomagállapotok kiadásonként, a szállítás időpontja | Elsődleges forrás az Ön rendszeréhez |
| Tárhelyszolgáltatók és panelgyártók | A saját PHP-buildek állapota | Csak írásban kötelező érvényű |
| BSI, CERT-Bund | Helyzetértékelés, riasztási szint, ajánlások | Hatósági besorolás |
| Szaksajtó és biztonsági cégek | Támadási megfigyelések, számok, háttér | Hasznos, beszámolóként jelölje |
Fontos a különbség a „van javítás” és a „a rendszeremen van a javítás” között. Az első kijelentés a php.net-en áll. A másodikat minden szerverre Önnek kell igazolnia.
Iratkozzon fel a php.net és a disztribúciója közleményeire RSS-sel vagy e-mail-listán, és irányítsa őket egy közös postafiókba vagy csatornába, amelyet egynél több személy olvas. A szabadság és a betegség a késedelmes frissítések leggyakoribb okai.
Mit érdemes előkészíteni a következő közlemény előtt
A PHP2Shell tapasztalata megmutatja, hol vész el idő: a szerverek keresésénél, a felelősségek tisztázásánál és az elfelejtett újraindításnál. Mindez előre elintézhető.
- Leltár: Az összes szerver és weboldal listája PHP-águkkal, üzemmódjukkal (PHP-FPM, mod_php, LiteSpeed) és csomagforrásukkal. E lista nélkül minden közlemény keresgéléssel kezdődik. Hogyan sikerül ez, azt az Az összes weboldal és szerver leltára írás írja le.
- Felelősség: Minden rendszerhez rögzített, ki javít, ki indít újra és ki hagy jóvá. Tárhelyszolgáltatóknál és ügynökségeknél ez a szerződésbe tartozik.
- Értékelési raszter: Három kérdés elég az első besoroláshoz. Érintett az águnk? Használjuk az érintett funkciót vagy üzemmódot? Van javítás, vagy csak átmeneti intézkedések?
- Tesztút: Egy staging környezet, amelyben egy PHP-frissítés rövid idő alatt ellenőrizhető.
- Igazolás: Egy rögzített formátum, amelyben a csomagállapot, a changelog-találat és az újraindítás ideje rögzítve van.
Hogyan működik egy ilyen folyamat rutinként tűzoltás helyett, azt a Javításkezelés folyamatként oldal tartalmazza. A PHP-projekt résekkel való bánásmódjának hátterét a Hogyan kezeli a PHP-projekt a biztonsági réseket oldal adja.
A saját konfiguráció mint korai figyelmeztető rendszer
A további közlemények egy része csak bizonyos beállításokat érint. A CVE-2026-115560 erre példa: a php.net feltételként azt nevezi meg, hogy egy alkalmazás futásidőben átállítja a session-szerializálót, miközben az upload progress aktív. Azok az alkalmazások, amelyek ezt soha nem teszik, a php.net szerint nem érintettek.
Aki ismeri a hatályos konfigurációját, gyorsabban be tudja sorolni az ilyen közleményeket. Rögzítse ezért minden ághoz, mely értékek vannak szerveroldalon beállítva, és mely alkalmazások írhatják felül őket. Már egy egyszerű összevetés is segít az aktív beállításokról:
# A parancssor hatályos értékei (a webes konfiguráció eltérhet)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Az FPM-poolokban beállított értékek (az útvonal disztribúciónként különböző)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
A parancssor nem feltétlenül azt mutatja, ami a webes környezetben érvényes. Egyértelműséget a pool- vagy VirtualHost-konfiguráció, valamint rövid időre és védetten egy phpinfo-oldal ad.
További előny: aki tudja, mely átmeneti értékek vannak még beállítva a PHP2Shell hetéből, a következő rendes kiadás után tudatosan ellenőrizheti őket. Egyes beállítások, például a kikapcsolt upload progress, tartósan értelmesek maradhatnak. Másokat, például a nagyon szűk feltöltési korlátokat, a szakosztályokkal való egyeztetés után érdemes visszaigazítani a tényleges igényhez.
Hogyan segít konkrétan a PHP SOS?
- Követjük a php.net, a disztribúciók és a BSI közleményeit, és az új tudnivalókat az Ön konkrét rendszereire nézve értékeljük.
- Önnel közösen elkészítjük az összes PHP-telepítés leltárát, és szerverenként rögzítjük a felelősségeket.
- Egy biztonsági karbantartási szerződés keretében telepítjük a frissítéseket, újraindítunk minden folyamatot, és dokumentáljuk az állapotot.
- Javítás nélküli közleményeknél felülírhatatlan átmeneti intézkedéseket alkalmazunk, és utólag ellenőrizzük őket.
Gyakori kérdések
Van már új PHP biztonsági rés a PHP2Shell után?
2026. október 23-án a php.net közleményt tett közzé a CVE-2026-115560-ról. Eszerint a kódfuttatás csak szokatlan session-konfigurációnál lehetséges. A teljes advisory a következő rendes kiadással várható.
Minden új közleménynél azonnal cselekednem kell?
Nem minden közlemény követel azonos sietséget. A döntő a súlyossági fok, a konfigurációja érintettsége és az, hogy van-e elérhető javítás. Egy rögzített folyamat segít ezt percek alatt értékelni napok helyett.
Hol értesülök először az új PHP-résekről?
Az elsődleges források a php.net közleményei és a disztribúciója biztonsági közleményei, például az Ubuntu Security Notices, a Debian Security Tracker vagy a Red Hat. A BSI (a német szövetségi információbiztonsági hivatal) figyelmeztetésekről tájékoztat. A médiabeszámolók hasznosak, de gyakran későbbiek és kevésbé pontosak.
Miért jelentenek néha a disztribúciók napokkal később, mint a php.net?
A disztribúcióknak át kell venniük a javítást a saját csomagjaikba, le kell fordítaniuk és tesztelniük kell. Régebbi kiadásoknál ez tovább tarthat, vagy csak kiegészítő ajánlatokon keresztül történhet. Ezért érdemes a két forrást külön követni.