HTTP2Shell és a WordPress: a Brotli-hibát nem a WordPress frissítése javítja
A HTTP2Shell a Brotli tömörítőkönyvtár hibája, nem a WordPressé, mégis elérhető egy WordPress-oldalon keresztül. Mit javít a frissítés, mit nem, és mit kérdezz a szolgáltatótól.

Október 23-án azt írtam, hogy a Node.js Brotli-hibája a legtöbb kisvállalkozói weboldalt nem érinti, mert egy hagyományos WordPress-oldal alatt nincs Node.js. Akkor ez így is volt, hiszen a hibát addig a Node.js-hez kötötték. November 2-án viszont a Wordfence, az egyik legnagyobb WordPress-biztonsági cég, a laborjában megmutatta, hogy ugyanez a hiba bizonyos szerverbeállítás mellett egy WordPress-oldalon keresztül is elérhető.
A jó hír, hogy magában a WordPressben nincs hiba, és a javítás nagy része most is a tárhelyszolgáltatóé. A kellemetlen rész az, hogy a WordPress, a bővítmények és a PHP frissítése ezt nem javítja, így aki a múlt hónapban mindent frissített, az ettől még érintett lehet.
A rövid válasz
Mi | Kit érint | Mi javítja | Kinek a dolga |
|---|---|---|---|
A Brotli-kicsomagoló hibája (HTTP2Shell, CVE-2026-111497) | minden programot, ami ezzel a könyvtárral csomagol ki kívülről jövő adatot: Node.js, Python, .NET és a szerver egyéb programjai | Brotli 1.0.10, 1.1.1, 1.2.1, vagy a szerver operációs rendszerének javított csomagja | a tárhelyszolgáltatóé vagy az üzemeltetőé |
Az út a WordPressen át (XML-RPC pingback) | WordPress-oldalt, ha a szerveren javítatlan Brotli-könyvtár fut | a fenti frissítés, addig a pingback kikapcsolása | a pingback a tiéd vagy a fejlesztődé |
Mi az a Brotli, és miért van a szerveren?
A Brotli egy tömörítési formátum, amit a Google fejlesztett. A szerverek és a böngészők ezzel küldik összenyomva az oldalakat, hogy gyorsabban érjenek át, ezért szinte minden szerveren ott van valamilyen formában. A hiba a kicsomagoló részben van: ha egy program olyan tömörített adatot csomagol ki, amit egy támadó rakott össze, a támadó felülírhat egy darabot a memóriából, és a legrosszabb esetben ebből saját kódot futtathat a szerveren.
A Brotli javított verziói október 21-én jelentek meg, a hiba másnap kapta meg a CVE-azonosítóját. A Google 9,2 ponttal kritikusnak sorolta, a Red Hat 8,1 ponttal egy fokkal enyhébbnek. A különbség abból jön, hogy két különböző pontozási rendszert használnak, a teendőn nem változtat.
Hogyan jut el a hiba egy WordPress-oldalig?
A WordPress régóta tud pingbacket: ha egy másik blog hivatkozik a cikkedre, erről értesítést küldhet az oldaladnak. Az értesítés az xmlrpc.php címre érkezik, bejelentkezés nélkül, és benne van a hivatkozó oldal címe. A WordPress ezután lekéri azt az oldalt, hogy megnézze, valóban linkel-e a cikkedre.
A támadás ezt használja ki. A támadó a saját szerverének a címét adja meg, a szervere pedig Brotlival tömörítettnek jelölt, szándékosan elrontott választ küld vissza. Ha a te szervereden a letöltést végző program a javítatlan Brotli-könyvtárral csomagolja ki ezt a választ, a hiba a te szervereden, a PHP-folyamaton belül jön elő.
A Wordfence a feltételeket is felsorolta. Elérhetőnek kell lennie az XML-RPC-nek, a pingbacknek bekapcsolva kell lennie, a megcélzott cikknek fogadnia kell az értesítéseket, a szervernek ki kell tudnia szólni az internetre, és a letöltést végző programnak az érintett Brotli-kicsomagolót kell használnia. Egy alapbeállításon hagyott WordPressnél az első négy jellemzően teljesül, vagyis az ötödiken múlik a dolog, az pedig a szerveren dől el.
A kódfuttatás ettől még nem egyszerű. A Wordfence tesztjében a támadásnak pontosan illeszkednie kellett a szerver PHP-verziójához és memóriakiosztásához: PHP 8.3.36-on lefutott, 8.3.35-ön nem, egy másik érintett környezetben pedig csak összeomlott a PHP-folyamat. Ebből nem az következik, hogy a régebbi PHP véd, hanem az, hogy a támadást minden szerverhez külön kell igazítani. A 8.3.36 ráadásul éppen az a verzió, amelyik a múlt havi PHP2Shell-javítást hozta, tehát a frissített PHP ettől a hibától nem véd. Amikor a tesztszerveren csak a Brotli-csomagot frissítették, a támadás nem futott le, és a szerver is működött tovább.
Támadják már?
Ebben a források nem egyeznek. Az amerikai kiberbiztonsági hivatal, a CISA október 27-én felvette a hibát az aktívan kihasznált sebezhetőségek listájára, de azt nem írta le, milyen programon keresztül, kit és milyen eredménnyel támadtak. A Microsoft a saját közleményében nyilvánosságra került, de ki nem használt hibaként jelölte. A Wordfence a november 2-ig átnézett jelentésekben pásztázást és próbálkozást talált, sikeres betörést viszont senki nem dokumentált, WordPressen keresztül pedig egyet sem.
Szerintem ebből annyi a lényeg, hogy a támadók már keresik a sérülékeny szervereket, a működő WordPress-támadáshoz viszont szerverenként külön kell igazítani a kódot. Ez ad egy kis időt, de nem sokat, mert október 28. óta nyilvánosan elérhető egy tesztkörnyezethez írt támadókód, amiből a többi változat készülhet.
Mit tegyél, ha WordPress-oldalad van?
Két dolgot, és ezek közül az első a fontosabb.
Kérdezd meg a szolgáltatót, frissítették-e a Brotlit. Ez a szerver része, a WordPress kezelőfelületéről nem látszik, és a beépített állapotjelentés (Site Health) sem mondja meg. Elég ennyit írni: „Telepítve van-e a szerveren a Brotli-könyvtár CVE-2026-111497 elleni javítása, és újraindították-e utána a PHP-t és a webszervert?” Az újraindításra azért kérdezz rá, mert a már futó folyamatok a memóriában tovább használják a régi könyvtárat.
Kapcsold ki a pingbacket, ha nem használod. Egy cégoldalon szerintem szinte soha nincs rá szükség, a régi blogos világból maradt itt. Ez csak a most megmutatott útvonalat zárja le, a Brotli-könyvtár ettől javítatlan marad a szerveren, ezért az első pontot nem váltja ki.
Ez a két feladat jól mutatja, miért külön munka a WordPress frissítése és a szerveré. Az elsőt a kezelőfelület jelzi, a másodikról csak akkor tudsz, ha valaki figyeli, ezért tartozik mindkettő a weboldal karbantartásához.
Hogyan kapcsold ki a pingbacket?
Itt könnyű félrecsúszni. Sok biztonsági pluginban van „XML-RPC kikapcsolása” jellegű kapcsoló, de ezek egy része csak a bejelentkezést igénylő funkciókat tiltja le, a pingback közben tovább működik. A Wordfence a saját bővítményéről is ezt írja: a „Disable XML-RPC authentication” opció a bejelentkezés nélküli pingbacket nem állítja le. A WordPress xmlrpc_enabled szűrője ugyanígy érintetlenül hagyja.
Három szinten lehet lezárni, a gyengébbtől az erősebbig:
A Beállítások menü hozzászólásokról szóló oldalán (angolul Discussion) kikapcsolhatod a más blogokról érkező értesítéseket. Ez csak az ezután írt cikkekre vonatkozik, a meglévőkön a pingback bekapcsolva marad.
Egy rövid kódrészlet kiveszi a
pingback.pingfunkciót az XML-RPC-ből, és ez már minden cikkre érvényes. Gyermeksablonba vagy egy saját kis pluginba tedd, mert a sablon frissítése felülírja afunctions.phpfájlt.Ha az oldalon semmi nem használja az XML-RPC-t, a webszerveren az egész
xmlrpc.phpletiltható. Előtte nézd meg, mi épít rá: a Jetpack például igen, és a régebbi mobilos WordPress-alkalmazás is ezen keresztül kapcsolódott.
A kódrészlet a második ponthoz:
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );
Fejlesztőknek, röviden
A Brotli-csomag Debianon és Ubuntun
dpkg -l | grep brotli, Red Hat-alapú rendszerenrpm -q brotli, Alpine-onapk info brotli. A disztribúciók visszaportolják a javítást, ezért a teljes csomagverziót vesd össze a saját biztonsági közleményükkel, ne a Brotli verziószámát. Debian 13-on a javított csomag az1.1.0-2+deb13u1.Frissítés után indítsd újra a PHP-FPM-et vagy az Apache-ot, és minden hosszan futó folyamatot, ami a régi könyvtárat töltötte be. A konténerképet friss alapképből építsd újra.
A PHP brotli bővítményénél (kjdev/php-ext-brotli) a 0.21.1 hozza a javított Brotlit. Node.js-nél a 22.23.4, a 24.22.1 és a 26.12.1, Pythonnál a brotli 1.2.1 és a brotlicffi 1.2.1.0 a javított verzió.
Amíg nem tudsz frissíteni, a megbízhatatlan forrásból jövő Brotli-tömörítésű választ ne csomagold ki automatikusan, a gzip és a deflate maradhat.
Őrizd meg a naplókat. A Wordfence a váratlan pingback-kéréseket, a szokatlan kimenő kapcsolatokat és a PHP- vagy webszerver-összeomlásokat javasolja átnézni.
Nem tudod, nyitva van-e nálad a pingback?
Küldd el az oldalad címét, és megnézem, elérhető-e kívülről az XML-RPC és a pingback. Ha kell, segítek megfogalmazni a kérdést a szolgáltatónak, vagy úgy kapcsolom ki a pingbacket, hogy a Jetpack és a többi bővítmény működjön tovább. Írj nekem.
Hozzászólások
Hozzászóláshoz jelentkezz be vagy regisztrálj.
Még nincs hozzászólás. Legyél az első!