Pe scurt: memory_limit stabilește cât de multă memorie poate ocupa o singură cerere PHP; valoarea implicită este 128M. În funcționarea normală stabiliți o valoare finită, potrivită aplicației, și o blocați cu php_admin_value. Cât timp PHP2Shell nu este remediat, php.net recomandă provizoriu memory_limit=-1, care să nu poată fi suprascris și combinat cu o limită prin container sau cgroup, nu prin RLIMIT_AS sau RLIMIT_DATA. După actualizare se aplică din nou o valoare finită.
O setare de rutină care a devenit brusc o temă de securitate
Ani la rând, memory_limit a fost un șurub de reglaj pentru dezvoltatori. Dacă un site raportează „Allowed memory size exhausted”, valoarea se mărește și problema e rezolvată. Odată cu PHP2Shell, aceasta a devenit o chestiune de securitate, iar recomandarea php.net pare la prima vedere paradoxală: pentru perioada de tranziție, limita proprie de memorie a PHP ar trebui să dispară cu totul.
Fundalul este CVE-2026-109618. Potrivit proiectului PHP, o stare de Out-of-Memory poate întrerupe PHP în timp ce datele cererii sunt inițializate doar parțial. Curățarea cererii poate trata atunci date invalide drept valide. Detaliile tehnice se găsesc la CVE-2026-109618, iar ce se petrece în interiorul PHP la lipsa de memorie explică memory_limit și Out-of-Memory. Pentru operatori contează întrebarea: ce valoare se aplică când și unde trebuie să fie stabilită?
Ce face memory_limit în funcționarea normală
Potrivit manualului PHP, memory_limit limitează memoria pe care o poate ocupa un script și protejează astfel serverul împotriva codului prost scris. Valoarea implicită este 128M, iar -1 înseamnă fără limită. Notațiile scurte precum 256M sau 1G sunt permise.
Două caracteristici sunt importante pentru securitate. În primul rând, valoarea poate fi modificată peste tot, inclusiv în timpul execuției prin ini_set(). Multe CMS-uri și magazine o măresc singure, de exemplu pentru importuri sau procesarea imaginilor. Cine vrea să impună o valoare trebuie să o stabilească cu php_admin_value; potrivit manualului, valorile stabilite astfel nu pot fi suprascrise prin ini_set(). În al doilea rând, manualul recomandă ca memory_limit să fie mai mare decât post_max_size.
Ce valoare se potrivește depinde de aplicație. O privire în jurnalul de erori arată dacă apar mesaje despre memorie epuizată și la ce apelări. S-a dovedit eficient să stabiliți valoarea pentru fiecare site în propriul pool FPM: mai generoasă pentru un magazin cu importuri, mai strânsă pentru un site simplu de firmă. O valoare general foarte mare pentru toate site-urile irosește efectul de protecție, pentru că atunci o singură cerere defectuoasă sau abuzată poate lega multă memorie.
Începând cu PHP 8.5 există suplimentar max_memory_limit. Această setare poate fi stabilită doar la pornire și limitează cât de sus poate fi stabilit memory_limit. Valorile mai mari sunt reduse printr-un avertisment. Valoarea implicită -1 înseamnă fără limită superioară.
memory_limit după PHP2Shell: măsura provizorie de la php.net
Pentru serverele care nu sunt încă actualizate la 8.5.12, 8.4.27, 8.3.36 sau 8.2.35 ori la un backport confirmat, php.net indică în anunțul de securitate din 21.10.2026 următorii pași. Ei reduc riscul unor căi de atac individuale, dar, potrivit php.net, nu fac o instalare sigură:
- Stabiliți
memory_limit=-1, pe cât posibil astfel încât aplicațiile să nu poată suprascrie valoarea, de exemplu cuphp_admin_valueîn pool-ul FPM sau în configurația Apache. - Verificați că nicăieri nu se stabilește din nou o limită finită, nici în alt pool, nici într-o configurație pe director, nici în aplicație.
- Stabiliți o limită de memorie prin container sau cgroup, ca protecție a disponibilității, pe cât posibil astfel încât la depășire să fie încheiat doar workerul afectat.
- Nu folosiți
RLIMIT_ASsauRLIMIT_DATA. Potrivit php.net, aceste limite pot declanșa tocmai eroarea vulnerabilă la solicitarea de memorie.
php.net explică în acest context că -1 elimină atingerea țintită a limitei de memorie PHP, dar că o eroare de memorie de la un nivel mai profund poate totuși ajunge pe calea vulnerabilă. Prezentarea tuturor măsurilor provizorii se află la Măsuri imediate dacă nu puteți încă aplica patchul.
; Pool FPM, de ex. /etc/php/8.3/fpm/pool.d/www.conf (doar până la actualizare)
php_admin_value[memory_limit] = -1
# Unde este stabilit memory_limit peste tot (doar citire)
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
Cum stabiliți limita cgroup pentru serviciul FPM descrie Stabilirea limitelor de memorie cu systemd și cgroups. Fără această limită exterioară, o singură cerere poate aduce întregul server în lipsă de memorie.
După fiecare modificare reporniți toți workerii PHP. Un worker în execuție își păstrează valorile vechi.
Ce se aplică după actualizare
Odată cu versiunile corectate, potrivit manualului PHP, s-a schimbat și comportamentul lui memory_limit. Începând cu 8.5.12, 8.4.27, 8.3.36 și 8.2.35, aceasta este o limită flexibilă: o solicitare de memorie care o depășește poate fi, în majoritatea cazurilor, încă finalizată înainte ca eroarea să fie declanșată. O setare nouă, memory_hard_limit_percent, stabilește o limită fermă, care nu este niciodată depășită.
| Setare | Valoare | Efect conform manualului |
|---|---|---|
memory_hard_limit_percent nesetat sau -1 |
implicit | limită fermă de două ori mai mare decât memory_limit până la 1G, peste aceasta memory_limit plus 1G |
memory_hard_limit_percent = 150 |
exemplu | la memory_limit=128M, limita fermă este 192M |
memory_limit = -1 |
fără limită | atunci nu există nici limită fermă |
Manualul indică un punct practic de verificare: dacă memory_hard_limit_percent nu este recunoscut, versiunea PHP folosită este afectată și trebuie actualizată. La backporturile distribuțiilor, verificați suplimentar starea prin changelog-ul pachetului.
# Cunoaște binarul FPM noua setare? (adaptați numărul de versiune)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
După actualizare, memory_limit=-1 și-a atins scopul. Reveniți la o valoare finită, potrivită aplicației, și blocați-o cu php_admin_value. Limita cgroup poate rămâne ca strat suplimentar de protecție.
Cum ajută PHP SOS concret?
- Stabilim unde este setat și suprascris
memory_limitpe serverul dumneavoastră, inclusiv în aplicații. - Aplicăm măsurile provizorii de la php.net în locul corect și adăugăm o limită cgroup pentru serviciul FPM.
- Prin serviciul de patchuri PHP aducem PHP la o versiune corectată și repornim toți workerii.
- Apoi stabilim din nou o valoare finită potrivită și documentăm setările.
Întrebări frecvente
Care este valoarea implicită a memory_limit?
Potrivit manualului PHP, 128M. Valoarea limitează cât de multă memorie poate ocupa un singur script. Poate fi modificată în php.ini, în configurația serverului, în pool-ul FPM și în timpul execuției prin ini_set(), dacă nu a fost blocată cu php_admin_value.
De ce recomandă php.net, la PHP2Shell, memory_limit=-1?
Una dintre vulnerabilități, CVE-2026-109618, este legată de starea de lipsă de memorie. Potrivit php.net, memory_limit=-1 elimină atingerea țintită a limitei de memorie PHP, dar nu orice eroare de memorie. Măsura nu este o protecție completă și trebuie combinată cu o limită de memorie prin container sau cgroup.
Pot stabili în schimb limita cu ulimit?
Nu. php.net descurajează explicit folosirea RLIMIT_AS sau RLIMIT_DATA ca înlocuitor, deoarece aceste limite pot declanșa tocmai eroarea vulnerabilă la solicitarea de memorie. Se recomandă o limită prin container sau cgroup.
Ce se aplică după actualizarea la o versiune PHP corectată?
Potrivit manualului, în versiunile corectate memory_limit este o limită flexibilă, completată de o limită fermă prin memory_hard_limit_percent. Măsura provizorie cu -1 și-a atins atunci scopul, iar ar trebui să se aplice din nou o valoare finită, potrivită aplicației.