Pwn2Own Berlin 2026 — 47 Zero-Days, und KI-Tooling steht erstmals im Zentrum

Was ist passiert

Die Zero Day Initiative hat die dreitägige Pwn2Own Berlin 2026 (14.–16. Mai, OffensiveCon) abgeschlossen: 47 verifizierte Zero-Days, 1.298.250 US-Dollar Prämien, DEVCORE als Master of Pwn mit 505.000 US-Dollar. Zum ersten Mal lagen die Themenschwerpunkte explizit auf KI: AI Databases, Coding Agents, Local Inferences und NVIDIA-Komponenten. OpenAI Codex fiel viermal, Anthropic Claude Code dreimal, Cursor zweimal. Im Local-Inference-Block trafen erfolgreiche Chains LiteLLM (unter anderem SSRF + Code Injection), LM Studio und Ollama; in den AI Databases Oracle Autonomous AI Database und Chroma. Die betroffenen Anbieter haben 90 Tage Zeit für die Behebung, bevor die Details veröffentlicht werden.

Einordnung

Bisher waren KI-Werkzeuge auf Pwn2Own eine Nebenkategorie. Mit Berlin rückt die LLM-Inferenz-Ebene auf dieselbe Bühne wie Browser und Hypervisoren — und sie hält dem Vergleich nicht stand. Drei Beobachtungen tragen weiter als der Prämienzähler. Erstens sind die meisten Funde klassische Web-Bugs (SSRF, Path Traversal, Code Injection, unsichere Defaults) in den Diensten rund um das Modell, keine Modell-Schwächen. Zweitens kollidierten mehrere Einreichungen bei LiteLLM und Claude Code: verschiedene Teams fanden unabhängig dieselbe Lücke. Das ist ein Indikator für strukturelle Schwächen, nicht für Einzelfehler. Drittens trafen die Coding-Agent-Exploits genau die Werkzeuge, die in den letzten zwölf Monaten in jeden Entwickler-Arbeitsplatz eingezogen sind.

Bedeutung für den Mittelstand

Wer im DACH-Mittelstand Claude Code, Cursor oder Codex auf Entwickler-Laptops oder in CI/CD-Pipelines eingeführt hat, betreibt jetzt Werkzeuge, in denen bewiesene Zero-Days existieren — auch wenn die konkreten Bugs noch unter dem 90-Tage-Embargo stehen. Die Werkzeuge sind nicht mehr „neu und ungeprüft“, sondern „neu und nachweislich angreifbar“. Das Threat-Modell der Entwicklungsumgebung muss diese Schicht enthalten.

Für LiteLLM und vergleichbare LLM-Gateways verschärft sich der Befund. Wer einen Proxy als zentrale Brücke zwischen internen Anwendungen und externen Modell-APIs (OpenAI, Anthropic, Mistral) betreibt, hat damit eine Komponente im Datenpfad, durch die Kundendaten, Geschäftsgeheimnisse oder API-Schlüssel laufen. Eine SSRF-Lücke an dieser Stelle eskaliert zu Remote-Code-Execution. Sie berührt damit DSGVO-Artikel 32 (technische und organisatorische Maßnahmen) und, bei NIS-2-pflichtigen Unternehmen, die Meldepflicht für signifikante Sicherheitsvorfälle nach § 32 BSIG-neu. Die Frage „ist unser LLM-Gateway in der Datenschutz-Folgenabschätzung sauber abgebildet?“ gehört jetzt auf den Tisch des oder der Datenschutzbeauftragten, nicht erst nach Veröffentlichung der Details.

Lokale Inferenz-Stacks wie LM Studio oder Ollama, die im Mittelstand häufig als DSGVO-saubere Alternative zur Cloud eingeführt werden, verdienen denselben Reflex: Lokal ist nicht automatisch sicher. Die Vorteile bleiben (kein Drittland-Transfer, kein Token-Abfluss zu US-Anbietern), die Inferenz-Software selbst gehört aber in das interne Patch-Management und in das Schwachstellen-Monitoring der IT-Abteilung.

Bedeutung für die technische Entwicklung

Die Berliner Ergebnisse markieren einen Reife-Übergang: KI-Tooling wird wie jede andere produktive Software auditierbar. Die Diskussion verschiebt sich von Modell-Sicherheit (Jailbreaks, Prompt Injection, Alignment) auf Stack-Sicherheit — auf die HTTP-Endpunkte, die Tool-Calling-Routen, die MCP-Server, die Vektor-Datenbanken. Genau diese Schicht steht im Zentrum der MCP-/A2A-Standardisierung, die unter der Linux Foundation Agentic AI Foundation Fahrt aufgenommen hat. Die Funde sind das empirische Argument für Signed Agent Cards, sandboxed Tool-Execution und Capability-basierte Berechtigungen, die in den Standards bereits diskutiert werden, jetzt aber mit Druck von der Disclosure-Uhr.

Architektonisch verschiebt sich der Schutzring nach innen. Der Coding Agent läuft mit Lese- und Schreibrechten auf das Repository, hat Netzzugang zu internen APIs und führt modell-vorgeschlagenen Code aus. Compass Security hat in Berlin gezeigt, dass dieser Sprung kein theoretisches Risiko trägt. Wer agentenbasierte Pipelines plant, kommt nicht mehr darum herum, die klassischen DevSecOps-Werkzeuge (SAST, DAST, SBOM, Container-Hardening) auf den Agenten-Teil auszudehnen.

Konkrete Handlungsempfehlung

Inventur in dieser Reihenfolge: Erstens, listen Sie auf, welche Coding-Agenten (Claude Code, Codex, Cursor, Copilot) auf Entwickler-Geräten und in CI/CD-Pipelines laufen und mit welchen Rechten. Zweitens, identifizieren Sie alle LLM-Gateways im Datenpfad und prüfen Sie, ob personenbezogene Daten oder Geschäftsgeheimnisse hindurchlaufen. Drittens, vergewissern Sie sich, dass diese Komponenten im internen Patch-Management und im NIS-2-Vorfall-Meldepfad eingetragen sind. Viertens, abonnieren Sie die ZDI-Advisories für die 90-Tage-Fenster der betroffenen Produkte, damit Sie am Veröffentlichungstag patchen können statt aus der Presse zu erfahren. Architektur-Schritte wie sandboxed Tool-Execution oder Capability-Restriktionen folgen sinnvoll erst nach dieser Inventur.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Quellen

• Zero Day Initiative — Pwn2Own Berlin 2026: Day Three Results and Master of Pwn (16.05.2026)
• Zero Day Initiative — Pwn2Own Berlin 2026: The Full Schedule (13.05.2026)
• Security Affairs — Pwn2Own Berlin 2026, Day One: $523,000 paid out, AI products fall (15.05.2026)
• Security Affairs — Pwn2Own Berlin 2026, Day Two: $385,750 more, Microsoft Exchange falls, running total crosses $900K (15.05.2026)