# PHP disable_functions richtig einsetzen

> PHP disable_functions richtig einsetzen: welche Funktionen Sie sperren, wie Sie Ihre Anwendung vorher prüfen und wo die Härtung an Grenzen stößt.

Quelle: https://phpsos.de/ratgeber/disable-functions/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Mit PHP disable_functions sperren Sie Funktionen, über die PHP Systembefehle ausführt, etwa `exec`, `shell_exec` oder `proc_open`. Das erschwert Angreifern nach einem Einbruch den nächsten Schritt. Die Einstellung wirkt nur aus php.ini oder FPM-Pool, muss zur Anwendung passen und ersetzt kein Update.

## Warum disable_functions gerade jetzt sinnvoll ist

Bei PHP2Shell geht es um die Ausführung von Schadcode aus der Ferne ohne Anmeldung. Die beiden Lücken CVE-2026-109618 und CVE-2026-109619 stecken im PHP-Interpreter selbst, behoben in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das Update ist der einzige Weg, sie zu schließen.

Härtung setzt eine Ebene später an. Wer einmal Code auf einem Server ausführen kann, will meist weiter: Systembefehle starten, Werkzeuge nachladen, eine dauerhafte Hintertür einrichten. Viele dieser Schritte laufen über wenige PHP-Funktionen. Sind sie gesperrt, wird der Weg mühsamer und auffälliger.

disable_functions ist deshalb kein Ersatz für Patches, sondern ein Baustein für den Fall, dass trotz aller Vorsicht etwas durchkommt. Das gilt für künftige Lücken genauso wie für PHP2Shell.

## Was PHP disable_functions leistet und was nicht

Die Einstellung entfernt die genannten Funktionen aus der Laufzeitumgebung. Ruft ein Skript eine gesperrte Funktion auf, bricht PHP mit einem Fehler ab. Die Sperre gilt für jeden Code, der in diesem PHP-Prozess läuft, also auch für eingeschleusten Code.

Die Grenzen sollten Sie kennen:

- Die Einstellung ist kein abgeschlossener Schutzraum. PHP-Erweiterungen, Fehler im Interpreter oder Programme außerhalb von PHP können sie umgehen.
- Sie verhindert nicht, dass ein Angreifer Dateien liest oder schreibt, auf die der PHP-Benutzer Zugriff hat. Dafür sind Dateirechte und Isolation zuständig.
- Sie wirkt nur aus der php.ini oder als `php_admin_value`. Mit `ini_set()`, `.user.ini` oder `.htaccess` lässt sie sich nicht setzen.

