Röviden: A PHP2Shell és a Log4Shell közös vonása, hogy kritikus rések egy nagyon elterjedt alapépítőelemben, amelyeken keresztül a támadók bejelentkezés nélkül futtathatnak kódot. A láthatóságban, a besorolásban és az ismert támadások helyzetében különböznek. A Log4Shell legfontosabb tanulsága ma változatlanul érvényes: aki tudja, hol fut az érintett építőelem, órák alatt cselekszik hetek helyett.
Miért bukkan fel most mindenütt az összehasonlítás
2021 decemberében a Log4Shell hetekig lélegzetvisszafojtva tartotta az IT-világot. A BSI akkor a legmagasabb, piros riasztási szintet hirdette ki. Majdnem öt évvel később a PHP2Shell kapcsán sok írásban ugyanez a név hangzik el, gyakran a kérdéssel: „Ez megint ilyen súlyos lesz?”
Az összehasonlítás kézenfekvő, és hasznos, ha helyesen végzik. Megmutatja, mely minták ismétlődnek, és mely tapasztalatokat hasznosíthatnak a vállalatok közvetlenül. Hogyan sorolja be a BSI az aktuális helyzetet, azt a BSI narancs riasztási szint írás magyarázza.
PHP2Shell és Log4Shell közvetlen összehasonlításban
| Jellemző | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Érintett szoftver | Log4j Java-könyvtár | maga a PHP-futtatókörnyezet |
| Azonosító | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Értékelés | CVSS 10,0 (v3) | CVSS v4.0 9,2 |
| Hatás | kódfuttatás bejelentkezés nélkül | kódfuttatás bejelentkezés nélkül |
| BSI riasztási szint | 4 / piros | 3 / narancs |
| Helyzet a figyelmeztetéskor | az akkori beszámolók szerint feltörések ismertek | támadási kísérletek beszámolók szerint, a BSI szerint kezdetben nem voltak megerősített, széles körű sikeres támadások |
| Láthatóság | gyakran mélyen elrejtve az alkalmazásokban | a szerveren látható, a javítási állapot azonban a backportok miatt nehezen olvasható le |
| Következő közlemények | több további CVE néhány héten belül | közlemény a CVE-2026-115560-ról október 23-án |
Mi a közös a két résben
Egy alapépítőelem, számtalan alkalmazás. A Log4j mindenféle Java-szoftverben benne volt, a PHP a WordPresst, a Shopwaret, a TYPO3-at és számtalan egyedi fejlesztést hordoz. Mindkét esetben nem egy termék érintett, hanem egy alapzat.
Nincs szükség bejelentkezésre. Mindkét rés lehetővé teszi a kód távoli futtatását bejelentkezés nélkül. Ettől vonzók az automatizált támadások számára.
A javítás nem a vég. A Log4Shellnél kiderült, hogy sok rendszert a frissítés előtt már megtámadtak. A PHP2Shellnél is igaz: egy javítás nem távolítja el a bejuttatott kártékony szoftvert. Médiabeszámolók szerint az első támadási kísérletet már október 17-én megfigyelték.
Következő közlemények. A Log4Shell után néhány héten belül újabb CVE-k jelentek meg a Log4j-hez. A PHP-nál a javítások után két nappal megjelent a CVE-2026-115560-ról szóló közlemény. Hogy miért valószínűek további közlemények, azt a A PHP2Shell után: miért valószínűek további közlemények írás magyarázza.
Hol sántít az összehasonlítás
A legnagyobb különbség a láthatóságban van. A Log4j gyakran egy alkalmazás részeként volt beépítve, néha többszörösen egymásba ágyazva. Sok üzemeltető egyszerűen nem tudta, hogy használja. A PHP viszont egy webszerveren nem titok. Ehelyett a PHP2Shellnél másfajta bizonytalanság keletkezik: a disztribúciók és a tárhelyszolgáltatók a javításokat backportként telepítik, a kijelzett verziószám ugyanaz marad. A PHP-t látja az ember, de nem rögtön azt, hogy javított-e.
A második különbség a frissítés kiindulási helyzete. A Log4Shellnél gyakran a szakalkalmazások gyártóinak kellett először új verziókat szállítaniuk. A PHP2Shellnél frissítések állnak rendelkezésre az összes támogatott ághoz. Nehéz a helyzet a PHP 8.1-nél és régebbieknél, amelyekhez a PHP-projekt már nem ad ki hivatalos frissítéseket.
A harmadik különbség a támadás helyét érinti. A Log4Shellnél veszélyes lehetett minden hely, ahol egy alkalmazás bemeneteket naplózott, vagyis a belső rendszerek is, amelyek csak közvetetten kaptak adatot az internetről. A PHP2Shellnél a kéréseket közvetlenül fogadó webszerver áll a középpontban. Ez kissé áttekinthetőbbé teszi az érintett rendszerek keresését: először jön az összes nyilvánosan elérhető PHP-szolgáltatás, utána a belső alkalmazások.
Végül a kihasználás helyzete is különbözik. A Log4Shellhez korán keringtek egyszerű támadóeszközök, és a feltörések az akkori beszámolók szerint már a figyelmeztetés idején ismertek voltak. A PHP2Shellnél a Cloudflare és a Patchstack támadási kísérletekről számol be, a watchTowr saját közlése szerint reprodukálta az egyik rést, megerősített, széles körű sikeres támadásokról a BSI kezdetben nem számolt be. Ez változhat. Ez azonban egy ok arra, hogy az összehasonlítás miért nem alkalmas előrejelzésnek.
Használja fel a Log4Shell tapasztalatait a saját házában: mely listák, folyamatok és kapcsolatok segítettek akkor? Ezek közül sok közvetlenül újra felhasználható a PHP2Shellhez.
Öt tanulság a Log4Shellből, amely ma segít
- Leltár a javítás előtt: Aki 2021-ben aktuális listával rendelkezett a rendszereiről, gyorsabb volt. Ez ma is így van. Útmutatót kínál az Az összes weboldal és szerver leltára írás.
- Ismerje a függőségeket: A szoftverépítőelemek jegyzéke, röviden SBOM, perceken belül megválaszolja a „Hol használjuk ezt?” kérdést. A PHP-alkalmazásoknál segít a Composerbe való betekintés, ahogyan azt a Composer-függőségek ellenőrzése írja le.
- Őrizze meg a naplókat: A Log4Shell után sok vállalat már nem tudta tisztázni, hogy érintett volt-e, mert hiányoztak a naplók. A szaksajtó a PHP2Shellnél azt javasolja, hogy mentse a naplókat október 20-tól.
- Utólagos ellenőrzés: Egy javítás nem válaszolja meg, mi történt korábban. A nyomok ellenőrzése is hozzátartozik.
- Készüljön fel a következő közleményekre: Az első frissítés ritkán az utolsó. Aki egyszer rendesen kialakította a frissítési utat, gyorsan megismétli.
Hogyan segít konkrétan a PHP SOS?
- Helyzetfelmérés: Meghatározzuk, hol fut PHP a vállalatánál, milyen verzióban és üzemmódban.
- Javítás és újraindítás: Telepítjük a frissítéseket, és rendszerenként igazoljuk az állapotot.
- Nyomok ellenőrzése: Mentjük a naplókat, és október 17. óta feltűnő jelenségeket keresünk.
- Tartós megfigyelés: Szemmel tartjuk a rendszereit, hogy a következő közleményeknél ne kezdődjön megint nulláról a munka.
Hogyan néz ki a folyamatos felügyelet, azt a Biztonsági monitoring webszerverekhez írja le.
Összegzés
A PHP2Shell nem a Log4Shell, de rímel rá. Mindkettő egy alapzatot talál el, mindkettőnek több kell egy javításnál. Azok a vállalatok, amelyek 2021-ből leltárt, naplómegőrzést és frissítési utakat vittek magukkal, ma előnyben vannak. Mindenki másnak most van itt az ideje pótolni.
Gyakori kérdések
Olyan súlyos a PHP2Shell, mint a Log4Shell?
Mindkettő kritikus rés egy nagyon elterjedt szoftverben, amelyen keresztül a támadók bejelentkezés nélkül futtathatnak kódot. A BSI (a német szövetségi információbiztonsági hivatal) a Log4Shellt 2021-ben pirossal, a PHP2Shellt narancssal sorolta be. Fontos különbség: a Log4Shellnél az akkori beszámolók szerint a figyelmeztetéskor már ismertek voltak feltörések, a PHP2Shellnél a BSI szerint kezdetben nem voltak megerősített, széles körű sikeres támadások.
Mi volt a Log4Shell?
A Log4Shell egy kritikus rés volt a Log4j Java-könyvtárban, amely 2021 decemberében vált ismertté, és a CVE-2021-44228 alatt szerepel. A Log4j nagyon sok alkalmazásban építőelemként szerepelt, gyakran anélkül, hogy az üzemeltetők tudtak volna róla.
Jönnek újabb rések a PHP2Shell után?
Ez lehetséges. A Log4Shell után néhány héten belül újabb CVE-k következtek a Log4j-hez. A PHP-nál október 23-án már megjelent egy közlemény a CVE-2026-115560-ról, amely csak szokatlan konfigurációnál érvényesül. Számoljon következő közleményekkel.
Mi az az SBOM?
A Software Bill of Materials egy alkalmazást alkotó összes szoftverépítőelem jegyzéke. Ennek segítségével egy új résnél gyorsan megállapítható, hol használják az érintett építőelemet.