Ethereum Foundation

Ethereum Foundation

Blockchain / Kryptowährungen

Unabhängig belegt

Ethereum Foundation setzt koordinierte KI-Agenten zur Erkennung von Sicherheitslücken in Kernprotokoll ein

Reifegrad: Pilot / Test

Im Register seit 11.07.2026. Wir verfolgen, was aus diesem KI-Einsatz wird.

Wie nutzt Ethereum Foundation KI?

Das Protocol-Security-Team der Ethereum Foundation betreibt koordinierte KI-Agenten, die parallel gegen sicherheitskritischen Protokollcode gerichtet werden, um Schwachstellen zu finden, zu reproduzieren und zu validieren, mit belegtem Fund einer öffentlich gemeldeten Sicherheitslücke.

IT-Sicherheit / Protokoll-SicherheitEinsatz koordinierter KI-Agenten zur Erkennung von Sicherheitslücken in Ethereum-KerninfrastrukturMulti-Agenten-System (Aufklärungs-, Jagd-, Lückenfüll- und Validierungsagenten)

Auf einen Blick

Unternehmen
Ethereum Foundation
Funktion
IT-Sicherheit / Protokoll-Sicherheit
KI-Technik
Multi-Agenten-System (Aufklärungs-, Jagd-, Lückenfüll- und Validierungsagenten)
Ergebnis
CVE-2026-34219: remotely-triggerable panic in libp2p gossipsub, gefunden und gepatcht

Ausgangslage

Das Protocol-Security-Team der Ethereum Foundation ist für die Absicherung von Systemen zuständig, von denen das Netzwerk direkt abhängt: Systemsoftware, kryptografischer Code und Contracts. Klassische Werkzeuge wie Fuzzer liefern bei der Suche nach Schwachstellen lediglich einen Absturz und einen Stack-Trace. Das Team suchte nach einem Ansatz, der strukturiertere und besser nachvollziehbare Ergebnisse produziert.

Vergleichbare Ansätze wurden zur selben Zeit auch anderswo erprobt: Anthropics Frontier Red Team baute einen Agenten, der Property-Based-Tests schreibt und reale Bugs im Python-Ökosystem fand. Cloudflare setzte ein Frontier-Modell in einem Security-Research-Harness gegen eigene Systeme ein. Das Ethereum-Team orientierte sich an diesen Erfahrungen und entwickelte daraus seine eigene Methodik.

Was das Unternehmen konkret macht

Das Protocol-Security-Team betreibt viele KI-Agenten parallel gegen ein einzelnes Ziel. Die Koordination läuft über das Repository selbst, mit gemeinsamem Zustand in der Versionskontrolle, ohne zentralen Koordinationsprozess. Ein Agent schreibt einen Befund dort nieder, wo die anderen ihn sehen können, erledigt die Arbeit und committed.

Die Rollen entstehen aus der entdeckten Arbeit heraus und sind in vier Bereiche gegliedert:

- **Recon** überführt eine Angriffsfläche in konkrete, testbare Hypothesen, nicht „prüfe den Decoder“, sondern eine spezifische Aussage über ein Feld, eine Eigenschaft, die es wahren muss, und einen Beweis, der die Frage entscheiden würde. - **Hunting** nimmt eine Hypothese, verfolgt den Code-Pfad und versucht, einen Reproduzierer zu bauen. - **Gap-filling** wertet aus, was akzeptiert und was abgelehnt wurde, formuliert die nächste Hypothese-Runde und verfolgt die Abdeckung, damit Agenten nicht dieselben Pfade mehrfach abarbeiten. - **Validation** prüft jeden Kandidaten unabhängig, entfernt Duplikate und trifft die Entscheidung.

Diesen Aufbau hat das Team nach eigenen Angaben nicht erfunden: Cloudflare beschreibt dieselben Stufen, Recon, paralleles Hunting, unabhängige Validation, Deduplizierung, Reporting, und dessen Dokumentation hat die Methodik mitgeprägt. Den Koordinationsansatz ohne zentralen Prozess übernahm das Team aus Anthropics Beschreibung, wie eine Flotte von Agenten einen C-Compiler baut.

Technik & Ansatz

