A PHP fejlesztői október 26-án újra kiadták a PHP 8.2, 8.3, 8.4 és 8.5 hivatalos Windows-csomagjait. A frissítés a CVE-2026-111497 azonosítójú sérülékenységet javítja: egy hibásan felépített tömörített adatfolyam feldolgozásakor a Brotli-dekóder egy belső puffer határán túlra írhat. Az így megsérülő folyamatmemória az alkalmazás összeomlásához, bizonyos körülmények között pedig támadói kód futtatásához is vezethet.
A PHP által leírt támadási útvonalon az alkalmazás HTTP-kliensként működik: kapcsolatot kezdeményez egy másik szerverrel, majd kitömöríti a kapott választ. A sérülékeny dekóder a PHP cURL-bővítményén keresztül érhető el, ha az automatikus kitömörítés engedélyezett. A cURL-ben ez alapértelmezés szerint ki van kapcsolva, de maga az alkalmazás vagy az általa használt HTTP-klienskönyvtár bekapcsolhatja. Az új Windows-csomagok már a javított Brotli 1.2.1 verziót tartalmazzák. A PHP fejlesztőinek október 26-i közleménye
Melyik Windows-csomag tartalmazza a javítást?
| PHP-ág | A Brotli-javítást tartalmazó Windows-csomag | A PHP futáskor jelzett verziója |
|---|---|---|
| PHP 8.2 | 8.2.35-1 | 8.2.35 |
| PHP 8.3 | 8.3.36-1 | 8.3.36 |
| PHP 8.4 | 8.4.27-1 | 8.4.27 |
| PHP 8.5 | 8.5.12-1 | 8.5.12 |
A -1 a Windows-csomag kiadását jelöli: a fejlesztők frissítették a hozzá csomagolt könyvtárat, de a PHP forráskiadása és a futtatókörnyezet verziója nem változott. Ha egy nyilvántartásban például csak annyi látszik, hogy „PHP 8.4.27”, abból nem állapítható meg, hogy az eredeti csomag fut-e, vagy a Brotli-javítást már tartalmazó 8.4.27-1. Az üzemeltetőnek a telepített csomag teljes azonosítóját és a ténylegesen használt telepítési helyet kell ellenőriznie. A PHP hivatalos Windows-letöltései
Hogyan válhat egy tömörített webes válasz támadási útvonallá?
A Brotli csökkenti a hálózaton átvitt adatok méretét. A hiba a fogadó oldalon, az eredeti tartalom visszaállításakor jelentkezik. A Node.js biztonsági közleménye szerint a dekóder egy érvénytelen blokkváltást végleges formátumhiba helyett úgy értelmezhet, mintha csupán a bemenet következő részére kellene várnia. Emiatt az adatfolyam elutasítása helyett tovább ír egy belső pufferbe, akár annak végén túl is.
A következmény a programtól és futtatási környezetétől függ: a folyamat összeomolhat, a memóriájában tárolt adatok kiszivároghatnak, vagy távoli kódfuttatás válhat lehetővé. A Node.js projekt a sérülékenység bejelentését az OpenAI Codex Security két kutatójának, Khai Trannek és Sylvie Mayernek tulajdonítja. A Node.js biztonsági közleménye
A Windowsos PHP-nál ezért a kimenő HTTP-kéréseket is fel kell térképezni. Jó kiindulópont az olyan funkciók áttekintése, amelyek felhasználótól kapott URL-t nyitnak meg, távoli dokumentumot töltenek le, külső adatfolyamot importálnak vagy más szolgáltatás API-ját hívják. Egy ilyen funkció jelenléte önmagában nem bizonyít kihasználhatóságot. Három kérdés döntő: sérülékeny Brotli-verzió fut-e, az adott feldolgozási út meghívja-e a dekódert, és befolyásolhatja-e egy támadó a neki átadott tömörített adatot.
A cURL alapbeállítása nem feltétlenül az alkalmazás beállítása
A libcurl CURLOPT_ACCEPT_ENCODING opciója egyszerre szabályozza, milyen tartalomkódolásokat kér a kliens a kiszolgálótól, és bekapcsolja a válasz automatikus kitömörítését. Van egy könnyen félreérthető részlet: az üres karakterlánc nem a tömörítés kikapcsolását jelenti. Ezzel az értékkel a kliens az adott libcurl-kiadás által támogatott összes kódolást kéri.
A kiszolgáló ráadásul visszaküldhet a kérttől eltérő kódolású tartalmat. Ezért ha valaki pusztán törli a Brotlit jelölő br értéket a kimenő Accept-Encoding fejlécből, még nem igazolta, hogy a kliens egy beérkező Brotli-válasznál nem fogja meghívni a dekódert. A kérés fejlécét és a válasz tényleges feldolgozását külön kell ellenőrizni. A libcurl dokumentációja a CURLOPT_ACCEPT_ENCODING opcióról
A PHP-alkalmazások gyakran egy magasabb szintű HTTP-kliensen keresztül kommunikálnak. A Guzzle dokumentációja például a decode_content opció alapértelmezett értékeként true-t ad meg. Ebből nem következik, hogy minden Guzzle-telepítés sérülékeny: számít a tényleges kéréskezelő, az alatta működő könyvtárak és a beérkező adat is. A példa azt mutatja, miért nem elég a cURL gyári beállítását ellenőrizni annak megállapításához, hogyan viselkedik az alkalmazás. A Guzzle decode_content beállítása
Node.js alatt sikerült kódot futtatni – mit bizonyít ez a PHP-ról?
Az Imperva kutatója, Ron Masas működő demonstrációt ismertetett a hivatalos Node.js 24.22.0 Linux ARM64 konténerképen. A kutatók speciálisan összeállított Brotli-adatokkal kódfuttatást értek el, míg a javított Node.js 24.22.1 ugyanazt a bemenetet elutasította. A tesztkörnyezetben a sikeres kihasználáshoz több próbálkozás kellett. Az Imperva kutatási beszámolója
A kutatók két külön feldolgozási utat vizsgáltak. Az egyikben a Node.js beépített fetch() függvénye távoli szerver válaszát fogadta. A másikban egy erre beállított szerveroldali köztes szoftver a bejövő kérés törzsét tömörítette ki. Ez utóbbi az adott Node.js-alkalmazás sajátossága volt; a PHP közleménye a Windows-csomagoknál a cURL-lel fogadott válasz automatikus kitömörítését nevezi meg.
A demonstráció tehát megmutatja, hogy a dekóder hibája megfelelő környezetben valóban kihasználható kódfuttatásra. Nem igazol működő támadást a Windowsos PHP-csomagok ellen. A PHP október 26-i bejelentése sérülékeny komponenst és hozzá vezető alkalmazási útvonalat azonosít, de nem számol be e Windows-csomagok elleni aktív támadásokról. A PHP bejelentése
Ugyanaz a Brotli-könyvtár több rendszerben is frissítésre szorulhat
A Google Brotli projektje október 21-én három ághoz adott ki javítást: az 1.2.1, 1.1.1 és 1.0.10 kiadás egyaránt kezeli a CVE-2026-111497 jelű hibát. A hivatalos Windowsos PHP-csomagokba ezek közül az 1.2.1 került. A Brotli projekt kiadási megjegyzései
Más projektek is frissítést vagy biztonsági tájékoztatót adtak ki. A Microsoft október 25-én a rendes kiadási cikluson kívül frissítette a .NET-et. Közleménye szerint ott az érintettség attól függ, hogy az alkalmazás engedélyezi-e a Brotli-kitömörítést, vagy közvetlenül meghívja-e a kitömörítési függvényeket támadó által befolyásolható adatokon. A Microsoft a .NET Frameworköt nem sorolja az érintett termékek közé. Az Envoy projekt a Brotli-kitömörítővel konfigurált telepítéseket nevezi meg érintettként. A Microsoft .NET biztonsági közleménye · Az Envoy biztonsági tájékoztatója
Ez az üzemeltetésben azt jelenti, hogy akár egyetlen kiszolgálón is több, külön karbantartott Brotli-példány lehet. Az operációs rendszer csomagkezelője frissítheti a rendszer saját könyvtárát anélkül, hogy megváltozna egy futtatókörnyezetbe, proxyba vagy külső szállító alkalmazásába beépített másolat. Mindegyiknél annak a szállítónak a javítását kell ellenőrizni, amelyik az adott példányt terjeszti.
A Windows-csomagok cseréje külön feladat a PHP2Shell javításától
Az október 26-i Windows-kiadások öt nappal a két PHP2Shell-sérülékenységhez kiadott sürgősségi frissítések után érkeztek. A CVE-2026-109618 a memória elfogyásának hibás kezelésével, a CVE-2026-109619 pedig a korábbi kérés lezárása után visszamaradó belső állapottal függ össze. Bizonyos feltételek mellett mindkettő hitelesítés nélküli távoli kódfuttatást tehet lehetővé. A brit Nemzeti Kiberbiztonsági Központ (NCSC) az összes PHP-telepítés azonosítását, a kívülről elérhető rendszerek előresorolását és a PHP-t beépítve szállító gyártók közleményeinek követését javasolta. A brit NCSC PHP2Shell-riasztása
A Brotli hibája ettől elkülönülő sérülékenység egy mellékelt könyvtárban. Például aki október 21-én a hivatalos Windowsos PHP 8.5.12 csomagra frissített, az megkapta a két PHP2Shell-javítást. A Brotli-javítás azonban csak az október 26-i 8.5.12-1 csomagba került bele. Egy „PHP frissítve” állapotú hibajegy ezért csak akkor igazolja mindhárom javítást, ha a teljes csomagazonosító is ismert.
Mit ellenőrizzenek most az üzemeltetők?
- Azonosítsák és cseréljék le a hivatalos Windows-csomagot. A megfelelő PHP-ághoz tartozó újracsomagolt kiadást telepítsék, és rögzítsék a teljes csomagazonosítót. Más szállító csomagjánál annak saját biztonsági közleménye az irányadó.
- Ellenőrizzék, mi töltődött be ténylegesen. A kompatibilitási próba után indítsák újra az érintett folyamatokat, hogy azok az új komponenseket használják. Nézzék meg a háttérfolyamatokat, az ütemezett feladatokat és a párhuzamos PHP-telepítéseket is: ezek másik könyvtárból indíthatják a PHP-t, mint a webhely.
- Próbálják ki a tömörített válaszokat fogadó alkalmazásokat. Különösen azokat az integrációkat ellenőrizzék, amelyek távoli dokumentumot, adatfolyamot vagy API-választ töltenek le. A normál működés mellett azt is érdemes tisztázni, melyik kliensréteg végzi a kitömörítést.
- Ha késik a telepítés, az automatikus kitömörítést kapcsolják ki, ne csak a kérés fejlécét módosítsák. Ez akkor zárja le a PHP által ismertetett útvonalat, ha minden érintett kliensbeállításban érvényes, és a tömörített adatot később sem adják át másik sérülékeny dekódernek. A PHP által megnevezett támadási feltétel
Guzzle esetében a decode_content értéke false-ra állítható. Ilyenkor a válasz törzse kitömörítetlen marad: a JSON-t vagy HTML-t váró kód tömörített bájtokat kaphat, ezért az átmeneti intézkedést is tesztelni kell. A Guzzle dokumentációja
Ennél a frissítésnél a lezárás legjobb bizonyítéka a telepített Windows-csomag azonosítója és annak ellenőrzése, hogy a webhely, a háttérfolyamatok és az ütemezett feladatok már azt használják. A PHP változatlan verziószáma ezek egyikét sem igazolja önmagában.
Eredeti cím: PHP Releases Emergency Windows Security Update To Fix Critical Brotli Decoder Vulnerability