Am meisten bringt disable_functions zusammen mit einer sauberen php.ini, eigenen Benutzern je Website und restriktiven Dateirechten. Die Grundlagen dazu stehen im Ratgeber [php.ini sicher konfigurieren](https://phpsos.de/ratgeber/php-ini-sicher-konfigurieren/).

## Welche Funktionen Sie sperren sollten

Für typische Websites ohne Bedarf an Systembefehlen hat sich die folgende Liste bewährt. Sie umfasst Funktionen zum Starten von Prozessen und zum Steuern laufender Prozesse.

| Gruppe | Funktionen | Typischer legitimer Einsatz |
|---|---|---|
| Befehle ausführen | `exec`, `shell_exec`, `system`, `passthru` | Bildbearbeitung, Backups per Skript |
| Prozesse öffnen | `proc_open`, `popen` | Composer, PDF-Werkzeuge, Mailversand |
| Prozesse steuern | `proc_nice`, `proc_terminate`, `proc_get_status` | Warteschlangen, Hintergrundjobs |
| Prozessverwaltung | `pcntl_exec`, `pcntl_fork` | meist nur auf der Kommandozeile |
| Signale und Rechte | `posix_kill`, `posix_setuid` | selten im Webbetrieb |

Als Konfiguration sieht das so aus:

```ini
; php.ini der Web-Betriebsart, z. B. /etc/php/8.3/fpm/php.ini
disable_functions = exec,shell_exec,system,passthru,proc_open,popen,proc_nice,proc_terminate,proc_get_status,pcntl_exec,pcntl_fork,posix_kill,posix_setuid
```

Gilt die Liste nicht für alle Websites auf dem Server, setzen Sie sie je FPM-Pool. Prüfen Sie nach dem Neuladen, welche Liste in diesem Pool tatsächlich gilt:

```ini
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (Auszug)
php_admin_value[disable_functions] = exec,shell_exec,system,passthru,proc_open,popen
```

## Anwendung vorher prüfen: so vermeiden Sie Ausfälle

Wer die Liste ungeprüft setzt, riskiert, dass Bildverkleinerung, PDF-Rechnungen oder der Mailversand plötzlich nicht mehr funktionieren. Suchen Sie deshalb vorher im Code nach den betroffenen Funktionen:

```bash
# Wo und wie oft werden die Funktionen im Code verwendet?
grep -rnoE "\b(exec|shell_exec|system|passthru|proc_open|popen|pcntl_exec)\s*\(" /var/www/meine-seite --include="*.php" \
  | cut -d: -f1 | sort | uniq -c | sort -rn | head -30
```

Treffer bedeuten nicht automatisch, dass die Funktion im Betrieb gebraucht wird. Viele Bibliotheken prüfen erst, ob eine Funktion verfügbar ist, und weichen sonst aus. Entscheidend ist ein Test in einer Staging-Umgebung mit allen wichtigen Abläufen: Bestellung, Rechnung, Formularversand, Bild-Upload, geplante Aufgaben.

Verlangt eine Anwendung zwingend eine dieser Funktionen, prüfen Sie die Systemanforderungen des Herstellers auf dessen offizieller Seite. Oft lässt sich die Aufgabe auf einen getrennten Pool oder ein Kommandozeilen-Skript verlagern, das nicht über das Web erreichbar ist.

## Einstellung aktivieren und Wirkung kontrollieren

Nach der Änderung muss PHP die Konfiguration neu einlesen. Prüfen Sie danach den Wert in der Betriebsart Ihrer Website, nicht auf der Kommandozeile:

```bash
sudo systemctl reload php8.3-fpm
php-fpm8.3 -i | grep "^disable_functions"
# Fehlerlog auf Aufrufe gesperrter Funktionen prüfen
sudo grep -i "has been disabled" /var/log/php/*.log | tail -20
```

Die Meldungen im Fehlerlog sind auch später wertvoll. Tauchen dort plötzlich Aufrufe gesperrter Funktionen auf, obwohl Ihre Anwendung sie nicht nutzt, kann das auf eingeschleusten Code hindeuten. Wie Sie dann weiter vorgehen, beschreibt der Ratgeber [Webshells erkennen und entfernen](https://phpsos.de/ratgeber/webshell-erkennen/).

## Typische Fehler beim Einsatz von disable_functions

In der Praxis scheitert die Härtung selten an der Technik, sondern an Kleinigkeiten. Diese Fehler sind besonders verbreitet:

- **Falsche Datei geändert:** Die Liste steht nur in der php.ini der Kommandozeile, die Website läuft über PHP-FPM und bleibt ungeschützt.
- **Kein Neustart:** Die Datei ist korrekt, aber die laufenden Prozesse arbeiten noch mit der alten Konfiguration.
- **Zu breit gesperrt:** Funktionen wie `ini_set` oder `mail` werden mitgesperrt, und wichtige Abläufe brechen unbemerkt ab. Fehler fallen dann oft erst Tage später auf, etwa bei ausbleibenden Bestellbestätigungen.
- **Einmal gesetzt, nie geprüft:** Nach einem Umzug, einem Wechsel der PHP-Version oder einer Neuinstallation über das Hosting-Panel ist die Liste verschwunden.
- **Falsches Sicherheitsgefühl:** Die Sperre wird als Ersatz für Updates verstanden. Sie schließt aber keine Lücke im Interpreter.

Nehmen Sie die Prüfung des aktiven Wertes deshalb in Ihre Routine nach jedem PHP-Update auf. Ein kurzer Blick genügt, kostet kaum Zeit und verhindert, dass eine Härtung still verloren geht.

> **Tipp:**
> Bei mehreren Websites auf einem Server: Legen Sie für jede Website einen eigenen Pool mit eigener Liste an. Ergänzend begrenzt [open_basedir](https://phpsos.de/ratgeber/open-basedir/) die Verzeichnisse, auf die PHP zugreifen darf.

## Wie hilft PHP SOS konkret?

- Wir prüfen Code und Abläufe Ihrer Anwendung auf die Nutzung kritischer Funktionen.
- Wir legen je Website eine passende Sperrliste fest und testen sie vor dem Livegang.
- Wir kombinieren die Sperre mit Pools, Dateirechten und Protokollierung zu einem stimmigen Härtungskonzept.
- Wir dokumentieren die Einstellungen und überwachen das Fehlerlog auf auffällige Aufrufe.

Wie das als Gesamtpaket abläuft, beschreibt die Leistung [Server-Härtung für PHP-Webserver](https://phpsos.de/leistungen/server-haertung/).


## Häufige Fragen

**Kann ich disable_functions per ini_set() oder .htaccess setzen?**  
Nein. Die Einstellung wirkt nur aus der php.ini oder als php_admin_value im FPM-Pool beziehungsweise in der Apache-Konfiguration. Zur Laufzeit lässt sie sich nicht setzen, und die Anwendung kann gesperrte Funktionen auch nicht wieder freigeben.

**Schützt disable_functions vor PHP2Shell?**  
Nein. PHP2Shell betrifft den PHP-Interpreter selbst, die Lücke wird nur durch das Update geschlossen. Gesperrte Funktionen können aber den Spielraum eines Angreifers nach einer erfolgreichen Ausnutzung einschränken.

**Warum zeigt php -i eine andere Liste als meine Website?**  
Die Kommandozeile liest oft eine eigene php.ini. Für die Website zählt die Konfiguration von PHP-FPM, mod_php oder LiteSpeed. Prüfen Sie den Wert daher in der Betriebsart, über die Ihre Website läuft.

**Welche Anwendungen brauchen proc_open oder exec?**  
Das hängt von der Anwendung ab. Typisch sind Bildbearbeitung über externe Programme, PDF-Erzeugung, Mailversand über sendmail oder Werkzeuge wie Composer. Prüfen Sie das im Code und in den Systemanforderungen des Herstellers.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)