Im Unterschied zu klassischen Fuzzern liefert ein KI-Agent nicht nur eine Fehlermeldung, sondern zusätzlich eine Beschreibung der Call-Chain, eine Einschätzung des möglichen Schadens, eine Schweregradbewertung und ein Proof-of-Concept, das gegen den echten Code ausführbar ist.

Jeder Kandidat muss einem festgelegten Schema entsprechen, bevor er als Fund gilt. Dieses Schema umfasst: Zielkomponente und erreichbaren Einstiegspunkt, die Invariante, die gewahrt sein muss, den konkreten Mechanismus, durch den sie gebrochen werden könnte, einen beobachtbaren Beweis (etwa ein Panic, ein Stall oder eine akzeptierte ungültige Eingabe), einen selbstständig lauffähigen Reproduzierer gegen den echten Code sowie einen Deduplication-Key, damit zwei Agenten nicht denselben Befund doppelt verfolgen.

Eine Regel hat dabei besonderes Gewicht: Ein Kandidat gilt erst dann als Fund, wenn ein selbstständiger Reproduzierer existiert, der den Fehler gegen den echten Code zeigt und für jemanden funktioniert, der ihn nicht selbst geschrieben hat.

Das Team benennt drei häufige False-Positive-Muster: ein Panic, der nur im Debug-Build auftritt und in der Produktionsversion nicht reproduzierbar ist; ein Reproduzierer, der intern einen Wert konstruiert, den kein realer Angreifer je erzeugen könnte; und in der Formal-Verification-Arbeit ein Beweis, dessen Aussage trivial wahr ist, unabhängig davon, was der Code tut. Das Volumen ist das Neue: Ein Agent schreibt die nutzlose Variante genauso schnell wie die echte, und genauso selbstsicher.

Ergebnisse

Die Agenten fanden eine reale Sicherheitslücke: einen remotely-triggerable Panic im libp2p-gossipsub-Protokoll, einem zentralen Teil der Peer-to-Peer-Schicht, auf der Ethereums Consensus-Clients laufen. Die Lücke wurde behoben und als CVE-2026-34219 veröffentlicht, mit Namensnennung des Teams.

Ein erheblicher Teil der generierten Kandidaten erwies sich als False Positives, Duplikate oder Befunde außerhalb des Untersuchungsrahmens. Das Team beschreibt dies nicht als Methodenproblem: „Most candidates are wrong, duplicated, or out of scope. That's not a problem with the method, it's how it works. The goal is to quickly filter out the false ones and back the real ones with evidence that's hard to argue with.“

Zusätzlich identifizierte das Team eine Schwäche des Ansatzes: Agenten können bei komplexen Ereignisfolgen versagen, bei denen ein Bug erst nach mehreren Schritten sichtbar wird.

Einordnung

Die Ethereum Foundation fasst die Verschiebung in der Arbeitsverteilung so zusammen: „The time that used to go into finding hypotheses now goes into verifying them at scale. The bottleneck hasn't disappeared, it shifted from finding bugs to trusting the results, and that's a better place for it because that's where human judgment really matters.“

KI hat dabei die Sicherheitsforschenden nicht ersetzt. Die Stiftung formuliert es direkt: „AI hasn't replaced the security researcher, it just shifted the focus of the work.“ Der Anteil der Arbeit, der früher in das Aufstellen von Hypothesen floss, geht nun in deren Überprüfung im Maßstab. Die Validierung durch menschliches Urteilsvermögen bleibt nach Einschätzung des Teams der entscheidende Schritt.

Der vorliegende Bericht des Teams richtet sich ausdrücklich an Client-Teams und Sicherheitsforscherinnen, die denselben Ansatz anwenden wollen, und beschreibt Methoden statt spezifischer Werkzeuge, da sich das Tooling nach eigener Einschätzung zu schnell verändert, um dauerhaft gültig zu sein.


Quellen

Unabhängig belegt

Von einer unabhängigen Quelle (Redaktion/Dritter) berichtet, nicht nur vom Unternehmen oder KI-Anbieter.

KI Cases fasst öffentlich berichtete Einsätze neutral zusammen und verlinkt die Originalquellen. Maßgeblich ist die jeweilige Quelle.


Weitere Fälle

Jede Woche neue KI-Fallstudien

Wie Unternehmen KI wirklich einsetzen: kuratiert, mit Quelle. Der Newsletter startet bald, trag dich ein und sei von Anfang an dabei.

Abonnieren