Kurz gesagt: post_max_size begrenzt die gesamte Größe einer POST-Anfrage, upload_max_filesize die einzelne Datei; Standard sind laut PHP-Handbuch 8M und 2M. Die Werte müssen zu den Grenzen im Webserver und in der Anwendung passen, sonst scheitern Uploads ohne klare Meldung. Bis zum PHP2Shell-Update rät php.net zu post_max_size = 8M ohne Uploads oder 32M mit Uploads, upload_max_filesize darunter, gesetzt so, dass Anwendungen es nicht überschreiben.
Wenn das Bewerbungsformular plötzlich schweigt
Nach den Übergangsmaßnahmen zu PHP2Shell haben viele Admins post_max_size gesenkt. Wenige Tage später meldet die Personalabteilung, dass Bewerbungen nicht mehr ankommen. Das Formular lädt einfach neu, eine Fehlermeldung gibt es nicht. Der Grund: Die Anfrage mit drei PDF-Anhängen war größer als die neue Grenze, und PHP hat die Formulardaten verworfen.
Das Beispiel zeigt das Grundproblem. Upload-Grenzen wirken an mehreren Stellen gleichzeitig, und jede Stelle reagiert anders, wenn sie überschritten wird. Wer die Kette kennt, kann die Werte so setzen, dass sie schützen, ohne den Betrieb zu stören. Wie PHP Uploads intern verarbeitet, erklärt Wie PHP Datei-Uploads verarbeitet; die sichere Programmierung von Upload-Funktionen beschreibt Datei-Uploads in PHP sicher umsetzen.
Die Kette der Upload-Grenzen
Eine Anfrage durchläuft mehrere Grenzen, bevor die Anwendung sie sieht. Die folgenden Angaben stammen aus den Dokumentationen von Nginx, Apache und PHP:
| Stelle | Einstellung | Standard laut Doku | Bei Überschreitung |
|---|---|---|---|
| Nginx | client_max_body_size |
1m | Fehler 413 an den Browser |
| Apache ab 2.4.54 | LimitRequestBody |
1 GiB (bis 2.4.53: unbegrenzt) | Fehlerantwort statt Verarbeitung |
| PHP | post_max_size |
8M | $_POST und $_FILES leer |
| PHP | upload_max_filesize |
2M | Datei wird mit Fehlercode abgelehnt |
| PHP | max_file_uploads |
20 | weitere Dateien werden ignoriert |
| PHP | max_input_vars |
1000 | weitere Formularfelder fehlen |
Daraus ergibt sich eine einfache Regel: upload_max_filesize kleiner als post_max_size, post_max_size kleiner als die Grenze im Webserver. Das PHP-Handbuch empfiehlt zudem, dass memory_limit im Allgemeinen größer ist als post_max_size. Während der PHP2Shell-Übergangsmaßnahme mit memory_limit=-1 übernimmt diese Rolle die Grenze über Container oder cgroup; mehr dazu unter memory_limit richtig setzen.
post_max_size nach PHP2Shell: was php.net rät
In der Sicherheitsmeldung vom 21.10.2026 nennt php.net für Server ohne Update niedrige Anfragegrenzen als eine der Übergangsmaßnahmen. Sie verringern das Risiko einzelner Angriffswege, sind aber ausdrücklich kein vollständiger Schutz:
- Ohne Datei-Uploads:
post_max_size = 8M. - Mit Datei-Uploads:
post_max_size = 32M. - In beiden Fällen:
upload_max_filesizeunterpost_max_sizehalten. - Zusätzlich erwägen: Grenzen im Webserver oder Proxy für die dekodierte Anfragegröße, die Zahl der Eingabefelder, die Zahl der Multipart-Teile, die Zahl der Kopfzeilen und die Verschachtelungstiefe. Laut php.net müssen diese Grenzen auch Anfragen ohne verwertbare
Content-Length-Angabe erfassen.
Die Werte gehören dorthin, wo Anwendungen sie nicht überschreiben können. Weil post_max_size und upload_max_filesize laut Handbuch auf Verzeichnisebene änderbar sind, könnte eine .user.ini oder bei mod_php eine .htaccess sie sonst wieder anheben:
; FPM-Pool der Website, mit Uploads (Übergang bis zum Update)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
Im Webserver ziehen Sie die Grenze knapp oberhalb, damit zu große Anfragen gar nicht erst bei PHP ankommen:
# Nginx, im server- oder location-Block
client_max_body_size 32m;
# Apache, im VirtualHost: 32 MiB in Bytes
LimitRequestBody 33554432
Danach alle PHP-Worker und den Webserver neu laden. Die Übersicht aller Übergangsmaßnahmen steht unter Sofortmaßnahmen, wenn Sie noch nicht patchen können. Ob und wie sich Upload-Anfragen zusätzlich am Proxy filtern lassen, beleuchtet Upload-Anfragen am Rand filtern.
Testen Sie nach jeder Änderung die Formulare mit den größten legitimen Anfragen: Bewerbungen mit mehreren Anhängen, Produktimporte, Bildergalerien. Ein zu knapper Wert legt Geschäftsprozesse lahm, ohne dass jemand eine Fehlermeldung sieht.
Den richtigen Wert für Ihre Website ermitteln
Statt pauschaler Werte lohnt eine kurze Bestandsaufnahme. Listen Sie alle Formulare mit Uploads auf und notieren Sie die größte legitime Datei und die höchste Zahl gleichzeitiger Dateien. Daraus ergibt sich der Bedarf: upload_max_filesize deckt die größte Einzeldatei, post_max_size die Summe aller Dateien einer Anfrage plus etwas Reserve für Formularfelder.
Liegt der Bedarf über 32M, passt er nicht zur Übergangsempfehlung von php.net. Dann ist das ein weiterer Grund, das Update vorzuziehen. Große Uploads lassen sich auch über eine eigene Subdomain mit eigenem Pool abwickeln, damit die übrige Website enge Grenzen behält.
Nach dem Update auf 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einen bestätigten Backport können Sie die Werte wieder am tatsächlichen Bedarf ausrichten. Großzügiger als nötig sollten sie trotzdem nicht sein: Jede Grenze, die über den Bedarf hinausgeht, vergrößert die Angriffsfläche ohne Nutzen. Braucht eine Website gar keine Uploads, ist file_uploads = Off die sauberste Lösung.
Fehlerbilder richtig deuten
Wenn Uploads scheitern, verrät das Verhalten, welche Grenze greift. Eine Seite mit Fehler 413 stammt vom Webserver. Ein Formular, das ohne Meldung neu lädt oder „ungültige Anfrage“ meldet, deutet auf leere $_POST-Daten, also post_max_size. Eine Meldung der Anwendung zu einer einzelnen Datei passt zu upload_max_filesize. Und fehlende Felder in sehr großen Formularen, etwa bei Produktvarianten, sprechen für max_input_vars. Das PHP-Fehlerlog enthält bei überschrittenem post_max_size in der Regel eine Warnung mit der Größe der Anfrage.
Damit Nutzer nicht ratlos zurückbleiben, sollte die Anwendung den Fall erkennen. Das PHP-Handbuch schlägt dafür einen einfachen Weg vor: Das Formular übergibt einen Marker in der Adresse, etwa ?processed=1. Kommt dieser Marker an, sind aber $_POST und $_FILES leer, war die Anfrage zu groß, und die Anwendung kann eine verständliche Meldung mit der zulässigen Größe anzeigen.
Wie hilft PHP SOS konkret?
- Wir erfassen alle Upload-Wege Ihrer Websites und ermitteln die tatsächlich nötigen Größen.
- Wir setzen Webserver-, PHP- und Pool-Grenzen stimmig und gegen Überschreiben gesperrt, einschließlich der Übergangswerte von php.net.
- Wir testen Formulare, Importe und Uploads nach der Umstellung und passen Werte gezielt an.
- Im Rahmen der Server-Härtung führen wir die Werte nach dem Update auf den dauerhaften Bedarf zurück.
Häufige Fragen
Was ist der Unterschied zwischen post_max_size und upload_max_filesize?
upload_max_filesize begrenzt die Größe einer einzelnen hochgeladenen Datei. post_max_size begrenzt die gesamten Daten einer POST-Anfrage, also alle Dateien und Formularfelder zusammen. Laut PHP-Handbuch muss post_max_size deshalb größer sein als upload_max_filesize.
Was passiert, wenn eine Anfrage größer als post_max_size ist?
Laut PHP-Handbuch sind dann $_POST und $_FILES leer. Die Anwendung erhält also gar keine Formulardaten und zeigt oft nur eine unklare Fehlermeldung oder lädt das Formular neu. Das macht diesen Fehler schwer zu erkennen.
Welche Werte empfiehlt php.net wegen PHP2Shell?
Als Übergangsmaßnahme bis zum Update: post_max_size = 8M für Anwendungen ohne Datei-Uploads, 32M für Anwendungen mit Uploads, und upload_max_filesize darunter. Das ist laut php.net kein vollständiger Schutz; nur das Update auf eine behobene PHP-Version schließt die Lücken.
Kann ich post_max_size per ini_set() im Code ändern?
Nein. Laut PHP-Handbuch ist post_max_size nur auf Verzeichnisebene änderbar, etwa in php.ini, im FPM-Pool, in .user.ini oder bei mod_php in .htaccess. Wer den Wert erzwingen will, setzt ihn mit php_admin_value, dann kann ihn auch eine .user.ini nicht überschreiben.