Kurz gesagt: memory_limit legt fest, wie viel Speicher eine einzelne PHP-Anfrage belegen darf; Standard sind 128M. Im Normalbetrieb setzen Sie einen endlichen Wert, der zur Anwendung passt, und sperren ihn mit php_admin_value. Solange PHP2Shell nicht gepatcht ist, rät php.net vorübergehend zu memory_limit=-1, nicht überschreibbar und kombiniert mit einer Grenze über Container oder cgroup, nicht über RLIMIT_AS oder RLIMIT_DATA. Nach dem Update gilt wieder ein endlicher Wert.
Eine Routine-Einstellung, die plötzlich Sicherheitsthema ist
Jahrelang war memory_limit eine Stellschraube für Entwickler. Meldet eine Website „Allowed memory size exhausted“, wird der Wert erhöht, und das Problem ist erledigt. Mit PHP2Shell ist daraus eine Sicherheitsfrage geworden, und die Empfehlung von php.net wirkt auf den ersten Blick paradox: Für den Übergang soll die PHP-eigene Speichergrenze ganz entfallen.
Der Hintergrund ist CVE-2026-109618. Laut PHP-Projekt kann ein Out-of-Memory-Zustand PHP unterbrechen, während Anfragedaten nur teilweise initialisiert sind. Das Aufräumen der Anfrage kann ungültige Daten dann als gültig behandeln. Technische Einzelheiten stehen unter CVE-2026-109618, was beim Speichermangel im Inneren von PHP passiert, erklärt memory_limit und Out-of-Memory. Für Betreiber zählt die Frage: Welcher Wert gilt wann, und wo muss er stehen?
Was memory_limit im Normalbetrieb leistet
Laut PHP-Handbuch begrenzt memory_limit den Speicher, den ein Skript belegen darf, und schützt so den Server vor schlecht geschriebenem Code. Der Standard ist 128M, -1 bedeutet keine Grenze. Kurzschreibweisen wie 256M oder 1G sind erlaubt.
Zwei Eigenschaften sind für die Sicherheit wichtig. Erstens ist der Wert überall änderbar, auch zur Laufzeit per ini_set(). Viele CMS und Shops erhöhen ihn selbst, etwa für Importe oder Bildverarbeitung. Wer einen Wert erzwingen will, muss ihn mit php_admin_value setzen; laut Handbuch lassen sich so gesetzte Werte nicht per ini_set() überschreiben. Zweitens empfiehlt das Handbuch, dass memory_limit größer ist als post_max_size.
Welcher Wert passt, hängt von der Anwendung ab. Ein Blick ins Fehlerlog zeigt, ob Meldungen über erschöpften Speicher auftreten und bei welchen Aufrufen. Bewährt hat sich, den Wert je Website im eigenen FPM-Pool festzulegen: großzügiger für einen Shop mit Importen, knapper für eine einfache Unternehmensseite. Ein pauschal sehr hoher Wert für alle Websites verschenkt die Schutzwirkung, weil dann eine einzelne fehlerhafte oder missbrauchte Anfrage viel Speicher binden kann.
Seit PHP 8.5 gibt es zusätzlich max_memory_limit. Diese Einstellung kann nur beim Start gesetzt werden und begrenzt, wie hoch memory_limit überhaupt gesetzt werden darf. Höhere Werte werden mit einer Warnung gekappt. Der Standard -1 bedeutet keine Obergrenze.
memory_limit nach PHP2Shell: die Übergangsmaßnahme von php.net
Für Server, die noch nicht auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder einen bestätigten Backport aktualisiert sind, nennt php.net in der Sicherheitsmeldung vom 21.10.2026 folgende Schritte. Sie verringern das Risiko einzelner Angriffswege, machen eine Installation laut php.net aber nicht sicher:
memory_limit=-1setzen, möglichst so, dass Anwendungen den Wert nicht überschreiben können, etwa mitphp_admin_valueim FPM-Pool oder in der Apache-Konfiguration.- Prüfen, dass nirgends wieder eine endliche Grenze gesetzt wird, weder in einem anderen Pool noch in einer Verzeichniskonfiguration noch in der Anwendung.
- Eine Speichergrenze über Container oder cgroup setzen, als Schutz der Verfügbarkeit, möglichst so, dass bei Überschreitung nur der betroffene Worker beendet wird.
- Nicht
RLIMIT_ASoderRLIMIT_DATAverwenden. Diese Grenzen können laut php.net genau den verwundbaren Fehler bei der Speicheranforderung auslösen.
php.net erklärt dazu, dass -1 das gezielt auslösbare Erreichen der PHP-Speichergrenze entfernt, ein Speicherfehler auf tieferer Ebene den verwundbaren Pfad aber weiterhin erreichen kann. Die Übersicht aller Übergangsmaßnahmen steht unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
; FPM-Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf (nur bis zum Update)
php_admin_value[memory_limit] = -1
# Wo überall memory_limit gesetzt wird (nur lesend)
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
Wie Sie die cgroup-Grenze für den FPM-Dienst setzen, beschreibt Speichergrenzen mit systemd und cgroups setzen. Ohne diese äußere Grenze kann eine einzelne Anfrage den gesamten Server in Speichernot bringen.
Nach jeder Änderung alle PHP-Worker neu starten. Ein laufender Worker behält seine alten Werte.
Was nach dem Update gilt
Mit den behobenen Versionen hat sich laut PHP-Handbuch auch das Verhalten von memory_limit geändert. Ab 8.5.12, 8.4.27, 8.3.36 und 8.2.35 ist es eine weiche Grenze: Eine Speicheranforderung, die sie überschreitet, darf in den meisten Fällen noch abgeschlossen werden, bevor der Fehler ausgelöst wird. Eine neue Einstellung, memory_hard_limit_percent, legt eine harte Grenze fest, die nie überschritten wird.
| Einstellung | Wert | Wirkung laut Handbuch |
|---|---|---|
memory_hard_limit_percent nicht gesetzt oder -1 |
Standard | harte Grenze doppelt so hoch wie memory_limit bis 1G, darüber memory_limit plus 1G |
memory_hard_limit_percent = 150 |
Beispiel | bei memory_limit=128M harte Grenze 192M |
memory_limit = -1 |
keine Grenze | dann gibt es auch keine harte Grenze |
Das Handbuch nennt einen praktischen Prüfpunkt: Wird memory_hard_limit_percent nicht erkannt, ist die verwendete PHP-Version betroffen und muss aktualisiert werden. Bei Backports der Distributionen prüfen Sie den Stand zusätzlich über den Paket-Changelog.
# Kennt die FPM-Binärdatei die neue Einstellung? (Versionsnummer anpassen)
php-fpm8.3 -i | grep -E 'memory_hard_limit_percent|memory_limit'
Nach dem Update hat memory_limit=-1 seinen Zweck erfüllt. Kehren Sie zu einem endlichen Wert zurück, der zur Anwendung passt, und sperren Sie ihn mit php_admin_value. Die cgroup-Grenze kann als zusätzliche Schutzschicht bestehen bleiben.
Wie hilft PHP SOS konkret?
- Wir ermitteln, wo auf Ihrem Server
memory_limitgesetzt und überschrieben wird, einschließlich der Anwendungen. - Wir setzen die Übergangsmaßnahmen von php.net an der richtigen Stelle um und ergänzen eine cgroup-Grenze für den FPM-Dienst.
- Über den PHP-Patch-Service bringen wir PHP auf einen behobenen Stand und starten alle Worker neu.
- Danach setzen wir wieder einen passenden endlichen Wert und dokumentieren die Einstellungen.
Häufige Fragen
Was ist der Standardwert von memory_limit?
Laut PHP-Handbuch 128M. Der Wert begrenzt, wie viel Speicher ein einzelnes Skript belegen darf. Er lässt sich in php.ini, in der Serverkonfiguration, im FPM-Pool und zur Laufzeit per ini_set() ändern, sofern er nicht mit php_admin_value gesperrt ist.
Warum rät php.net bei PHP2Shell zu memory_limit=-1?
Eine der Lücken, CVE-2026-109618, hängt mit dem Zustand bei Speichermangel zusammen. Laut php.net entfernt memory_limit=-1 das gezielt auslösbare Erreichen der PHP-Speichergrenze, nicht aber jeden Speicherfehler. Die Maßnahme ist kein vollständiger Schutz und muss mit einer Speichergrenze über Container oder cgroup kombiniert werden.
Darf ich die Grenze stattdessen mit ulimit setzen?
Nein. php.net rät ausdrücklich davon ab, RLIMIT_AS oder RLIMIT_DATA als Ersatz zu verwenden, weil diese Grenzen genau den verwundbaren Fehler bei der Speicheranforderung auslösen können. Empfohlen ist eine Grenze über Container oder cgroup.
Was gilt nach dem Update auf eine behobene PHP-Version?
Laut Handbuch ist memory_limit in den behobenen Versionen eine weiche Grenze, ergänzt um eine harte Grenze über memory_hard_limit_percent. Die Übergangsmaßnahme mit -1 hat dann ihren Zweck erfüllt, und ein endlicher, zur Anwendung passender Wert sollte wieder gelten.