# Azonnali intézkedések, ha még nem tud javítani

> Workaround a PHP2Shell PHP-sebezhetőségre: a php.net átmeneti intézkedései helyesen beállítva, a korlátokkal és tudnivalókkal a javításhoz vezető úton.

Forrás: https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/  
Á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 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](https://phpsos.de/hu/php2shell/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`):

```ini
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:

```apache
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:

```ini
# 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](https://phpsos.de/hu/php2shell/php-fpm-neustart/) írja le. A konfiguráció általános keményítését a [php.ini biztonságos beállítása](https://phpsos.de/hu/ratgeber/php-ini-sicher-konfigurieren/) ismerteti.

> **Fontos:**
> 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](https://phpsos.de/hu/leistungen/waf-virtuelles-patching/) 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](https://phpsos.de/hu/leistungen/php-patch-service/) 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)