Alexandre Daubois beschreibt in einem am 14. Oktober 2026 veröffentlichten Beitrag die Arbeit hinter den Sicherheitsmeldungen für PHPs Kerncode. Das Team besteht aus Community-Mitgliedern und von The PHP Foundation finanzierten Entwicklern. Es arbeitet unabhängig von der Foundation. Deren Ecosystem Security Team unterstützt die Arbeit parallel. Jede Meldung wird von einem Teammitglied gelesen, reproduziert und anhand der Klassifizierungsrichtlinie geprüft, bevor eine Entscheidung fällt.

Seit dem 1. Juli veröffentlichte das Team 15 CVEs und schloss 106 Meldungen. Darunter waren keine Schwachstellen, Duplikate und Fälle ohne erfolgreiche Reproduktion. Einige Meldungen stammten von Fuzzern, die Bedingungen nutzten, wie sie in Produktionsumgebungen nicht vorkommen. Jede Meldung wurde geprüft. Fälle, die keine Schwachstelle sind, aber einen Fehler zeigen, können als Hardening-Aufgabe weiterbearbeitet werden. Daniel Scherzer ist dafür kürzlich zum Ecosystem Security Team gestoßen.

Die PHP Group ist für php-src eine CVE Numbering Authority und vergibt seit 2019 eigene CVE-Kennungen. Das Team kann seine Advisories dadurch selbst terminieren. Bei GitHub dauern Prüfungen in der Advisory-Warteschlange im Jahr 2026 teilweise Wochen. PHP muss auf diese Warteschlange nicht warten, sobald ein Fix bereitsteht.

Ein Rückstand bei den Sicherheitsmeldungen bleibt bestehen. Das Team bittet darum, nicht mit öffentlichen Issues, Pull Requests oder Social-Media-Beiträgen Druck auszuüben. Dadurch könnte ein Fehler vor einem Fix bekannt werden. Freiwillige sowie von der PHP Foundation finanzierte Entwickler erledigen die Arbeit. Sponsoring soll die dafür nötigen Ressourcen bereitstellen.

KI-Werkzeuge haben die Zahl der Meldungen für php-src erhöht und das Erstellen solcher Meldungen vereinfacht. Das Team automatisiert deshalb weitere Abläufe. Reproduktionen decken Linux und macOS ab. Auch Windows und andere für einen Fall relevante Plattformen werden genutzt. Die Builds laufen mit AddressSanitizer und UndefinedBehaviorSanitizer und entsprechen der CI-Konfiguration des Projekts.

Das Team verwendet Daybreak Red, die höchste Stufe des OpenAI-Programms Daybreak. Der Zugang ist zugelassenen Verteidigern vorbehalten und für Sicherheitsforschung sowie Exploit-Validierung ausgelegt. OpenAI stellte ihn im Rahmen seiner Unterstützung für Open-Source-Maintainer bereit. Das Team verfolgt damit Proof-of-Concept-Code durch die Engine, prüft die behaupteten Auswirkungen und erkennt Meldungen mit derselben Ursache. Anfang 2026 nutzte es außerdem Claude Mythos, ein damals führendes Sicherheitsmodell von Anthropic. Der Zugang entstand vor allem über Kontakte zu Alpha-Omega.

Die Modelle treffen keine abschließenden Entscheidungen. Ein Mensch legt den Schweregrad fest und schreibt oder prüft jeden Patch. Eine Analyse wird erst an den Melder weitergegeben, wenn ein Teammitglied die Reproduktion versucht hat.

Meldungen gehören in das GitHub-Sicherheitsformular unter github.com/php/php-src/security/advisories/new. Öffentliche Issues sind für Fälle außerhalb dieses Prozesses gedacht. Eine gute Meldung beginnt mit dem kleinsten PHP-Skript, das den Fehler auslöst. Sie muss die PHP-Version oder den Commit nennen. Auch Betriebssystem und Configure-Flags gehören dazu. Vollständige Sanitizer-Ausgaben helfen bei der Prüfung.

Die Meldung sollte angeben, welche Eingabe ein Angreifer kontrolliert, in welcher Art Anwendung das geschieht und welches Ergebnis daraus entsteht. Gerade die Auswirkungen werden häufig zu knapp beschrieben, obwohl sie den Schweregrad bestimmen. Lange und dramatische Texte bremsen einfache Untersuchungen. Die Sicherheitsrichtlinie steht unter github.com/php/policies/blob/main/security-classification.rst.

Gültiger, bösartig eingesetzter PHP-Code gilt nach dieser Richtlinie nicht als Sicherheitslücke. Das gilt auch für unsanitisierte Eingaben an Funktionen wie mysqli_query(), FFI-Probleme, open_basedir-Umgehungen, nicht standardmäßige Builds und Fehler, die nur den eingebauten Webserver betreffen. Solche Fälle können weiterhin Bugs sein und gehören in den öffentlichen Issue-Tracker.

KI-gestützte Meldungen sind willkommen, wenn der Absender das Problem auf einem PHP-Build reproduziert, die Richtlinie geprüft und die eigene Behauptung verstanden hat. Ein von einem Modell erzeugter, nicht reproduzierbarer Absturz kostet bei der Zurückweisung ebenso Zeit und wird geschlossen.