Kurz gesagt: open_basedir begrenzt die Verzeichnisse, auf die PHP zugreifen darf. Allein ist das nur eine zusätzliche Schranke. Wirksame Isolation pro Website entsteht erst im Zusammenspiel: eigener Systembenutzer, eigener PHP-FPM-Pool, eigener Temp-Ordner und eigene Datenbankzugänge. Dann bleibt ein Einbruch in eine Website auf diese Website begrenzt.
Warum Isolation nach PHP2Shell über den Schaden entscheidet
Auf vielen Servern laufen mehrere Websites nebeneinander: die Firmenseite, ein Shop, eine alte Kampagnenseite, bei Agenturen oft Dutzende Kundenprojekte. Häufig teilen sie sich einen Systembenutzer und einen PHP-Prozess. Wird eine davon kompromittiert, liegen alle anderen offen.
PHP2Shell macht dieses Risiko greifbar. Die Lücken CVE-2026-109618 und CVE-2026-109619 erlauben die Ausführung von Schadcode ohne Anmeldung, unabhängig vom CMS. Laut Medienberichten gab es schon am 17.10.2026 einen ersten Angriffsversuch, die Patches folgten am 21.10. Der Fix ist das Update. Ob ein Angriff in der Zeit davor eine oder zehn Websites trifft, entscheidet aber die Isolation.
Gerade bei der zweiten Lücke kommt ein weiterer Gedanke hinzu: Laut PHP-Projekt kann interner Zustand einer Anfrage in einem Worker bestehen bleiben und von einer späteren Anfrage im selben Worker genutzt werden. Getrennte Pools je Website sorgen dafür, dass sich Websites ohnehin keine Worker teilen.
Was open_basedir leistet
Mit open_basedir legen Sie eine Liste von Verzeichnissen fest. Dateifunktionen von PHP wie fopen, include oder file_get_contents verweigern dann den Zugriff auf alles außerhalb dieser Liste. Ein eingeschleustes Skript kann so nicht ohne Weiteres die Konfigurationsdateien der Nachbar-Website lesen.
Die Grenzen sind wichtig: Die Prüfung findet innerhalb von PHP statt. Programme, die außerhalb von PHP gestartet werden, unterliegen ihr nicht, und Fehler im Interpreter können sie umgehen. Deshalb gehört open_basedir immer mit gesperrten Systemfunktionen zusammen, wie im Ratgeber disable_functions richtig einsetzen beschrieben, und vor allem mit Trennung auf Ebene des Betriebssystems.
Isolation pro Website in vier Schichten
Eine belastbare Trennung baut auf mehreren Schichten auf. Jede fängt ab, was die vorherige nicht leistet.
| Schicht | Maßnahme | Wirkung |
|---|---|---|
| Betriebssystem | eigener Systembenutzer je Website | Dateien anderer Websites sind nicht lesbar |
| PHP-Prozesse | eigener PHP-FPM-Pool mit eigenem Socket | kein gemeinsamer Worker, eigene Einstellungen |
| PHP-Konfiguration | open_basedir, eigener Tmp- und Session-Ordner |
zusätzliche Schranke, keine gemeinsamen Temp-Dateien |
| Daten | eigener Datenbankbenutzer mit Rechten nur auf die eigene Datenbank | kein Zugriff auf fremde Kundendaten |
Bei hohem Schutzbedarf, etwa bei Shops mit Zahlungsabwicklung oder Portalen mit Gesundheitsdaten, kommen Container oder getrennte Server hinzu.
open_basedir im PHP-FPM-Pool konfigurieren
Das folgende Beispiel zeigt einen Pool für eine Website mit eigenem Benutzer seite1. Pfade und Versionsnummer passen Sie an Ihr System an.
; /etc/php/8.3/fpm/pool.d/seite1.conf
[seite1]
user = seite1
group = seite1
listen = /run/php/seite1.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = ondemand
pm.max_children = 10
php_admin_value[open_basedir] = /var/www/seite1/:/var/www/seite1-tmp/
php_admin_value[upload_tmp_dir] = /var/www/seite1-tmp/
php_admin_value[sys_temp_dir] = /var/www/seite1-tmp/
php_admin_value[session.save_path] = /var/www/seite1-tmp/sessions
php_admin_value[error_log] = /var/log/php/seite1.error.log
php_admin_flag[session.upload_progress.enabled] = off
Die letzte Zeile setzt die PHP2Shell-Übergangsmaßnahme von php.net gleich mit. Sie wirkt nur aus Pool, php.ini oder Serverkonfiguration, nicht über ini_set() oder .user.ini. Die Ordner legen Sie mit passenden Rechten an:
sudo useradd --system --home /var/www/seite1 --shell /usr/sbin/nologin seite1
sudo mkdir -p /var/www/seite1-tmp/sessions
sudo chown -R seite1:seite1 /var/www/seite1-tmp
sudo chmod 700 /var/www/seite1-tmp
Wie die Rechte im eigentlichen Webverzeichnis aussehen sollten, beschreibt der Ratgeber Dateirechte auf dem Webserver.
Webserver anbinden und Ergebnis prüfen
In Nginx verweist jede Website auf ihren eigenen Socket. So landet keine Anfrage im Pool einer anderen Website.
server {
server_name seite1.example;
root /var/www/seite1/public;
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/seite1.sock;
}
}
Weitere Hinweise zu dieser Kombination finden Sie unter Nginx mit PHP-FPM absichern. Nach dem Neustart prüfen Sie, ob die Pools wirklich getrennt laufen:
sudo systemctl restart php8.3-fpm
# Jeder Pool sollte unter seinem eigenen Benutzer laufen
ps -eo user,pid,cmd | grep "[p]hp-fpm: pool"
Testen Sie anschließend alle Funktionen der Website: Uploads, Bildverarbeitung, Caches, geplante Aufgaben. Fehlermeldungen mit dem Hinweis auf open_basedir restriction im Fehlerlog zeigen, welcher Pfad noch fehlt. Ergänzen Sie nur Pfade, die die Anwendung wirklich braucht, und niemals das gesamte Dateisystem.
Agenturen mit vielen Kundenseiten sollten die Pool-Konfiguration als Vorlage pflegen. So bekommt jede neue Website die Trennung automatisch, statt sie später nachrüsten zu müssen. Hintergründe für diesen Fall stehen unter Sicherheitspartner für Agenturen.
Typische Stolpersteine bei der Umstellung
Die Umstellung auf getrennte Pools ist planbar, hat aber einige wiederkehrende Fallen. Die häufigste betrifft gemeinsam genutzte Bibliotheken: Liegt etwa ein Framework oder ein Ordner mit Schriften außerhalb des Website-Verzeichnisses, muss dieser Pfad lesend in open_basedir aufgenommen werden. Besser ist es, solche Abhängigkeiten in das Projekt selbst zu holen.
Die zweite Falle sind Sessions. Wechselt der Speicherort, sind alle Besucher einmal abgemeldet, und laufende Warenkörbe gehen verloren. Planen Sie die Umstellung deshalb in einem ruhigen Zeitfenster und kündigen Sie sie intern an.
Drittens laufen geplante Aufgaben häufig über die Kommandozeile und damit unter einem anderen Benutzer als die Website. Prüfen Sie Cronjobs und Warteschlangen und lassen Sie sie unter dem neuen Website-Benutzer laufen, sonst entstehen Dateien mit falschem Eigentümer, die PHP später nicht mehr ändern darf.
Schließlich sollte jeder Pool eigene Grenzen für Prozesse und Speicher haben. Eine Website, die unter Last gerät oder angegriffen wird, kann so die anderen nicht mit in die Knie zwingen.
Wie hilft PHP SOS konkret?
- Wir erfassen, welche Websites sich heute Benutzer, Prozesse und Datenbanken teilen.
- Wir richten je Website eigene Benutzer, Pools, Temp-Ordner und Datenbankzugänge ein, ohne die Anwendungen zu verändern.
- Wir testen jede Website nach der Umstellung und beheben fehlende Pfade gezielt.
- Wir dokumentieren die Trennung als Vorlage für künftige Projekte.
Wie das in ein Gesamtkonzept passt, beschreibt die Leistung Server-Härtung für PHP-Webserver.
Häufige Fragen
Reicht open_basedir, um Websites voneinander zu trennen?
Nein. open_basedir ist eine zusätzliche Schranke innerhalb von PHP, keine harte Trennung. Verlässlich wird die Isolation erst mit eigenen Systembenutzern und Pools je Website, bei höherem Schutzbedarf mit Containern oder getrennten Servern.
Warum funktionieren nach dem Setzen von open_basedir Uploads nicht mehr?
Meist fehlt der Ordner für temporäre Dateien in der Liste. Legen Sie für jede Website einen eigenen Tmp-Ordner an, tragen Sie ihn in open_basedir ein und setzen Sie upload_tmp_dir und sys_temp_dir auf diesen Ordner.
Kann eine Anwendung open_basedir selbst aufheben?
Eine Anwendung kann die Einstellung zur Laufzeit nur weiter einschränken, nicht lockern. Setzen Sie open_basedir trotzdem über php_admin_value im Pool, damit der Wert eindeutig festliegt.
Ist Isolation auch bei Shared Hosting möglich?
Das liegt beim Hoster. Viele Angebote trennen Kunden über eigene Benutzer und PHP-Prozesse. Fragen Sie nach, wie die Trennung umgesetzt ist, besonders wenn mehrere Ihrer Websites in einem Paket liegen.