# A memory_limit helyes beállítása

> PHP memory_limit helyes beállítása: mit jelent az érték, mit javasol átmenetileg a php.net a PHP2Shell ellen, és mi legyen érvényes a frissítés után.

Forrás: https://phpsos.de/hu/blog/memory-limit-richtig-setzen/  
Á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 `memory_limit` meghatározza, mennyi memóriát foglalhat egyetlen PHP-kérés; az alapértelmezés 128M. Normál üzemben egy véges, az alkalmazáshoz illő értéket állítson be, és zárolja a `php_admin_value`-val. Amíg a PHP2Shell nincs javítva, a php.net átmenetileg a `memory_limit=-1` beállítást javasolja, felülírhatatlanul, konténeren vagy cgroupon keresztüli határral kombinálva, nem az `RLIMIT_AS` vagy `RLIMIT_DATA` útján. A frissítés után ismét véges érték érvényes.

## Egy rutinbeállítás, amely hirtelen biztonsági téma lett

Éveken át a `memory_limit` a fejlesztők hangolócsavarja volt. Ha egy weboldal „Allowed memory size exhausted” hibát jelez, megemelik az értéket, és a probléma elintézve. A PHP2Shellel biztonsági kérdéssé vált, és a php.net javaslata első pillantásra paradoxnak tűnik: az átmenetre a PHP saját memóriahatárának teljesen el kell esnie.

