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 oldalon vannak, azt pedig, hogy mi történik a PHP belsejében memóriahiánykor, a memory_limit és 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:
- A
memory_limit=-1beállítása, lehetőleg úgy, hogy az alkalmazások ne tudják felülírni az értéket, például aphp_admin_value-val az FPM-poolban vagy az Apache-konfigurációban. - 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.
- 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.
- Nem használni az
RLIMIT_ASvagyRLIMIT_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 oldalon található.
; FPM-pool, pl. /etc/php/8.3/fpm/pool.d/www.conf (csak a frissítésig)
php_admin_value[memory_limit] = -1
# 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 írja le. Ez a külső határ nélkül egyetlen kérés az egész szervert memóriahiányba sodorhatja.
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.
# 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 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.