Kort gezegd: memory_limit bepaalt hoeveel geheugen een afzonderlijk PHP-verzoek mag innemen; standaard is dat 128M. In normaal bedrijf stelt u een eindige waarde in die bij de applicatie past en vergrendelt u die met php_admin_value. Zolang PHP2Shell niet is gepatcht, adviseert php.net tijdelijk memory_limit=-1, niet overschrijfbaar en gecombineerd met een grens via container of cgroup, niet via RLIMIT_AS of RLIMIT_DATA. Na de update geldt weer een eindige waarde.
Een routine-instelling die opeens een beveiligingsonderwerp is
Jarenlang was memory_limit een stelschroef voor ontwikkelaars. Meldt een website „Allowed memory size exhausted”, dan wordt de waarde verhoogd en is het probleem opgelost. Met PHP2Shell is dat een beveiligingsvraag geworden en het advies van php.net lijkt op het eerste gezicht paradoxaal: voor de overgang moet de eigen geheugengrens van PHP geheel vervallen.
De achtergrond is CVE-2026-109618. Volgens het PHP-project kan een out-of-memory-toestand PHP onderbreken terwijl verzoekgegevens maar deels zijn geïnitialiseerd. Het opruimen van het verzoek kan ongeldige gegevens dan als geldig behandelen. Technische details staan onder CVE-2026-109618; wat er bij geheugentekort binnenin PHP gebeurt, legt memory_limit en out-of-memory uit. Voor beheerders telt de vraag: welke waarde geldt wanneer, en waar moet ze staan?
Wat memory_limit in normaal bedrijf doet
Volgens de PHP-handleiding begrenst memory_limit het geheugen dat een script mag innemen en beschermt zo de server tegen slecht geschreven code. De standaard is 128M, -1 betekent geen grens. Verkorte schrijfwijzen als 256M of 1G zijn toegestaan.
Twee eigenschappen zijn voor de beveiliging belangrijk. Ten eerste is de waarde overal te wijzigen, ook tijdens de uitvoering met ini_set(). Veel CMS'en en webwinkels verhogen haar zelf, bijvoorbeeld voor imports of beeldverwerking. Wie een waarde wil afdwingen, moet haar instellen met php_admin_value; volgens de handleiding zijn zo ingestelde waarden niet met ini_set() te overschrijven. Ten tweede adviseert de handleiding dat memory_limit groter is dan post_max_size.
Welke waarde past, hangt van de applicatie af. Een blik in het foutenlog toont of er meldingen over uitgeput geheugen optreden en bij welke aanroepen. Het heeft zich bewezen de waarde per website in de eigen FPM-pool vast te leggen: ruimer voor een webwinkel met imports, krapper voor een eenvoudige bedrijfssite. Een algemeen zeer hoge waarde voor alle websites verspilt de beschermende werking, omdat dan één foutief of misbruikt verzoek veel geheugen kan vastleggen.
Sinds PHP 8.5 is er bovendien max_memory_limit. Deze instelling kan alleen bij het opstarten worden ingesteld en begrenst hoe hoog memory_limit maximaal mag worden gezet. Hogere waarden worden met een waarschuwing afgekapt. De standaard -1 betekent geen bovengrens.
memory_limit na PHP2Shell: de overbruggingsmaatregel van php.net
Voor servers die nog niet zijn bijgewerkt naar 8.5.12, 8.4.27, 8.3.36 of 8.2.35 of een bevestigde backport, noemt php.net in de beveiligingsmelding van 21-10-2026 de volgende stappen. Ze verkleinen het risico van afzonderlijke aanvalswegen, maar maken een installatie volgens php.net niet veilig:
memory_limit=-1instellen, bij voorkeur zo dat applicaties de waarde niet kunnen overschrijven, bijvoorbeeld metphp_admin_valuein de FPM-pool of in de Apache-configuratie.- Controleren dat nergens opnieuw een eindige grens wordt ingesteld, niet in een andere pool, niet in een mapconfiguratie en niet in de applicatie.
- Een geheugengrens via container of cgroup instellen, als bescherming van de beschikbaarheid, bij voorkeur zo dat bij overschrijding alleen de getroffen worker wordt beëindigd.
- Niet
RLIMIT_ASofRLIMIT_DATAgebruiken. Deze grenzen kunnen volgens php.net juist de kwetsbare fout bij de geheugenaanvraag uitlokken.
php.net legt daarbij uit dat -1 het gericht uit te lokken bereiken van de PHP-geheugengrens verwijdert, maar dat een geheugenfout op een lager niveau het kwetsbare pad nog steeds kan bereiken. Het overzicht van alle overbruggingsmaatregelen staat onder Noodmaatregelen als u nog niet kunt patchen.
; FPM-pool, bijv. /etc/php/8.3/fpm/pool.d/www.conf (alleen tot de update)
php_admin_value[memory_limit] = -1
# Overal waar memory_limit wordt ingesteld (alleen-lezen)
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
Hoe u de cgroup-grens voor de FPM-service instelt, beschrijft Geheugengrenzen instellen met systemd en cgroups. Zonder deze buitenste grens kan één enkel verzoek de hele server in geheugennood brengen.
Herstart na elke wijziging alle PHP-workers. Een draaiende worker behoudt zijn oude waarden.
Wat na de update geldt
Met de verholpen versies is volgens de PHP-handleiding ook het gedrag van memory_limit veranderd. Vanaf 8.5.12, 8.4.27, 8.3.36 en 8.2.35 is het een zachte grens: een geheugenaanvraag die haar overschrijdt, mag in de meeste gevallen nog worden afgerond voordat de fout wordt uitgelokt. Een nieuwe instelling, memory_hard_limit_percent, legt een harde grens vast die nooit wordt overschreden.
| Instelling | Waarde | Werking volgens de handleiding |
|---|---|---|
memory_hard_limit_percent niet ingesteld of -1 |
Standaard | harde grens twee keer zo hoog als memory_limit tot 1G, daarboven memory_limit plus 1G |
memory_hard_limit_percent = 150 |
Voorbeeld | bij memory_limit=128M harde grens 192M |
memory_limit = -1 |
geen grens | dan is er ook geen harde grens |
De handleiding noemt een praktisch controlepunt: wordt memory_hard_limit_percent niet herkend, dan is de gebruikte PHP-versie getroffen en moet ze worden bijgewerkt. Bij backports van distributies controleert u de status daarnaast via de pakketchangelog.
# Kent het FPM-binaire bestand de nieuwe instelling? (versienummer aanpassen)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
Na de update heeft memory_limit=-1 zijn doel bereikt. Keer terug naar een eindige waarde die bij de applicatie past en vergrendel die met php_admin_value. De cgroup-grens kan als extra beschermlaag blijven bestaan.
Hoe helpt PHP SOS concreet?
- Wij stellen vast waar op uw server
memory_limitwordt ingesteld en overschreven, inclusief de applicaties. - Wij voeren de overbruggingsmaatregelen van php.net op de juiste plek door en vullen aan met een cgroup-grens voor de FPM-service.
- Via de PHP-patchservice brengen wij PHP op een verholpen versie en herstarten wij alle workers.
- Daarna stellen wij weer een passende eindige waarde in en documenteren wij de instellingen.
Veelgestelde vragen
Wat is de standaardwaarde van memory_limit?
Volgens de PHP-handleiding 128M. De waarde begrenst hoeveel geheugen een afzonderlijk script mag innemen. Ze kan worden gewijzigd in php.ini, in de serverconfiguratie, in de FPM-pool en tijdens de uitvoering met ini_set(), tenzij ze met php_admin_value is vergrendeld.
Waarom adviseert php.net bij PHP2Shell memory_limit=-1?
Een van de kwetsbaarheden, CVE-2026-109618, hangt samen met de toestand bij geheugentekort. Volgens php.net verwijdert memory_limit=-1 het gericht uit te lokken bereiken van de PHP-geheugengrens, maar niet elke geheugenfout. De maatregel is geen volledige bescherming en moet worden gecombineerd met een geheugengrens via container of cgroup.
Mag ik de grens in plaats daarvan met ulimit instellen?
Nee. php.net raadt uitdrukkelijk af om RLIMIT_AS of RLIMIT_DATA als vervanging te gebruiken, omdat deze grenzen juist de kwetsbare fout bij de geheugenaanvraag kunnen uitlokken. Aanbevolen is een grens via container of cgroup.
Wat geldt na de update naar een verholpen PHP-versie?
Volgens de handleiding is memory_limit in de verholpen versies een zachte grens, aangevuld met een harde grens via memory_hard_limit_percent. De overbruggingsmaatregel met -1 heeft dan zijn doel bereikt en er moet weer een eindige, bij de applicatie passende waarde gelden.