Patch the Planet: weltweit auf kritische Schwachstellen reagieren, die Agenten aufdecken
In den vergangenen zwei Monaten haben wir einen Zusammenschluss aus Wartungsteams, Forschenden und Sicherheitsanbietern geleitet, um kritische Schwachstellen in PHP zu beheben. Diese Open-Source-Programmiersprache wird für Websites und Webanwendungen genutzt. Calif entdeckte mithilfe von GPT‑5.6 Sol im Rahmen unserer Initiative Patch the Planet(wird in einem neuen Fenster geöffnet) eine kritische Schwachstelle. Unabhängig davon entdeckte und meldete auch Wiz beide Schwachstellen. Das PHP-Wartungsteam leitete die Fehlerbehebung und Veröffentlichung. Unsere Teams sowie Partnerunternehmen wie Wiz, Cloudflare und andere unterstützten mit Forschung, technischer Hilfe und Koordination, um vor der Offenlegung Schutzmaßnahmen vorzubereiten.
Für Organisationen, die PHP nutzen, hat das Einspielen der Korrekturen jetzt Priorität. Wir stellen einen PHP-Versionsprüfer als Codex-Skill bereit(wird in einem neuen Fenster geöffnet) Damit können Betriebsteams potenziell anfällige PHP-Versionen erkennen und anhand der Hinweise von PHP und ihren Anbietern ermitteln, welche Updates nötig sind.
Angesichts der Schwere dieser Schwachstellen und der weiten Verbreitung von PHP zählen wir dies zu den folgenreichsten Sicherheitsproblemen der jüngeren Vergangenheit. Der Fall zeigt, wie KI Sicherheitslücken mit internetweiten Auswirkungen aufdecken kann. Dieselben Fähigkeiten können Angreifenden aber auch helfen, schnell Angriffswerkzeuge und Exploits zu entwickeln.
Nach unserem Kenntnisstand entdeckte Frontier-KI diese Schwachstellen vor Angreifenden. Das eröffnete ein Zeitfenster für die Abwehr, in dem Wartungsteams und Sicherheitsanbieter vor der Offenlegung Korrekturen und Schutzmaßnahmen vorbereiten konnten.
Damit mehr Sicherheitsverantwortliche diese Fähigkeiten nutzen können, haben wir über Daybreak for Frontline Defenders eine Milliarde US-Dollar für subventionierten Zugang zu Daybreak zugesagt. Im Fokus stehen Organisationen, die mit begrenzten Sicherheitsressourcen grundlegende Dienste schützen.
So schwerwiegend diese Fehler sind: Sie gehören zu mehreren bedeutenden Schwachstellen, die wir bereits gefunden haben und an deren Behebung wir arbeiten. Wir erwarten, dass ähnliche Funde in den kommenden Monaten stark zunehmen. Auf Grundlage unserer bisherigen Erfahrungen schlagen wir ein Vorgehen für das KI-Zeitalter vor, um auf kritische Schwachstellen in weitverbreiteter Software zu reagieren. Wir bitten die Sicherheitscommunity, diesen Rahmen mit uns zu verbessern. Er verbindet unsere Modelle, Sicherheitsfachwissen und Wartungsteams, um aus Erkenntnissen Schutzmaßnahmen zu entwickeln und ein Vorgehen aufzubauen, das mit den Fortschritten der KI Schritt hält.
Eine Korrektur in die Praxis zu bringen, kann bedeuten, sie an ältere Versionen anzupassen, Schutzmaßnahmen bei Anbietern vorzubereiten und Systeme in vielen Organisationen zu aktualisieren. Ein wiederholbarer Prozess hilft diesen Teams, bei weiteren Schwachstellen schnell zu handeln.
Über Patch the Planet unterstützten wir die Reaktion auf die PHP-Schwachstellen mit Sicherheitsfachwissen und Modellzugang. Gemeinsam mit Wartungsteams und Forschungspartnern testeten wir Korrekturen und bereiteten Handlungsempfehlungen vor. Wir halfen auch, Schutzmaßnahmen für betroffene Systeme mit Infrastrukturanbietern abzustimmen, und bezogen staatliche Cybersicherheitsbehörden ein, damit die Empfehlungen wichtige Organisationen erreichen. Dies unterstützte das vom Wartungsteam geleitete Vorgehen und half weiteren Sicherheitsverantwortlichen bei der Vorbereitung.
Bei manchen Funden können Forschende direkt mit den Wartungsteams der Software zusammenarbeiten, um das Problem zu untersuchen und eine Korrektur zu entwickeln. Andere erfordern eine breitere Zusammenarbeit, weil viele Produkte betroffen sind oder Distributoren und Dienstleister Zeit für Updates und Schutzmaßnahmen brauchen. Diese Zeit kann knapp sein, wenn Frontier-Fähigkeiten den allgemein verfügbaren Fähigkeiten nicht weit voraus sind. In solchen Fällen kann der vorgeschlagene Rahmen Wartungsteams helfen, die nötigen Beteiligten zu bestimmen und die Arbeit zu koordinieren. Das Vorgehen kann fünf Phasen umfassen:
Die Schwachstelle im Ursprungsprojekt bestätigen und beheben. Das Wartungsteam, Forschende und zentrale technische Partner bestätigen den Fund, bewerten seine Auswirkungen und entwickeln und testen eine Korrektur. Dazu gehören Angriffstests mit Frontier-Modellen, um Umgehungsmöglichkeiten für den Patch und verwandte Varianten der Schwachstelle zu finden.
Betroffenen Organisationen Zeit zum Handeln geben. Wir schlagen einen Rahmen vor, um abzuwägen, welche Organisationen Vorabinformationen zur Vorbereitung von Schutzmaßnahmen brauchen. Die Wartungsteams entscheiden, wen sie einbeziehen. Wir helfen bei der Kontaktaufnahme, bei Vereinbarungen zum Informationsaustausch und bei der Koordination zwischen Teams. Ein Distributor könnte eine Korrektur an eine ältere Version anpassen, ein Hostinganbieter eine Schutzmaßnahme testen und ein Sicherheitsanbieter Erkennungs- oder Präventionsmaßnahmen vorbereiten, etwa Regeln für eine Web Application Firewall (WAF).
Mit staatlichen Partnern zusammenarbeiten, um kritische Systeme zu schützen. Staatliche Stellen spielen eine wesentliche Rolle bei der übergreifenden Koordination. Sie helfen, Sicherheitsempfehlungen an Organisationen zu vermitteln, die für kritische Infrastruktur und andere grundlegende Dienste verantwortlich sind. Im Fall von PHP suchten wir gemeinsam mit unseren Partnern den Austausch mit mehreren Stellen der US-Regierung: der Super Intelligence Force des Weißen Hauses, dem Office of the National Cyber Director (ONCD) und der Cybersecurity and Infrastructure Security Agency (CISA). Auch internationale Partner bezogen wir ein, um diese Arbeit zu unterstützen.
Updates für betroffene Produkte vorbereiten. Sobald Korrektur, Empfehlungen und Offenlegungspläne weitgehend feststehen, können Wartungsteams weitere Distributoren, Hostinganbieter, Dienstleister, Reaktionsteams und Betriebsteams einbeziehen, um Updates vorzubereiten und Schutzlücken zu schließen.
Sobald ein Patch verfügbar ist, Empfehlungen veröffentlichen und die Bereitstellung unterstützen. Öffentliche Empfehlungen helfen dabei, die eigene Gefährdung einzuschätzen, offizielle Updates oder vorläufige Schutzmaßnahmen zu finden und zu prüfen, ob eine Korrektur aktiv ist. Die Zusammenarbeit geht weiter, während Betriebsteams Updates einspielen und melden, wo sie Hilfe brauchen.
Der vorgeschlagene Rahmen berücksichtigt die Schutzaufgaben einer Organisation, auch für eigene Systeme und ihre Kundschaft, die nötige Reaktionszeit und ihre Fähigkeit, mit sensiblen Informationen umzugehen. Für vergleichbare Organisationen würden dieselben Kriterien gelten. Die Wartungsteams entscheiden, wen sie vor der Offenlegung einbeziehen.
Alle Beteiligten erhalten die Informationen, die sie für ihre Schutzaufgaben brauchen: von Netzwerkprotokollen mit Kompromittierungsindikatoren bis hin zu sensibleren, funktionsfähigen Proof-of-Concept-Exploits. Schon wenige Details können eine Schwachstelle offenbaren. Deshalb wägen wir das Risiko ihrer Weitergabe gegen den dadurch möglichen Schutz ab.
Teams, die diesem Rahmen folgen, würden mit den Wartungsteams Zeit zur Vorbereitung von Schutzmaßnahmen einräumen. Sie würden den Zeitplan neu bewerten, wenn die Schwachstelle bereits ausgenutzt wird, Informationen unbefugt bekannt werden, ein öffentlicher Patch die Lücke verrät oder stockende Abhilfe das Risiko für Nutzende erhöht.
Die Website von Patch the Planet(wird in einem neuen Fenster geöffnet) bündelt öffentliche Schwachstellenmeldungen und Empfehlungen. So können Betriebsteams betroffene Systeme erkennen, das passende Update finden und prüfen, ob die aktualisierte Software ordnungsgemäß läuft. Für PHP verweist sie auf den offiziellen Patch und die Upgrade-Anleitungen des Wartungsteams sowie auf die technischen Forschungsergebnisse unserer Partner. Die Empfehlungen behandeln auch vorläufige Schutzmaßnahmen, den richtigen Zeitpunkt für das Hinzuziehen eines Anbieters oder einer Fachperson sowie Datensicherung und Wiederherstellung. Vorläufige Schutzmaßnahmen können Risiken senken. Wir werden ihre Grenzen und betrieblichen Nachteile jedoch klar benennen.
Betriebsteams können anhand der CISA-Empfehlungen zur Priorisierung und Behebung(wird in einem neuen Fenster geöffnet) einschätzen, wie schnell sie handeln müssen. Maßgeblich sind Gefährdung, Ausnutzung und mögliche Auswirkungen. Das kann Notfall-Patches, sofortige Schutzmaßnahmen oder ein geplantes Update erfordern. Bei Bedarf kommt eine forensische Ersteinschätzung hinzu, um zu prüfen, ob Systeme bereits kompromittiert wurden. Bei veränderten Bedingungen sollten Prioritäten neu bewertet werden. Dabei braucht es einen klaren Weg zur dauerhaften Behebung.
Weltweite Koordination hängt von den Menschen ab, die die Software warten. Viele Projekte werden von kleinen Teams betreut, die neben der regulären Entwicklungsarbeit auch Sicherheitsmeldungen prüfen. Diese Teams brauchen Hilfe, um neue Probleme von doppelten Meldungen zu unterscheiden, Auswirkungen einzuschätzen und Korrekturen in allen unterstützten Versionen zu testen. Wir unterstützen diese Arbeit mit finanziellen Mitteln, Zugang zu leistungsfähigen Modellen und praktischer technischer Hilfe.
Die KI-Fähigkeiten entwickeln sich in der gesamten Branche weiter. Wir erwarten, dass KI Sicherheitsverantwortliche zunehmend dabei unterstützt, Schwachstellen zu finden, Systeme zu überwachen und auf Bedrohungen zu reagieren. Wir investieren in Modelle, Werkzeuge und Partnerschaften, damit Sicherheitsverantwortliche diese Fähigkeiten nutzen können.
Dazu gehören Abonnements für alle, die Software warten, über Codex for OSS sowie die direkte Förderung von Projekten wie der Rust Foundation(wird in einem neuen Fenster geöffnet), um Wartungsteams und technische Arbeit zu unterstützen. Jedes Projekt legt seine eigenen Prioritäten fest. Wiederverwendbare Tests und Sicherheitsabläufe können den Aufwand für den Umgang mit künftigen Funden verringern. Open-Source-Projekte können sich für praktische Unterstützung bei Patch the Planet bewerben(wird in einem neuen Fenster geöffnet).
Wir kalibrieren außerdem zusätzliche Klassifikatoren für Daybreak, die Anfragen blockieren, um das Missbrauchspotenzial zu verringern. Dabei sind schwierige Abwägungen nötig: Schutzmaßnahmen gegen Missbrauch können auch legitime Sicherheitsarbeit blockieren. Ein breiter Zugang zu leistungsfähigen Modellen und ein wirksamer Schutz vor Missbrauch sind gleichermaßen entscheidend. Unser Ziel ist, die Fähigkeiten zu erhalten, die Sicherheitsverantwortliche zum Finden und Beheben von Schwachstellen brauchen, und zugleich schädliche Nutzung einzuschränken. Wir werden dieses Gleichgewicht weiter verfeinern, während sich die Fähigkeiten entwickeln und wir aus der Nutzung dieser Werkzeuge lernen.
Mit leistungsfähigeren Modellen reichen die Möglichkeiten über das Finden und Beheben einzelner Schwachstellen hinaus. Wir möchten Entwicklungsteams helfen, Software von Anfang an sicherer zu gestalten. Verbesserungen an einer weitverbreiteten Komponente können Fehler in vielen Produkten und Diensten verhindern oder ihre Auswirkungen begrenzen.
KI kann Entwicklungsteams helfen, bestehenden Code zu verstehen, Änderungen vorzubereiten und Tests zu entwickeln. Wartungsteams und Sicherheitsfachleute prüfen dabei, ob das Verhalten erhalten bleibt, auf das sich Nutzende verlassen. Wir sehen in mehreren Bereichen Möglichkeiten:
Sicherer Code von Anfang an. Programmiermodelle können Entwickelnden helfen, sicherere Standardeinstellungen zu wählen, Sicherheitsbibliotheken korrekt zu nutzen und riskante Muster schon beim Schreiben zu erkennen. Wer Schwachstellen während der Entwicklung verhindert, erspart Wartungsteams und Nutzenden spätere Notfallkorrekturen.
Speichersichere Software. Die Umstellung kritischer Komponenten auf speichersichere Sprachen kann häufige Klassen von Speicherfehlern ausschließen. KI kann bei Migrationen helfen. Tests und fachliche Prüfungen dienen dabei dazu, Verhalten und Kompatibilität zu kontrollieren.
Formale Verifikation. Mathematische Beweise können zeigen, dass kritische Komponenten unter festgelegten Annahmen bestimmte Sicherheitseigenschaften erfüllen. Diese Methoden auf weitverbreitete Komponenten anzuwenden, könnte helfen, ganze Schwachstellenklassen in den darauf aufbauenden Diensten und kritischen Infrastrukturen auszuschließen.
Stärkere Isolation. Systeme brauchen Schutz vor Schwachstellen, die noch nicht entdeckt oder behoben wurden. Software, die nicht vertrauenswürdige Dateien, Bilder oder Medien verarbeitet, kann in streng abgeschotteten Sandboxes ausgeführt werden. Wird sie kompromittiert, lässt sich so der Schaden begrenzen. KI kann Entwicklungsteams helfen, weitverbreitete Sandboxing-Technologien zu testen und zu stärken. Das verbessert den Schutz vieler Anwendungen.
Wir veröffentlichen unseren Ansatz, damit Wartungsteams, Forschende, Reaktionsteams, Anbieter und Betriebsteams ihn mit uns praxistauglich gestalten können. Wir möchten verstehen, wo er helfen würde, wo er Verzögerungen oder zusätzlichen Aufwand verursachen könnte und was wir übersehen haben. Beispiele aus früheren Offenlegungen wären besonders hilfreich.
Besonders interessieren uns:
Fristen bis zur Offenlegung. Wie viel Zeit brauchen Wartungsteams, Betriebsteams und Sicherheitsverantwortliche, um zuverlässige Korrekturen vorzubereiten und einzuspielen? Welche Anhaltspunkte sollten zu einer früheren Offenlegung führen, insbesondere wenn manche Nutzende früher geschützt werden können als andere?
Notfall-Patches. Wann sollten staatliche Stellen oder andere Systembetreiber, wenn überhaupt, eine Schwachstelle nutzen, um nach Verlust des administrativen Zugriffs eigene Systeme oder Systeme, die sie verwalten dürfen, zu patchen? Welche Schutzvorkehrungen sollten dabei gelten? Als möglichen Endzustand können wir uns vorstellen, dass das Internet fortlaufend auf bekannte Schwachstellen geprüft wird. Bei einem Fund würden entweder die Website-Verantwortlichen benachrichtigt oder das System gepatcht.
Frühzeitige Benachrichtigung. Wer braucht eine Vorwarnung, um sinnvolle Schutzmaßnahmen ergreifen zu können, einschließlich Sicherheitsverantwortlicher, die wir womöglich übersehen? Wann sind gestaffelte Benachrichtigungen besser als die gleichzeitige Information eines größeren Kreises? Wie sollten wir die Schutzabdeckung gegen das Risiko abwägen, dass Informationen unbefugt bekannt werden?
Standardmäßig sichere Softwarepakete. Wie können wir helfen, Schwachstellen in nachgelagerten Paketen zu erkennen und zu beheben, solange Korrekturen im Ursprungsprojekt noch ausstehen? Wie lassen sich Korrekturen auf ältere Versionen übertragen, die keine Sicherheitsupdates mehr erhalten? Welche Tests und Wartungsarbeiten würden diese Pakete zu verlässlichen Alternativen machen, wenn ein zeitnahes Upgrade nicht möglich ist?
Wir freuen uns auch über Empfehlungen für unabhängige Sicherheitsfachleute, die den Ansatz prüfen, seine Annahmen hinterfragen und Lücken aufzeigen können. Deine Rückmeldung hilft uns, das Vorgehen zu verfeinern und Unterstützung gezielt zu priorisieren. Teile hier dein Feedback(wird in einem neuen Fenster geöffnet).


