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 írás írja le. Az átmeneti intézkedések teljes listája az Azonnali intézkedések javítás nélkül 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 í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:
- 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?
- Á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.
- 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.
- 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?
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 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.