Röviden: A PHP2Shell PHP-sebezhetőségre adott workaround csökkentheti a kockázatot, de a frissítést nem pótolja. A php.net erre rögzített memória- és feltöltési korlátokat, a session upload progress kikapcsolását, és PHP 8.5-ön a fatal_error_backtraces=0 értéket nevezi meg. Ha ez sem lehetséges rövid időn belül, a BSI azt ajánlja, hogy a webszervert átmenetileg vegyék le a hálózatról.
Mit tud egy workaround, és mit nem
A php.net átmeneti intézkedései azokat a feltételeket hivatottak megnehezíteni, amelyek mellett a CVE-2026-109618 és a CVE-2026-109619 rések kihasználhatók. Kifejezetten nem teljes védelem. A réseket csak a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban, vagy a szolgáltatója megerősített backportjában javították.
Az intézkedések akkor értelmesek, ha a frissítés valamilyen konkrét okból még nem megy: egy karbantartási időablak még hátravan, egy alkalmazást előbb tesztelni kell, vagy PHP 8.1-et vagy régebbit üzemeltet, amelyhez már nincs hivatalos frissítés. Ilyenkor híd, nem cél.
Ezért a workarounddal együtt a frissítést is tervezze meg: ki hajtja végre, melyik karbantartási időablakban, és ki ellenőrzi utána, hogy az összes workert újraindították? Az átmenet végdátum nélkül tartós állapottá válhat.
1. lehetőség: a szerver átmeneti levétele a hálózatról
A BSI a 3. riasztási szintet (narancs) hirdette ki, és azt ajánlja, hogy az érintett webszervereket vegyék át ideiglenesen le a hálózatról, ha a frissítés nem lehetséges azonnal. Egyes szolgáltatók elővigyázatosságból ezt megtették; ez nem jelenti azt, hogy ezeket az oldalakat feltörték.
Sok vállalkozásnak egy webshop vagy portál kiesése drága. Egy mérlegelés lehet értelmes: hozzáférés már csak VPN-en vagy engedélyezett IP-címekről, egy statikus karbantartási oldal a PHP-alkalmazás helyett, vagy a szerver egyes, nem szükséges weboldalainak kikapcsolása. Minél kevesebb PHP érhető el kívülről, annál kisebb a támadási felület.
Fontos, hogy a döntést tudatosan hozzák meg és rögzítsék: ki döntött mikor úgy, hogy a szerver online marad, és milyen védelmi intézkedésekkel? Ez később segít a biztosítóval, az adatvédelemmel és a vezetéssel szemben.
A php.net átmeneti intézkedései
| Intézkedés | Érték | Megjegyzés |
|---|---|---|
memory_limit |
-1, nem felülírható |
a memóriahatárt ilyenkor konténeren vagy cgroupon keresztül kell beállítani |
post_max_size |
8M feltöltések nélkül, 32M feltöltésekkel |
az upload_max_filesize ez alatt legyen |
| Memóriahatár | konténeren/cgroupon keresztül | nem az RLIMIT_AS vagy az RLIMIT_DATA révén |
session.upload_progress.enabled |
0 |
a php.ini-ben, a poolban vagy a szerverkonfigurációban, nem ini_set()-tel vagy .user.ini-vel |
fatal_error_backtraces |
0 |
csak PHP 8.5 |
A session.upload_progress.enabled=0 beállítás egyúttal az október 23-án jelzett CVE-2026-115560 rés megoldása is.
A PHP-sebezhetőség workaroundjának helyes beállítása
A hely a döntő. Az értékeket úgy kell beállítani, hogy az alkalmazás ne írhassa felül őket. Az útvonalak és a szolgáltatásnevek disztribúciónként eltérnek; a példák PHP 8.3-ból indulnak ki.
PHP-FPM, a poolban (pl. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; csak PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache mod_php-val, a szerverkonfigurációban vagy a VirtualHostban:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Memóriahatár cgroupon keresztül, itt systemd-vel az FPM-szolgáltatásra. Az értéket igazítsa a szerveréhez:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Ezután indítsa újra az összes workert, különben ebből semmi sem érvényesül: systemctl restart php8.3-fpm, vagy mod_php esetén az Apache. Hogyan ellenőrizheti, hogy nem fut már régi folyamat, azt a PHP-FPM és az összes worker újraindítása írja le. A konfiguráció általános keményítését a php.ini biztonságos beállítása ismerteti.
Az átállítás után tesztelje a feltöltéseket és a nagy űrlapokat. Egy túl szűk post_max_size blokkolhatja a rendeléseket, a jelentkezési űrlapokat vagy a médiafeltöltéseket. Ez is ok arra, hogy a frissítést ne halogassa sokáig.
További védelmi rétegek
Egy webalkalmazás-tűzfal vagy virtuális javítás további rétegként segíthet. A Cloudflare védelmi szabályokat vezetett be, de maga is figyelmeztet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A WAF ezért kiegészítés, nem pótlék. Többet erről a WAF és virtuális javítás oldalon talál.
Mentse emellett a szervernaplókat október 20-tól. Médiabeszámolók szerint egy első támadási kísérletet már október 17-én megfigyeltek; a naplók az alapja annak, ha később tisztázni kell, történt-e valami a javítás előtt.
Hogyan segít konkrétan a PHP SOS?
- A helyzet tisztázása: Ellenőrizzük, hogy a frissítés rövid időn belül lehetséges-e, vagy átmenet szükséges, és megbeszéljük Önnel a részek hálózatról való levételének lehetőségét.
- Az intézkedések beállítása: A php.net értékeit a helyes helyre írjuk be, beállítjuk a cgroup-korlátot, és újraindítjuk az összes workert.
- Működés tesztelése: Az átállítás után ellenőrizzük az űrlapokat, feltöltéseket és rendelési folyamatokat.
- Vezetés a javításhoz: A PHP-javítási szolgáltatáson keresztül megtervezzük a frissítést, és az átmeneti értékeket utána ellenőrzötten visszavesszük, ahol zavarnak.
Gyakori kérdések
Teljesen véd a workaround a PHP2Shell ellen?
Nem. A php.net az intézkedéseket kifejezetten átmenetinek nevezi, nem teljes védelemnek. Csökkentik a kockázatot a frissítés telepítéséig. A BSI azt ajánlja, hogy a javítás nélküli szervereket átmenetileg vegyék le a hálózatról.
Beállíthatom az értékeket .htaccess-szel vagy .user.ini-vel?
A session.upload_progress.enabled esetében a php.net kifejezetten kizárja az ini_set()-et és a .user.ini-t. A memory_limitre is igaz: az értéket úgy kell beállítani, hogy az alkalmazás ne tudja felülírni. Ez a php.ini-ben, az FPM-poolban php_admin_value-val vagy az Apache szerverkonfigurációjában sikerül.
Elég egy webalkalmazás-tűzfal workaroundként?
További rétegként segíthet. A Cloudflare védelmi szabályokat vezetett be, de maga is felhívja a figyelmet, hogy a kérésadatok alapján felállított szabályok önmagukban nem elegendők. A WAF sem a frissítést, sem a szerveren lévő átmeneti intézkedéseket nem pótolja.
Mit tegyek, ha csak megosztott tárhelyem van?
Akkor a php.ini és az újraindítás a tárhelyszolgáltatónál van. Kérdezzen rá konkrétan, hogy telepítették-e a frissítést, vagy beállították-e az átmeneti intézkedéseket, és újraindították-e az összes PHP-folyamatot.