Das Ecosystem Security Team der PHP Foundation hat am 19. August 2026 einen praktischen Leitfaden von Sebastian Bergmann veröffentlicht, der Maintainer von PHP-Projekten durch den gesamten Ablauf einer Security-Meldung führt. Der Leitfaden ist in zehn Abschnitte plus ein Cheatsheet auf einem Bildschirm gegliedert; man springt direkt zu der Phase, in der man gerade steckt.

Das Kernprinzip ist Coordinated Disclosure: Details bleiben privat, bis ein Fix existiert. Keine öffentlichen Issues, keine öffentlichen Pull Requests, keine Commit-Messages wie "fix SQL injection in login handler" und keine Fixes auf öffentlichen Branches. Ein solcher Commit ist bereits die Veröffentlichung. Gleichzeitig sollte man die Meldung innerhalb weniger Tage bestätigen, auch mit einem einzigen Satz, denn Schweigen macht aus wohlmeinenden Meldern frustrierte, die irgendwann selbst veröffentlichen. Eine Meldung ist eine Behauptung, kein Urteil: Der Maintainer entscheidet, was valide ist, was außerhalb des Scopes liegt und welcher Zeitplan gilt. "Works as designed" ist eine legitime Antwort, wenn die Meldung Fähigkeiten voraussetzt, die das dokumentierte Sicherheitsmodell als vertrauenswürdig einstuft.

Ein Abschnitt existiert wegen des schlimmsten denkbaren Fehlers: Proof-of-Concept-Code niemals auf dem eigenen Rechner ausführen. Dort liegen SSH- und GPG-Schlüssel, Packagist- und GitHub-Zugänge und der Passwort-Manager; ein bösartiger PoC macht daraus einen Supply-Chain-Angriff auf alle, die das Paket installieren. Die Rangfolge der Isolation: eine MicroVM-Sandbox wie Docker Sandboxes (sbx) mit eigenem Kernel und standardmäßig gesperrtem Netzwerk; ein Container, wobei Container unter Linux den Host-Kernel teilen, während Docker Desktop unter macOS und Windows bereits hinter einer VM-Grenze läuft; eine gehärtete VM mit Snapshot und ohne Shared Folders; oder eine Wegwerf-VM in der Cloud. Präparierte Eingabedateien wie .phar-Archive oder serialisierte Payloads gelten als Code und fallen unter dieselben Regeln.

Der Fix gehört in den temporären privaten Fork von GitHub Security Advisories, der Regressionstest wird zuerst geschrieben, Commit-Messages bleiben neutral. Fallstricke: CI läuft nicht in privaten Forks, der Fork überlebt die Advisory nicht, und ein stiller Patch ohne Advisory lässt composer audit und Dependabot blind. Außerdem sollte man vor der Veröffentlichung nach Geschwisterfehlern derselben Klasse suchen, weil eine Advisory ein Schlaglicht auf diese Schwachstellenklasse wirft, und entscheiden, ob ältere unterstützte Branches Backports brauchen.

Bei Composer-Paketen entscheiden drei Advisory-Felder, ob die Werkzeuge greifen: Das Ökosystem muss Composer sein, der Paketname muss exakt dem Packagist-Namen in der Form vendor/package entsprechen, und die betroffenen Versionsbereiche müssen präzise Composer-Constraints sein. Das ist wichtiger geworden, weil der Dependency Resolver seit Composer 2.9 betroffene Versionen aktiv aus dem Kandidatenpool entfernt; Composer 2.10 erweiterte dies zu einem einheitlichen Dependency-Policy-Framework, das auch als Malware markierte Pakete sogar beim composer install blockiert. Zu breite Bereiche richten realen Schaden an: Bei einer PHPUnit-Advisory im April 2026 schrieb GitHub die konkreten betroffenen Versionen 12.5.21 und 13.1.5 in breite Bereiche um, wodurch über Nacht jede ältere PHPUnit-Version nicht mehr installierbar war, einschließlich des nie betroffenen PHPUnit 11. Korrekturen gehen am schnellsten über einen Pull Request zu FriendsOfPHP/security-advisories, dessen Daten bei Packagist Vorrang haben, plus einen PR zur GitHub Advisory Database.

Am Veröffentlichungstag gilt eine feste Reihenfolge: Fix mergen, taggen und releasen, bestätigen dass das Release auf Packagist erscheint, Advisory veröffentlichen, dann den FriendsOfPHP-Pull-Request, dann ankündigen. Der FriendsOfPHP-Schritt darf nicht übersprungen werden: Composer liest keine Advisorys auf Repository-Ebene, und GitHubs Review in die Advisory Database hinkt Tage bis Wochen hinterher. Für Projekte außerhalb von GitHub ist es der einzige Weg in die Toolchain. Der Abstand zwischen Release und Advisory sollte Minuten bis Stunden betragen, nicht Tage. Wenn Details vorzeitig leaken, ist das Embargo faktisch vorbei und man veröffentlicht, was man hat.

Zu CVEs: GitHub ist eine CNA, eine CVE-ID kann direkt aus der Advisory beantragt werden, dauert aber derzeit Wochen. Was Nutzer tatsächlich schützt, ist die GHSA, denn darauf reagieren Composer, composer audit und Dependabot. Also niemals ein Release auf eine CVE warten lassen. Den Reporter in der Advisory nennen; das kostet nichts und ist ein wesentlicher Anreiz für verantwortungsvolles Melden.

Die Schlussabschnitte behandeln die langfristige Haltung: GitHub Private Vulnerability Reporting aktivieren und eine SECURITY.md anlegen; starkes 2FA für GitHub, Packagist und E-Mail, wobei Packagist den MFA-Status von Maintainern künftig öffentlich ausweisen wird; niemals ein veröffentlichtes Tag überschreiben, was Packagist bei stabilen Versionen inzwischen ablehnt; veraltete Branches und Workflows löschen, um das Risiko von Poisoned Pipeline Execution zu senken; und GitHub-Actions-Workflows härten, wo PHPUnit selbst von 52 Befunden auf null kam, nachdem Template Injection, Credential Persistence, ungepinnte Actions, zu breite Permissions und überflüssige Drittanbieter-Actions behoben wurden. Als automatisierte Prüfung wird zizmor empfohlen.

Wer festhängt, erreicht das Ecosystem Security Team unter volker@thephp.foundation oder im Channel #ecosystem-security auf dem phpc-Discord. Das Team hilft bei Triage, Reproduktion in isolierten Umgebungen, Severity-Scoring und Coordinated Disclosure und will sich ausdrücklich nicht zwischen Meldung und Fix stellen.