# memory_limit juist instellen

> PHP memory_limit juist instellen: wat de waarde doet, waar ze geldt, wat php.net tijdelijk adviseert voor PHP2Shell en wat na de update weer moet gelden.

Bron: https://phpsos.de/nl/blog/memory-limit-richtig-setzen/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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](https://phpsos.de/nl/php2shell/cve-2026-109618/); wat er bij geheugentekort binnenin PHP gebeurt, legt [memory_limit en out-of-memory](https://phpsos.de/nl/php/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:

1. **`memory_limit=-1` instellen,** bij voorkeur zo dat applicaties de waarde niet kunnen overschrijven, bijvoorbeeld met `php_admin_value` in de FPM-pool of in de Apache-configuratie.
2. **Controleren dat nergens opnieuw een eindige grens wordt ingesteld,** niet in een andere pool, niet in een mapconfiguratie en niet in de applicatie.
3. **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.
4. **Niet `RLIMIT_AS` of `RLIMIT_DATA` gebruiken.** 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](https://phpsos.de/nl/php2shell/sofortmassnahmen-ohne-patch/).

```ini
; FPM-pool, bijv. /etc/php/8.3/fpm/pool.d/www.conf (alleen tot de update)
php_admin_value[memory_limit] = -1
```

```bash
# 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](https://phpsos.de/nl/blog/speichergrenzen-systemd-cgroups/). Zonder deze buitenste grens kan één enkel verzoek de hele server in geheugennood brengen.

> **Belangrijk:**
> 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.

```bash
# 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_limit` wordt 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](https://phpsos.de/nl/leistungen/php-patch-service/) 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.

## Bronnen

- [php.net: beveiligingsmelding van 21-10-2026](https://www.php.net/)
- [PHP-handleiding: kerninstellingen (memory_limit)](https://www.php.net/manual/en/ini.core.php)
- [PHP-handleiding: FPM-configuratie](https://www.php.net/manual/en/install.fpm.configuration.php)
