Kurz gesagt: Für die php.ini-Sicherheit zählen vor allem vier Bereiche: keine Fehlermeldungen nach außen, sichere Session-Cookies, begrenzte Uploads und gesperrte Werte, die Anwendungen nicht überschreiben können. Nach PHP2Shell kommen die Übergangsmaßnahmen von php.net hinzu, vor allem session.upload_progress.enabled=0. Eine sichere Konfiguration ersetzt aber nie das Update.
Warum die php.ini nach PHP2Shell wieder im Blick ist
Die php.ini ist die zentrale Konfigurationsdatei von PHP. Auf vielen Servern wurde sie einmal eingerichtet und danach kaum angefasst. Mit PHP2Shell hat sich das geändert: Für die beiden Lücken CVE-2026-109618 und CVE-2026-109619 nennt php.net Übergangsmaßnahmen, die genau hier ansetzen.
Die Lücken selbst stecken im PHP-Interpreter. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21.10.2026. Eine gute Konfiguration hilft dennoch auf zwei Wegen: Sie kann die Ausnutzung erschweren, und sie begrenzt den Schaden, wenn doch einmal etwas durchkommt.
Viele Betreiber wissen außerdem nicht genau, welche Einstellungen auf ihrem Server gelten. Das ist der erste Schritt.
Welche php.ini gilt auf Ihrem Server?
PHP kann je nach Betriebsart unterschiedliche Konfigurationsdateien lesen. Die Kommandozeile, PHP-FPM und Apache mit mod_php haben unter Debian und Ubuntu zum Beispiel jeweils eigene Ordner unter /etc/php/<version>/. Wer nur die CLI-Datei ändert, ändert an der Website nichts.
# Konfigurationsdateien der Kommandozeile
php --ini
# Konfiguration von PHP-FPM (Versionsnummer anpassen)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Einzelwerte von PHP-FPM prüfen
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Zusätzlich können Werte im FPM-Pool, in der Apache-Konfiguration, in .htaccess (nur mod_php) oder in .user.ini (FPM und CGI) stehen. Welche Version auf dem Server tatsächlich läuft und ob ein Backport enthalten ist, klärt der Beitrag PHP-Version und Patchstand richtig prüfen.
Grundeinstellungen für mehr php.ini-Sicherheit
Die folgenden Werte sind für die meisten Produktivserver sinnvoll. Prüfen Sie vor dem Einsatz in einer Testumgebung, ob Ihre Anwendung mit allen Werten zurechtkommt.
; Keine Versionsangabe im HTTP-Header
expose_php = Off
; Fehler protokollieren, aber nie im Browser anzeigen
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Keine Dateien von entfernten Adressen einbinden
allow_url_include = Off
; allow_url_fopen nur aktiv lassen, wenn die Anwendung es braucht
allow_url_fopen = Off
; Sessions: strikt, nur über HTTPS, nicht per JavaScript lesbar
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Laufzeit und Eingaben begrenzen
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
allow_url_fopen brauchen manche Anwendungen für Updates oder Schnittstellen. Schalten Sie es nur ab, wenn Sie das vorher geprüft haben. Funktionen, die Systembefehle ausführen, lassen sich zusätzlich sperren; wie das ohne Nebenwirkungen gelingt, erklärt der Ratgeber disable_functions richtig einsetzen.
Übergangsmaßnahmen von php.net zu PHP2Shell
Wenn Sie nicht sofort patchen können, nennt php.net mehrere Einstellungen, die das Risiko senken. Sie sind ausdrücklich kein vollständiger Schutz, sondern eine Brücke bis zum Update.
; Session-Upload-Progress abschalten (auch wegen CVE-2026-115560)
session.upload_progress.enabled = 0
; Anfragegröße begrenzen: 8M ohne Uploads, 32M mit Uploads
post_max_size = 8M
upload_max_filesize = 6M
; Nur PHP 8.5: keine Backtraces bei schweren Fehlern
fatal_error_backtraces = 0
Dazu empfiehlt php.net, memory_limit=-1 so zu setzen, dass Anwendungen den Wert nicht überschreiben können, und die Speichergrenze stattdessen über Container oder cgroup zu ziehen, nicht über RLIMIT_AS oder RLIMIT_DATA. Diese Maßnahme gehört in den FPM-Pool oder die Serverkonfiguration und sollte mit einer funktionierenden cgroup-Grenze kombiniert werden. Die vollständige Übersicht finden Sie unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
session.upload_progress.enabled=0 wirkt nur aus php.ini, FPM-Pool oder Serverkonfiguration. Über ini_set() oder .user.ini gesetzt, greift die Maßnahme nicht. Danach alle Worker neu starten.
Werte gegen Überschreiben sperren
Viele Anwendungen setzen eigene Werte, etwa für Speicher oder Uploads. Mit php_admin_value und php_admin_flag legen Sie Einstellungen so fest, dass weder ini_set() noch .user.ini sie ändern können. Im FPM-Pool sieht das so aus:
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (Auszug)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Unter Apache mit mod_php gilt dieselbe Logik mit php_admin_value und php_admin_flag in der VirtualHost-Konfiguration. Danach den Dienst neu laden und den aktiven Wert gegenprüfen:
sudo systemctl reload php8.3-fpm
# Startzeit der Prozesse: Liegt sie nach der Änderung?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Ein Reload startet die Worker von PHP-FPM neu. Nach einem PHP-Update ist dagegen ein vollständiger Neustart aller PHP-Prozesse nötig, damit kein alter Prozess im Speicher weiterläuft. Bei mehreren Websites auf einem Server lohnt außerdem ein eigener Pool je Website, mehr dazu im Ratgeber open_basedir und Isolation pro Website.
Häufige Fehler und eine kurze Prüfliste
Die meisten Probleme mit der php.ini entstehen nicht durch falsche Werte, sondern durch Werte an der falschen Stelle. Typisch ist die geänderte CLI-Datei, während die Website über PHP-FPM läuft. Ebenso häufig bleibt nach einer Änderung der Neustart aus, oder ein Hosting-Panel überschreibt die eigene Einstellung beim nächsten Speichern.
Ein zweiter Klassiker sind sichtbare Fehlermeldungen auf der Live-Website. Sie verraten Pfade, Datenbanknamen oder Versionen und erleichtern Angreifern die Orientierung. Gerade nach einem Umzug oder einer Neuinstallation steht display_errors oft wieder auf On.
Diese Punkte sollten Sie nach jeder Änderung und nach jedem PHP-Update kontrollieren:
- Welche Konfigurationsdatei liest die Web-Betriebsart, und enthält sie Ihre Werte?
- Sind
display_errorsundexpose_phpabgeschaltet, ist das Fehlerlog beschreibbar? - Steht
session.upload_progress.enabledauf0, gesetzt über php.ini oder Pool? - Sind Upload- und Anfragegrößen passend zur Anwendung begrenzt?
- Laufen alle PHP-Prozesse mit einem Startzeitpunkt nach der letzten Änderung?
Halten Sie das Ergebnis mit Datum fest. So lässt sich später belegen, wann welche Einstellung galt.
Wie hilft PHP SOS konkret?
- Wir ermitteln, welche Konfiguration in welcher Betriebsart tatsächlich aktiv ist.
- Wir setzen eine abgestimmte Grundkonfiguration und die PHP2Shell-Übergangsmaßnahmen um, getestet mit Ihrer Anwendung.
- Wir sperren sicherheitsrelevante Werte gegen Überschreiben und starten alle Worker kontrolliert neu.
- Wir dokumentieren Einstellungen und Prüfergebnis, damit spätere Änderungen nachvollziehbar bleiben.
Wie eine dauerhafte Absicherung aussieht, beschreibt die Leistung Server-Härtung für PHP-Webserver.
Häufige Fragen
Welche php.ini nutzt mein Webserver eigentlich?
Das ist oft nicht dieselbe wie auf der Kommandozeile. PHP-FPM, Apache mit mod_php und CLI haben meist eigene Konfigurationsordner. Prüfen Sie die aktive Datei deshalb über die jeweilige Betriebsart, etwa mit php-fpm -i oder einer kurzzeitig abgelegten Prüfdatei.
Ersetzt eine sichere php.ini das PHP-Update?
Nein. Die Einstellungen verkleinern die Angriffsfläche und erschweren die Ausnutzung, schließen aber keine Lücke im PHP-Interpreter. Auch die Übergangsmaßnahmen von php.net zu PHP2Shell sind ausdrücklich kein vollständiger Schutz.
Was ist der Unterschied zwischen php_value und php_admin_value?
Mit php_value gesetzte Werte kann die Anwendung zur Laufzeit wieder ändern. Werte über php_admin_value im FPM-Pool oder in der Apache-Konfiguration sind dagegen für die Anwendung gesperrt, auch für ini_set() und .user.ini.
Muss ich nach einer Änderung an der php.ini neu starten?
Ja. PHP-FPM und Apache mit mod_php lesen die Konfiguration nur beim Start. Erst nach einem Neustart oder Reload aller betroffenen Dienste gelten die neuen Werte.