Kurz gesagt: Sicherheitslücken in PHP werden vertraulich gemeldet, bevorzugt über das private Advisory-Formular im GitHub-Repository php/php-src, alternativ an security@php.net. Die PHP-Entwickler stufen den Fund als hoch, mittel oder niedrig ein; schwere Fehler werden in einem getrennten Sicherheits-Repository korrigiert und erst mit dem Release zusammen mit einem GitHub Security Advisory und meist einer CVE-Nummer veröffentlicht. Bei PHP2Shell lief dieser Prozess im Eiltempo: Vorankündigung am 20.10.2026, Patches am 21.10.2026, ergänzender Hinweis am 23.10.2026.
Wer kümmert sich bei PHP um Sicherheit?
PHP ist ein Open-Source-Projekt. Die Sicherheitsrichtlinie im Wiki beschreibt es als Projekt von Freiwilligen ohne Budget für Prämien. Für jede Version gibt es Release-Manager, die die Veröffentlichungen verantworten. Dazu kommt die PHP Foundation, die laut eigener Darstellung ein Team von Teilzeit- und Vollzeitentwicklern beauftragt, das an Wartung, Sicherheit und neuen Funktionen von PHP arbeitet.
Für Unternehmen heißt das: Es gibt keinen Hersteller mit Vertrag, Hotline oder zugesicherten Reaktionszeiten. Wer verbindliche Zusagen braucht, bekommt sie von seiner Linux-Distribution, seinem Hoster oder einem Anbieter für Langzeitsupport, nicht vom PHP-Projekt selbst. Diese Lieferkette sollten Sie kennen.
So wird eine Lücke gemeldet
Der Weg ist in der Sicherheitsrichtlinie auf GitHub beschrieben:
- Melden: über das private Formular für Security Advisories im Repository
php/php-src. Wer das nicht nutzen kann oder ein Thema besprechen will, das kein Fehlerbericht ist, schreibt an security@php.net. - Knapp beschreiben: Gewünscht ist ein kurzes Beispiel, das den Fehler zeigt, kein langer Bericht über mögliche Auswirkungen. So kann das Team schneller sichten.
- Vertraulichkeit: Die Meldung bleibt bis zur Veröffentlichung privat.
- Nennung: Meldende werden nach dem Credit-System von MITRE als Mitwirkende genannt.
Die ältere Wiki-Seite nennt zusätzlich den klassischen Fehler-Tracker mit dem Typ „Security“. Maßgeblich ist heute der Weg über GitHub.
Was das PHP-Projekt als Sicherheitslücke einstuft
Nicht jeder Absturz ist eine Sicherheitslücke. Das Wiki nennt vier Kriterien: Ein Fehler erlaubt unberechtigte Aktionen, überschreitet Sicherheitsgrenzen, öffnet Zugriff auf fremde Daten oder beeinträchtigt Verfügbarkeit oder Leistung schwer. Eingestuft wird in drei Stufen:
| Stufe | Bedeutung laut Richtlinie | CVE-Nummer |
|---|---|---|
| Hoch | Dritte können die meisten Installationen kompromittieren, Code ausführen oder Dateien lesen | in der Regel ja |
| Mittel | ähnliche Wirkung, aber nur unter selteneren Bedingungen, etwa einer seltenen Erweiterung oder Konfiguration | meist ja |
| Niedrig | theoretisch möglich, praktisch sehr schwer ausnutzbar | meist nein |
Ebenso aufschlussreich ist die Liste dessen, was ausdrücklich keine Sicherheitslücke ist: bösartiger Code, der absichtlich ausgeführt wird, Umgehungen von open_basedir und disable_functions, bösartige Eingaben an unserialize(), die Nutzung von FFI und ein gewöhnlicher Speicherabbruch, bei dem memory_limit greift und nur die aktuelle Anfrage endet. Für Betreiber heißt das: disable_functions ist sinnvolle Härtung, aber kein Schutzwall.
Vom Fix zur Veröffentlichung
Korrekturen für hohe und mittlere Lücken werden laut Wiki in einem getrennten Sicherheits-Repository eingepflegt, bevor das Release erstellt wird. Niedrig eingestufte Fehler laufen wie normale Fehlerkorrekturen. Veröffentlicht wird die Lücke nach dem Prinzip der verantwortungsvollen Offenlegung: erst die Korrektur, dann die Details. Releases erscheinen laut Wiki meist donnerstags, häufig im Rahmen der regulären monatlichen Veröffentlichungen.
Mit dem Release erscheint ein GitHub Security Advisory mit eigener Kennung (GHSA) und Schweregrad. Im Repository sind zum Beispiel am 24.09.2026 mehrere Advisories zu Stream-Wrappern, FastCGI und Filtern mit Schweregraden von niedrig bis hoch erschienen. Die Quellpakete auf php.net werden mit SHA-256-Prüfsummen und GPG-Signaturen der Release-Manager angeboten; die Git-Tags sind signiert. Welche Versionszweige überhaupt noch Sicherheitskorrekturen erhalten, zeigt die Seite zu den PHP-Versionen und dem Release-Zyklus.
PHP2Shell als Beispiel für den Ernstfall
PHP2Shell zeigt, wie der Prozess unter Druck abläuft:
- 20.10.2026: php.net kündigt ein kritisches Sicherheitsrelease für den 21.10.2026 um 14:00 UTC an und behält sich vor, früher zu veröffentlichen, falls Details öffentlich werden oder Angriffe auftauchen. Laut mehreren Berichten waren Details tatsächlich vor Ablauf der Sperrfrist bekannt geworden; die Hintergründe beleuchtet Warum die PHP-Lücke vor dem Patch bekannt wurde.
- 21.10.2026: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen, dazu die Advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) und GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), beide als kritisch eingestuft. Laut php.net hatten Linux-Distributionen und Anbieter von Langzeitsupport die Korrekturen vorab erhalten. Für 7.4, 8.0 und 8.1 gibt es minimale Backports.
- 23.10.2026: Ein informativer Hinweis zu CVE-2026-115560 empfiehlt
session.upload_progress.enabled=0; das vollständige Advisory folgt mit dem nächsten Release.
Was Betreiber daraus ableiten
- Quellen abonnieren: php.net, die GitHub-Advisories von
php/php-srcund die Sicherheitsmeldungen Ihrer Distribution. - Lieferkette kennen: Wer liefert Ihr PHP-Paket, und wie schnell kommen dort Backports an?
- Zeitfenster planen: Kritische Releases können außerhalb des üblichen Rhythmus kommen; ein Patch-Fenster muss kurzfristig möglich sein.
- Neustart einplanen: Ein Update wirkt erst, wenn alle PHP-Prozesse neu gestartet sind.
- Nachweis sichern: Version, Paketstand und Zeitpunkt dokumentieren.
Wie hilft PHP SOS konkret?
Mit dem PHP-Patch-Service übernehmen wir den Teil, der bei Ihnen liegt:
- Meldungen verfolgen: Wir beobachten php.net, die Advisories und die Meldungen der Distributionen und bewerten, ob Ihre Systeme betroffen sind.
- Patch umsetzen: Update aus der passenden Quelle, Neustart aller Prozesse, Kontrolle der laufenden Version.
- Übergang absichern: Wo das Update hängt, setzen wir die offiziellen Übergangsmaßnahmen um.
- Dokumentieren: Sie erhalten einen Nachweis mit Versionen, Paketständen und Zeitpunkten.
Häufige Fragen
Wie meldet man eine Sicherheitslücke in PHP?
Bevorzugt über das private Meldeformular für Security Advisories im GitHub-Repository php/php-src. Wer das nicht nutzen kann, schreibt an security@php.net. Die Meldung bleibt bis zur Veröffentlichung vertraulich.
Zahlt das PHP-Projekt eine Prämie für gefundene Lücken?
Nein. Laut Sicherheitsrichtlinie ist PHP ein Projekt von Freiwilligen ohne Geld für Bug Bounties. Meldende werden aber als Mitwirkende genannt.
Ist eine Umgehung von disable_functions eine Sicherheitslücke?
Nach der Richtlinie des PHP-Projekts nicht. Umgehungen von open_basedir und disable_functions gelten nicht als Sicherheitsproblem von PHP. Die Einstellungen sind Härtung, aber keine verlässliche Sicherheitsgrenze.
Wo erfahre ich von neuen PHP-Sicherheitslücken?
Auf der Startseite von php.net mit den Release-Meldungen und in den Security Advisories des GitHub-Repositorys php/php-src. Wer PHP aus der Distribution bezieht, verfolgt zusätzlich deren Sicherheitsmeldungen.
Warum wurde PHP2Shell an einem Mittwoch veröffentlicht?
Releases erscheinen laut Wiki meist donnerstags. Für PHP2Shell kündigte php.net am 20.10.2026 ein Sicherheitsrelease für Mittwoch, 21.10.2026, 14:00 UTC an und behielt sich vor, früher zu veröffentlichen, falls Details öffentlich würden.