# Veszélyes téves tippek a PHP2Shellről, amelyek éppen terjednek

> PHP2Shell tippek ténycsekkben: mely terjedő tanácsok nem védenek vagy akár ártanak, és mit javasol helyettük a php.net, a BSI és a szakírók.

Forrás: https://phpsos.de/hu/blog/gefaehrliche-falschtipps/  
Á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:** Sok PHP2Shell-tipp, amely éppen fórumokon és közösségi hálózatokon kering, nem véd, vagy akár árt: a session-sütit tartalmazó kérések blokkolása, a hibaüzenetek elrejtése, a beállítások `.user.ini`-vel való megadása vagy csak a CMS frissítése. A php.net egyértelmű: nincsenek teljes körű átmeneti intézkedések, az egyetlen biztos út a PHP-frissítés az összes folyamat újraindításával.

## Miért veszélyesek a téves tippek ebben a helyzetben

Egy nagy figyelmet kapó kritikus résnél piac keletkezik a gyors megoldásokra. A tanácsokat megosztják, lerövidítik és továbbadják, gyakran az eredeti forrás korlátozásai nélkül. A PHP2Shellnél ehhez jön, hogy a részletek beszámolók szerint már a hivatalos időpont előtt ismertté váltak, és a helyzet az első napokban áttekinthetetlen volt.

Egy téves tipp kétszeresen árt. Nyitva hagyja a rést, és azt az érzést kelti, hogy tettünk valamit. Éppen ez az érzés vezet oda, hogy a tényleges frissítés elmarad. Egyes tanácsok emellett megbénítják a saját weboldalt.

## Kilenc tanács ténycsekkben

Az alábbi táblázat összefoglalja, mit olvastunk az utóbbi napokban gyakran, és szembeállítja az elsődleges források állításaival.

| Terjedő tipp | Miért nem állja meg a helyét | Mi érvényes helyette |
|---|---|---|
| Az összes `PHPSESSID`-t tartalmazó kérés blokkolása | A szakírók kifejezetten elutasítják; megbénítja a bejelentkezéseket és a kosarakat | A PHP frissítése |
| A `session.upload_progress.enabled=0` elég | Szakmai beszámolók szerint nem zárja be mindkét rést | Értelmes átmeneti intézkedés, a frissítés továbbra is kötelező |
| Értékek megadása `ini_set()`-tel vagy `.user.ini`-vel | A php.net kifejezetten ellenzi | Szerveroldalon a php.ini-ben, az FPM-poolban vagy a szerverkonfigurációban |
| Hibaüzenetek elrejtése | A php.net szerint az `error_reporting`, a `display_errors` vagy a `@` nem segít | Frissítés; a hibakimenetet ettől még ne mutassa nyilvánosan |
| A memória korlátozása `RLIMIT_AS` vagy `RLIMIT_DATA` révén | A php.net figyelmeztet, hogy éppen ez válthatja ki a sebezhető helyzetet | Korlát konténeren vagy cgroupon keresztül |
| A WordPress vagy a bővítmények frissítése | A rés a PHP-értelmezőben van, nem a CMS-ben | A PHP-futtatókörnyezet frissítése |
| A Cloudflare vagy egy másik WAF elég | Védelem csak a szolgáltatáson keresztüli forgalomra; a közvetlenül elérhető szerverek nyitva maradnak | WAF kiegészítő rétegként, nem pótlásként |
| A szolgáltatás újratöltése újraindítás helyett | A Red Hat szerint a reload nem elég, a meglévő workerek megtarthatják a régi állapotot | Az összes worker teljes újraindítása |
| Javított egyenlő tiszta | Egy javítás nem távolítja el a korábban bejuttatott kártékony szoftvert | Naplók mentése október 20-tól és nyomok ellenőrzése |

## A három leggyakoribb tévedés részletesebben

### A süti tiltása

Az a tipp, hogy az összes `PHPSESSID` session-sütit tartalmazó kérést vissza kell utasítani, technikainak és határozottnak hangzik. A szakírók kifejezetten elutasítják. A gyakorlatban tönkretesz mindent, ami munkamenetet igényel: ügyfélfiókokat, kosarakat, admin területeket, hamisítás elleni védelemmel ellátott űrlapokat. A rés elleni védelem nem.

### Az az egy beállítás, amely mindent megold

A `session.upload_progress.enabled=0` benne van a php.net ajánlásaiban, és a CVE-2026-115560 ellen a megnevezett megoldás. Egyes írásokban ebből „PHP2Shell kikapcsolva” lett. Szakmai beszámolók szerint ez a beállítás önmagában azonban nem zárja be mindkét rést. A `memory_limit=-1` is a php.net szerint csak a vezérelhető kiváltó okot szünteti meg; egy mélyebb szintű memóriahiba továbbra is elérheti a sebezhető útvonalat. A PHP 8.5-ön a `fatal_error_backtraces=0` a php.net szerint csak a visszakövetéseken keresztüli megerősített utat blokkolja.

