# PHP2Shell és Log4Shell: mi a közös a két résben

> PHP2Shell és Log4Shell összehasonlítva: mi köti össze a réseket, miben különböznek, és mely 2021-es tanulságokat hasznosíthatják ma a vállalatok.

Forrás: https://phpsos.de/hu/blog/php2shell-und-log4shell/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/blog/bsi-warnstufe-orange-erklaert/) í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](https://phpsos.de/hu/blog/weitere-php-meldungen/) í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.

> **Tipp:**
> 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

1. **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](https://phpsos.de/hu/blog/inventar-websites-server/) írás.
2. **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](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) írja le.
3. **Ő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.
4. **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.
5. **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](https://phpsos.de/hu/leistungen/security-monitoring/) í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.

## Források

- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [php.net: biztonsági közlemények](https://www.php.net/)
- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)