Krótko: memory_limit określa, ile pamięci może zająć pojedyncze żądanie PHP; domyślnie jest to 128M. W normalnej pracy ustawiają Państwo skończoną wartość odpowiednią dla aplikacji i blokują ją za pomocą php_admin_value. Dopóki PHP2Shell nie jest załatany, php.net zaleca tymczasowo memory_limit=-1, bez możliwości nadpisania i w połączeniu z limitem przez kontener lub cgroup, a nie przez RLIMIT_AS czy RLIMIT_DATA. Po aktualizacji obowiązuje znów skończona wartość.
Rutynowe ustawienie, które nagle stało się kwestią bezpieczeństwa
Przez lata memory_limit był pokrętłem dla programistów. Jeśli strona zgłasza „Allowed memory size exhausted”, wartość się zwiększa i problem jest z głowy. Wraz z PHP2Shell stało się to kwestią bezpieczeństwa, a zalecenie php.net na pierwszy rzut oka wydaje się paradoksalne: na okres przejściowy ma zniknąć własny limit pamięci PHP.
Tłem jest CVE-2026-109618. Według projektu PHP stan braku pamięci (Out-of-Memory) może przerwać PHP w chwili, gdy dane żądania są zainicjowane tylko częściowo. Sprzątanie po żądaniu może wtedy traktować nieprawidłowe dane jako prawidłowe. Szczegóły techniczne znajdują się na stronie CVE-2026-109618, a co dzieje się przy braku pamięci wewnątrz PHP, wyjaśnia artykuł memory_limit i Out-of-Memory. Dla operatorów liczy się pytanie: jaka wartość obowiązuje kiedy i gdzie musi być ustawiona?
Co memory_limit robi w normalnej pracy
Według podręcznika PHP memory_limit ogranicza pamięć, jaką może zająć skrypt, i chroni w ten sposób serwer przed źle napisanym kodem. Wartość domyślna to 128M, a -1 oznacza brak limitu. Dozwolone są skróty takie jak 256M lub 1G.
Dwie właściwości są ważne dla bezpieczeństwa. Po pierwsze, wartość można zmienić wszędzie, także w czasie działania przez ini_set(). Wiele systemów CMS i sklepów samodzielnie ją zwiększa, na przykład przy importach lub przetwarzaniu obrazów. Kto chce wymusić wartość, musi ustawić ją przez php_admin_value; według podręcznika tak ustawionych wartości nie można nadpisać przez ini_set(). Po drugie, podręcznik zaleca, aby memory_limit był większy niż post_max_size.
Jaka wartość pasuje, zależy od aplikacji. Wgląd w log błędów pokazuje, czy występują komunikaty o wyczerpanej pamięci i przy jakich wywołaniach. Sprawdziło się ustawianie wartości dla każdej strony w jej własnej puli FPM: hojniej dla sklepu z importami, skromniej dla prostej strony firmowej. Zbiorczo bardzo wysoka wartość dla wszystkich stron marnuje działanie ochronne, bo wtedy pojedyncze błędne lub nadużyte żądanie może związać dużo pamięci.
Od PHP 8.5 istnieje dodatkowo max_memory_limit. To ustawienie można zadać tylko przy starcie i ogranicza ono, jak wysoko w ogóle można ustawić memory_limit. Wyższe wartości są obcinane z ostrzeżeniem. Domyślne -1 oznacza brak górnej granicy.
memory_limit po PHP2Shell: środek przejściowy z php.net
Dla serwerów, które nie zostały jeszcze zaktualizowane do 8.5.12, 8.4.27, 8.3.36 lub 8.2.35 albo do potwierdzonego backportu, php.net w komunikacie bezpieczeństwa z 21.10.2026 podaje następujące kroki. Zmniejszają one ryzyko poszczególnych dróg ataku, ale według php.net nie czynią instalacji bezpieczną:
- Ustawić
memory_limit=-1, możliwie tak, aby aplikacje nie mogły nadpisać wartości, na przykład przezphp_admin_valuew puli FPM lub w konfiguracji Apache. - Sprawdzić, że nigdzie nie ustawiono ponownie skończonego limitu, ani w innej puli, ani w konfiguracji katalogu, ani w aplikacji.
- Ustawić limit pamięci przez kontener lub cgroup, jako ochronę dostępności, możliwie tak, aby przy przekroczeniu zakończony został tylko dotknięty proces roboczy.
- Nie używać
RLIMIT_ASaniRLIMIT_DATA. Według php.net te limity mogą wywołać właśnie podatny błąd przy żądaniu pamięci.
php.net wyjaśnia przy tym, że -1 usuwa możliwość celowego wywołania osiągnięcia limitu pamięci PHP, ale błąd pamięci na głębszym poziomie nadal może dotrzeć do podatnej ścieżki. Przegląd wszystkich środków przejściowych znajduje się na stronie Środki doraźne, gdy nie mogą Państwo jeszcze załatać.
; Pula FPM, np. /etc/php/8.3/fpm/pool.d/www.conf (tylko do aktualizacji)
php_admin_value[memory_limit] = -1
# Gdzie wszędzie ustawiany jest memory_limit (tylko odczyt)
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
Jak ustawić limit cgroup dla usługi FPM, opisuje artykuł Ustawianie limitów pamięci za pomocą systemd i cgroups. Bez tego zewnętrznego limitu pojedyncze żądanie może doprowadzić cały serwer do braku pamięci.
Po każdej zmianie zrestartować wszystkie procesy robocze PHP. Działający proces roboczy zachowuje swoje stare wartości.
Co obowiązuje po aktualizacji
Wraz z naprawionymi wersjami zmieniło się według podręcznika PHP także zachowanie memory_limit. Od 8.5.12, 8.4.27, 8.3.36 i 8.2.35 jest to limit miękki: żądanie pamięci, które go przekracza, może w większości przypadków zostać jeszcze zakończone, zanim zostanie wywołany błąd. Nowe ustawienie, memory_hard_limit_percent, określa limit twardy, który nigdy nie jest przekraczany.
| Ustawienie | Wartość | Działanie według podręcznika |
|---|---|---|
memory_hard_limit_percent nieustawione lub -1 |
domyślnie | limit twardy dwa razy wyższy niż memory_limit do 1G, powyżej memory_limit plus 1G |
memory_hard_limit_percent = 150 |
przykład | przy memory_limit=128M limit twardy 192M |
memory_limit = -1 |
brak limitu | wtedy nie ma też limitu twardego |
Podręcznik podaje praktyczny punkt kontrolny: jeśli memory_hard_limit_percent nie jest rozpoznawane, używana wersja PHP jest dotknięta i wymaga aktualizacji. W przypadku backportów dystrybucji stan należy dodatkowo sprawdzić w changelogu pakietu.
# Czy plik binarny FPM zna nowe ustawienie? (dopasować numer wersji)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
Po aktualizacji memory_limit=-1 spełnił swoje zadanie. Proszę wrócić do skończonej wartości odpowiedniej dla aplikacji i zablokować ją przez php_admin_value. Limit cgroup może pozostać jako dodatkowa warstwa ochrony.
Jak konkretnie pomaga PHP SOS?
- Ustalamy, gdzie na Państwa serwerze ustawiany i nadpisywany jest
memory_limit, łącznie z aplikacjami. - Wdrażamy środki przejściowe z php.net we właściwym miejscu i uzupełniamy je o limit cgroup dla usługi FPM.
- Za pośrednictwem usługi poprawek PHP doprowadzamy PHP do naprawionej wersji i restartujemy wszystkie procesy robocze.
- Następnie ustawiamy ponownie odpowiednią skończoną wartość i dokumentujemy ustawienia.
Częste pytania
Jaka jest domyślna wartość memory_limit?
Według podręcznika PHP 128M. Wartość ogranicza, ile pamięci może zająć pojedynczy skrypt. Można ją zmienić w php.ini, w konfiguracji serwera, w puli FPM i w czasie działania przez ini_set(), o ile nie jest zablokowana przez php_admin_value.
Dlaczego php.net zaleca przy PHP2Shell memory_limit=-1?
Jedna z luk, CVE-2026-109618, wiąże się ze stanem przy braku pamięci. Według php.net memory_limit=-1 usuwa możliwość celowego wywołania osiągnięcia limitu pamięci PHP, ale nie każdy błąd pamięci. Ten środek nie jest pełną ochroną i trzeba go połączyć z limitem pamięci przez kontener lub cgroup.
Czy mogę zamiast tego ustawić limit za pomocą ulimit?
Nie. php.net wyraźnie odradza używanie RLIMIT_AS lub RLIMIT_DATA jako zamiennika, ponieważ te limity mogą wywołać właśnie podatny błąd przy żądaniu pamięci. Zalecany jest limit przez kontener lub cgroup.
Co obowiązuje po aktualizacji do naprawionej wersji PHP?
Według podręcznika w naprawionych wersjach memory_limit jest limitem miękkim, uzupełnionym twardym limitem przez memory_hard_limit_percent. Środek przejściowy z -1 spełnił wtedy swoje zadanie i ponownie powinna obowiązywać skończona wartość odpowiednia dla aplikacji.