Hogy hogyan állítsa be mégis helyesen és tartósan a beállítást, azt a [session.upload_progress kikapcsolása](https://phpsos.de/hu/blog/session-upload-progress-abschalten/) írás írja le. Az átmeneti intézkedések teljes listája az [Azonnali intézkedések javítás nélkül](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon található.

### A védőpajzs előtte

A Cloudflare saját közlése szerint október 21. óta aktív védelmi szabályokkal rendelkezik, az ingyenes csomagban lévő ügyfeleknek is. A Cloudflare maga is rámutat azonban a korlátokra: a védelem csak a Cloudflare-en keresztül haladó forgalomra érvényesül. Ha az eredeti szerver közvetlenül elérhető, megkerülik. Ezenkívül a Cloudflare a szerver válaszát is vizsgálja, mert a kérés önmagában nem mindig elég. Hogy a WAF miért nem helyettesíti a frissítést, azt a [WAF vagy frissítés](https://phpsos.de/hu/blog/waf-oder-update/) írás magyarázza.

## Egy kockázatos tipp: a feltöltési kérések szűrése a peremen

Nem minden kényelmetlen tanács téves. A szakírók átmeneti, nem hivatalos intézkedésként azt javasolják, hogy a valódi feltöltési útvonalakon kívüli `multipart/form-data` kéréseket blokkolják a proxynál vagy a WAF-ban. Ez csökkentheti a támadási felületet, de tönkreteszi az űrlapokat és a feltöltéseket, ha az engedélyezett útvonalak listája hiányos.

Aki ezt az utat választja, előtte tesztkörnyezetben ellenőrizze, egyeztesse a szakosztályokkal, és határidős intézkedésként dokumentálja. Ez sem helyettesíti a frissítést.

Sok WAF-megoldás kínál erre megfigyelési módot, amelyben a szabályok eleinte csak naplóznak blokkolás helyett. Hagyjon egy új szabályt néhány napig így futni, és értékelje ki, mely jogos kérések lennének érintettek. Csak utána váltson blokkolásra. Így elkerüli, hogy a jelentkezési űrlapok, az ügyfélportálok vagy a webshop képfeltöltése észrevétlenül kiessen.

## Így ellenőrizzen egy tippet, mielőtt végrehajtja

Négy kérdés választja szét a használható tanácsokat a veszélyesektől:

1. **Forrás:** A php.net-től, a disztribúciójától, a BSI-től vagy egy néven nevezett szakírótól származik az ajánlás?
2. **Állítás:** Az intézkedést átmenetként vagy megoldásként írják le? A PHP2Shellnél csak a frissítés megoldás.
3. **Mellékhatás:** Mi romlik el, ha az intézkedés érvényesül? A mellékhatásokra utalás nélküli tipp hiányos.
4. **A végrehajtás helye:** A beállítást szerveroldalon és felülírhatatlanul adják meg, az összes worker újraindításával?

> **Fontos:**
> Rögzítse, mikor mely átmeneti intézkedéseket állította be. Így később célzottan ellenőrizheti őket, és felismerheti, ha egy vélt védelem késleltette a tényleges frissítést.

## Hogyan segít konkrétan a PHP SOS?

- Ellenőrizzük azokat az intézkedéseket, amelyeket Önnél már végrehajtottak, és szétválasztjuk a hatékonyakat a hatástalanoktól.
- Telepítjük a PHP-frissítést, újraindítunk minden folyamatot, és igazoljuk az állapotot.
- Ahol a frissítés még nem lehetséges, a php.net szerinti átmeneti intézkedéseket szerveroldalon és dokumentáltan alkalmazzuk.
- A [WAF és virtuális javítás](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) szolgáltatással kiegészítjük a védelmet a peremen, a frissítés helyettesítése nélkül.


## Gyakori kérdések

**Véd, ha blokkolom a PHPSESSID-t tartalmazó kéréseket?**  
Nem. A szakírók kifejezetten elutasítják ezt a terjedő tippet. Megbénítja a bejelentkezéseket, a kosarakat és az űrlapokat, anélkül hogy bezárná az értelmezőben lévő rést.

**Elég a session.upload_progress.enabled=0 a PHP2Shell ellen?**  
Nem. A beállítás az egyik átmeneti intézkedés a több közül, és szakmai beszámolók szerint nem zárja be mindkét rést. Értelmes, de nem helyettesíti a PHP-frissítést.

**Segít, ha kikapcsolom a display_errors-t?**  
A PHP2Shell ellen nem. A php.net rámutat, hogy a diagnosztika elrejtése az error_reporting, a display_errors vagy a @ operátor révén nem segít. Éles környezetben a display_errors-nak más okokból mégis ki kell lennie kapcsolva.

**Miből ismerem fel a komoly tippet?**  
Egy komoly tipp megnevezi a forrását, leírja a korlátait, és az átmeneti intézkedéseket annak nevezi. Aki azt ígéri, hogy egyetlen beállítás szükségtelenné teszi a frissítést, téved a PHP2Shell esetében.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [Red Hat: CVE-2026-109618](https://access.redhat.com/security/cve/CVE-2026-109618)
- [Dr. Web: PHP2Shell és PHP-verziók](https://www.drweb.de/php2shell-update-php-versionen/)
- [Cloudflare-blog](https://blog.cloudflare.com/)