A háttér a CVE-2026-109618. A PHP-projekt szerint egy Out-of-Memory állapot megszakíthatja a PHP-t, miközben a kéréseket leíró adatok csak részben vannak inicializálva. A kérés felszámolása ilyenkor érvénytelen adatokat kezelhet érvényesként. A technikai részletek a [CVE-2026-109618](https://phpsos.de/hu/php2shell/cve-2026-109618/) oldalon vannak, azt pedig, hogy mi történik a PHP belsejében memóriahiánykor, a [memory_limit és Out-of-Memory](https://phpsos.de/hu/php/out-of-memory/) magyarázza. Az üzemeltetők számára a kérdés: melyik érték mikor érvényes, és hol kell lennie?

## Mit nyújt a memory_limit normál üzemben

A PHP kézikönyve szerint a `memory_limit` korlátozza a szkript által foglalható memóriát, és így védi a szervert a rosszul megírt kódtól. Az alapértelmezés `128M`, a `-1` határ nélkülit jelent. Rövid írásmódok, például `256M` vagy `1G`, megengedettek.

Két tulajdonság fontos a biztonság szempontjából. Először: az érték mindenhol módosítható, futásidőben az `ini_set()`-tel is. Sok CMS és webshop maga emeli meg, például importokhoz vagy képfeldolgozáshoz. Aki egy értéket ki akar kényszeríteni, azt a `php_admin_value`-val állítsa be; a kézikönyv szerint az így beállított értékek nem írhatók felül az `ini_set()`-tel. Másodszor: a kézikönyv azt javasolja, hogy a `memory_limit` nagyobb legyen a `post_max_size`-nál.

Hogy melyik érték illik, az az alkalmazástól függ. A hibanaplóba pillantva kiderül, előfordulnak-e kimerült memóriára utaló üzenetek, és melyik meghívásoknál. Bevált, ha az értéket weboldalanként a saját FPM-poolban rögzítik: nagyvonalúbban egy importokat végző webshopnál, szűkebben egy egyszerű cégoldalnál. Az összes weboldalra általánosan nagyon magas érték elveszi a védő hatást, mert ekkor egyetlen hibás vagy visszaélésszerű kérés sok memóriát köthet le.

A PHP 8.5 óta emellett létezik a `max_memory_limit`. Ez a beállítás csak indításkor állítható be, és korlátozza, hogy a `memory_limit` egyáltalán milyen magasra állítható. A magasabb értékeket figyelmeztetéssel levágják. Az alapértelmezett `-1` felső határ nélkülit jelent.

## memory_limit a PHP2Shell után: a php.net átmeneti intézkedése

Azoknak a szervereknek, amelyek még nincsenek frissítve a 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, illetve egy megerősített backportra, a php.net a 2026. 10. 21-i biztonsági közleményben a következő lépéseket nevezi meg. Csökkentik az egyes támadási utak kockázatát, de a php.net szerint nem teszik biztonságossá a telepítést:

1. **A `memory_limit=-1` beállítása,** lehetőleg úgy, hogy az alkalmazások ne tudják felülírni az értéket, például a `php_admin_value`-val az FPM-poolban vagy az Apache-konfigurációban.
2. **Ellenőrizni, hogy sehol sem állítanak be újra véges határt,** sem egy másik poolban, sem egy könyvtárkonfigurációban, sem az alkalmazásban.
3. **Konténeren vagy cgroupon keresztüli memóriahatár beállítása,** a rendelkezésre állás védelmeként, lehetőleg úgy, hogy túllépéskor csak az érintett workert állítsák le.
4. **Nem használni az `RLIMIT_AS` vagy `RLIMIT_DATA` értéket.** Ezek a határok a php.net szerint éppen a memóriafoglalás sebezhető hibáját válthatják ki.

A php.net ehhez azt magyarázza, hogy a `-1` eltávolítja a PHP memóriahatárának célzottan kiváltható elérését, egy mélyebb szintű memóriahiba viszont továbbra is elérheti a sebezhető útvonalat. Az összes átmeneti intézkedés áttekintése a [Azonnali intézkedések, ha még nem tud javítani](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon található.

```ini
; FPM-pool, pl. /etc/php/8.3/fpm/pool.d/www.conf (csak a frissítésig)
php_admin_value[memory_limit] = -1
```

```bash
# Hol állítják be mindenhol a memory_limit értékét (csak olvasás)
grep -rn 'memory_limit' /etc/php/ /etc/apache2/ 2>/dev/null
grep -rn --include='*.php' -E "ini_set\s*\(\s*['\"]memory_limit" /var/www | head -20
grep -rn --include='.user.ini' 'memory_limit' /var/www
```

Hogyan állítsa be a cgroup-határt az FPM-szolgáltatáshoz, azt a [Memóriahatárok beállítása systemd-vel és cgroupokkal](https://phpsos.de/hu/blog/speichergrenzen-systemd-cgroups/) írja le. Ez a külső határ nélkül egyetlen kérés az egész szervert memóriahiányba sodorhatja.

> **Fontos:**
> Minden módosítás után indítsa újra az összes PHP-workert. Egy futó worker megtartja a régi értékeit.

## Mi érvényes a frissítés után

A javított verziókkal a PHP kézikönyve szerint a `memory_limit` viselkedése is megváltozott. A 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziótól kezdve lágy határ: egy memóriakérést, amely túllépi, a legtöbb esetben még le szabad zárni, mielőtt a hibát kiváltják. Egy új beállítás, a `memory_hard_limit_percent`, kemény határt rögzít, amelyet soha nem lépnek túl.

| Beállítás | Érték | Hatás a kézikönyv szerint |
|---|---|---|
| `memory_hard_limit_percent` nincs beállítva vagy `-1` | alapértelmezés | a kemény határ 1G-ig kétszer olyan magas, mint a `memory_limit`, afölött a `memory_limit` plusz 1G |
| `memory_hard_limit_percent = 150` | példa | `memory_limit=128M` esetén a kemény határ 192M |
| `memory_limit = -1` | nincs határ | ekkor kemény határ sincs |

A kézikönyv egy gyakorlati ellenőrzési pontot nevez meg: ha a `memory_hard_limit_percent` beállítást nem ismeri fel, a használt PHP-verzió érintett, és frissíteni kell. A disztribúciók backportjainál az állapotot ezenkívül a csomag changelogján keresztül ellenőrizze.

```bash
# Ismeri az FPM bináris az új beállítást? (a verziószámot igazítsa)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
```

A frissítés után a `memory_limit=-1` betöltötte a célját. Térjen vissza egy véges, az alkalmazáshoz illő értékre, és zárolja a `php_admin_value`-val. A cgroup-határ kiegészítő védelmi rétegként megmaradhat.

## Hogyan segít konkrétan a PHP SOS?

- Megállapítjuk, hol állítják be és írják felül a `memory_limit` értékét a szerverén, az alkalmazásokat is beleértve.
- A php.net átmeneti intézkedéseit a megfelelő helyen valósítjuk meg, és kiegészítjük egy cgroup-határral az FPM-szolgáltatáshoz.
- A [PHP-javítási szolgáltatáson](https://phpsos.de/hu/leistungen/php-patch-service/) keresztül a PHP-t javított állapotra hozzuk, és újraindítjuk az összes workert.
- Ezután ismét megfelelő véges értéket állítunk be, és dokumentáljuk a beállításokat.


## Gyakori kérdések

**Mi a memory_limit alapértelmezett értéke?**  
A PHP kézikönyve szerint 128M. Az érték korlátozza, mennyi memóriát foglalhat egyetlen szkript. A php.ini-ben, a szerverkonfigurációban, az FPM-poolban és futásidőben az ini_set()-tel módosítható, ha nem zárolták a php_admin_value-val.

**Miért javasolja a php.net a PHP2Shellnél a memory_limit=-1 beállítást?**  
Az egyik rés, a CVE-2026-109618, a memóriahiányos állapottal függ össze. A php.net szerint a memory_limit=-1 eltávolítja a PHP memóriahatárának célzottan kiváltható elérését, de nem minden memóriahibát. Az intézkedés nem teljes védelem, és konténeren vagy cgroupon keresztüli memóriahatárral kell kombinálni.

**Beállíthatom helyette a határt ulimit-tel?**  
Nem. A php.net kifejezetten óv attól, hogy az RLIMIT_AS vagy RLIMIT_DATA értékét használják helyettesítésként, mert ezek a határok éppen a memóriafoglalás sebezhető hibáját válthatják ki. A konténeren vagy cgroupon keresztüli határ ajánlott.

**Mi érvényes a javított PHP-verzióra való frissítés után?**  
A kézikönyv szerint a memory_limit a javított verziókban lágy határ, amelyet a memory_hard_limit_percent útján kemény határ egészít ki. A -1-es átmeneti intézkedés ekkor betöltötte a célját, és ismét egy véges, az alkalmazáshoz illő értéknek kell érvényesnek lennie.

## Források

- [php.net: 2026. 10. 21-i biztonsági közlemény](https://www.php.net/)
- [PHP kézikönyv: alapbeállítások (memory_limit)](https://www.php.net/manual/en/ini.core.php)
- [PHP kézikönyv: FPM-konfiguráció](https://www.php.net/manual/en/install.fpm.configuration.php)
