Mobile-Menu

23 Exploits in „bikini/exploitarium“-Repository Wenn der Exploit vor dem Advisory kommt

Ein Gastbeitrag von Christoph Ebeling 8 min Lesedauer

Anbieter zum Thema

FAST LTA GmbH

Eigentlich hatten sich viele für das vergangene Wochenende vorgenommen, die Hitze an einem kühlen Ort zu verbringen. Am Badesee zum Beispiel. Für etliche IT-Teams wurde daraus nichts, da sie stattdessen mit dem Patchen von Softwarepaketen und Bibliotheken beschäftigt gewesen sein dürften.

Durch KI entdeckte Exploits bringen Admins zum Schwitzen, da Angreifer so immer mehr Schwachstellen ausnutzen können, teils lange bevor ein Security Advisory veröffentlicht wird.(Bild: Gemini / Vogel IT-Medien GmbH / KI-generiert)
Durch KI entdeckte Exploits bringen Admins zum Schwitzen, da Angreifer so immer mehr Schwachstellen ausnutzen können, teils lange bevor ein Security Advisory veröffentlicht wird.
(Bild: Gemini / Vogel IT-Medien GmbH / KI-generiert)

Während am letzten Juni-Wochenende die Temperaturen in Deutschland bis auf 41,7 Grad stiegen, rauchten IT-Administratoren weltweit die Köpfe aufgrund eines anderen Umstandes. Denn das kurz zuvor veröffentlichte Repository „bikini/exploitarium“ bedurfte dringender Aufmerksamkeit. Darin fanden sich 23 Proof-of-Concepts (PoCs) und Exploits für bis dahin nicht gemeldete Schwachstellen in weit verbreiteter Software. Demach hatten die Teams allerhand zu tun mit Patching, Workaround oder damit, betroffene Funktionen kurzfristig aus ihren Diensten zu entfernen.

Zu den betroffenen Paketen gehörten unter anderem die Mediabibliothek „FFmpeg“, die SSH-Bibliothek „libssh2“, der asynchrone DNS-Resolver „c-ares“ sowie Docker, PHP, ImageMagick, der HTTP/2-Stack „nghttp2“, der VLC-Player, Firefox und Nmap. Besonders unangenehm sind dabei Bibliotheken wie libssh2 und c-ares. Sie stecken nicht in einer einzelnen Anwendung, sondern oft als eingebettete oder „vendored“ Abhängigkeit in unzähligen Produkten. Eine einzige Sicherheitslücke darin fächert sich über die gesamte Lieferkette auf und taucht in einer Software Bill of Materials (SBOM) schnell an vielen Stellen gleichzeitig auf. Gefunden wurden die Schwachstellen über einen KI-gestützten Fuzzing-Workflow. Die eigentlichen PoCs sind laut Autor allerdings von Hand geschrieben. Solche Vorfälle sind längst keine Ausnahme mehr.

Zum Zeitpunkt der Veröffentlichung existierte für diese Schwachstellen weder eine EUVD- oder CVE-Nummer noch ein Advisory oder Feed-Eintrag. Der einzige öffentliche Exploit war der jeweilige PoC im Repository selbst. Gegen so etwas sind klassische, EUVD-/CVE- und Feed-getriebene Security-Tools per Definition machtlos.

KI beschleunigt Exploits

Dass bei einer Zero-Day-Schwachstelle jede Minute zwischen Bekanntwerden und Reaktion zählt, liegt auf der Hand. Doch auch bei regulären, nicht als Zero-Day eingestuften Schwachstellen wird der Faktor Zeit immer wichtiger.

Denn der Abstand zwischen Vergabe einer ID und öffentlichem Exploit wird seit Monaten kürzer. Erst am 22. Juni hat das BSI dazu eine Cybersicherheitswarnung herausgegeben: Aktuelle KI-Systeme seien inzwischen leistungsfähig genug, Schwachstellen in Software binnen kurzer Zeit umfassend und teils autonom zu erkennen, zu analysieren und in verwertbare Angriffspfade zu überführen. Ausdrücklich auch per Reverse Engineering von Binaries. KI beschleunigt also nicht nur das Finden von Schwachstellen, sondern vor allem deren Weaponization.

Das BSI benennt dabei auch die strukturelle Schieflage, um die es hier geht: Angreifer profitieren von Geschwindigkeit, Skalierung und Automatisierung, während Verteidiger an reale Betriebsgrenzen gebunden bleiben. Testaufwand, Freigabeprozesse, Wartungsfenster, Herstellerabhängigkeiten.

Aus gutem Grund führen viele große Softwarehersteller heute regelmäßig SCA-Scans (Software Composition Analysis) durch und patchen kritische Findings unmittelbar nach Bekanntwerden, häufig mehrmals täglich. Möglich machen das hochoptimierte CI/CD-Pipelines, die neben Unit-, Integrations-, Contract- und End-to-End-Tests auch das Erstellen von Patch-Pull-Requests, Canary-Deployments und automatische Rollbacks im Fehlerfall abdecken.

Sieht man von Zero-Days ab, war das bislang ein vergleichsweise sicherer Prozess: Ein Hersteller bekommt ein Sicherheitsproblem gemeldet, behebt es und veröffentlicht nach dem Patch ein Security Advisory. Oft mit etwas Verzögerung, damit Administratoren Zeit zum Einspielen haben.

Der Untergang der Silent Fixes

Dieser Prozess, in der Praxis auch als Silent Fix bekannt, hat über Jahre gut funktioniert. Vor allem, weil die Entwicklung eines lauffähigen Exploits historisch mehrere Wochen dauerte. Die RAND Corporation bezifferte die mittlere Entwicklungszeit auf rund 22 Tage. In diesem Fenster patchten aufmerksame Administratoren, während Angreifer von der Sicherheitslücke noch nichts wussten.

Dass dieser Prozess in Zeiten von KI nicht mehr trägt, zeigte zuletzt ein Fall im Linux-Kernel. Am 1. April 2026 wurde der Fix für eine lokale Privilege-Escalation-Schwachstelle, später als EUVD­2026-24639 / CVE-2026-31431 („Copy Fail“) geführt, als normaler Commit in den Kernel-Mainline gemergt. Ohne EUVD/CVE, ohne Advisory: ein klassischer Silent Fix. Der Patch war da, die öffentliche Meldung sollte später folgen, damit Distributionen und Administratoren in Ruhe nachziehen können. Die eigentliche Disclosure kam dann auch erst am 29. April, rund vier Wochen später.

Nur genügte in diesem Fenster der Commit selbst. Das zeigte sich kurz darauf an einer eng verwandten Sicherheitslücke derselben Bug-Klasse. Sicherheitsforscher Hyunwoo Kim (@v4bel) meldete „Dirty Frag“ (EUVD-2026-28535 / CVE-2026-43284) an das Kernel-Security-Team und reichte zugleich einen Fix öffentlich über die „netdev“-Mailingliste ein. Der Patch landete am 7. Mai im netdev-Tree. Noch am selben Tag, kaum dass Kim mit den Distributionen ein fünftägiges Embargo vereinbart hatte, veröffentlichte ein unbeteiligter Dritter einen aus genau diesem öffentlichen Patch reverse-engineerten Exploit. Das Embargo brach, bevor die Distributionen ihre Kernel ausliefern konnten.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Und genau das ist der Kern: Der Angreifer brauchte kein Advisory, keine EUVD/CVE und nicht einmal einen verräterischen „RCE“-Hinweis in der Commit-Nachricht. Der Diff selbst war die Schwachstellenbeschreibung.

In Zeiten vor KI wäre das vermutlich nur wenigen aufgefallen. Und die Wahrscheinlichkeit, dass daraus zeitnah ein Exploit entsteht, wäre deutlich geringer gewesen. Durch KI lässt sich genau diese Art von Information jedoch in großem Stil durchsuchen: Large Language Models (LLMs) sind sehr effizient darin, zu analysieren, was ein bestimmter Commit bewirkt. Mit gutem Prompting und einer entsprechenden Research-Pipeline erkennt man so binnen Minuten, wenn in einem Open-Source-Projekt eine Schwachstelle gefixt wird. Dieselbe Fähigkeit hat „exploitarium“ gerade an 23 frischen Zero-Days vorgeführt. Gegen einen öffentlich einsehbaren Fix-Commit ist sie erst recht trivial.

Damit ist das Konzept des Silent Fix praktisch beerdigt. Es beruhte nie darauf, dass der Fix wirklich versteckt war. Es beruhte auf der Annahme, dass Angreifer EUVDs/CVEs und Feeds scannen, nicht Commits. Genau diese Annahme löst KI auf.

Wenn es in der NVD steht, ist es schon zu spät

Nun mag man sich fragen, warum Projekte überhaupt noch auf verzögerte Advisories und Silent Fixes setzen, wenn das Konzept in Zeiten von KI überholt scheint. Die Antwort ist ebenso simpel wie frustrierend: Der Großteil der heute verfügbaren Schwachstellen-Scanner stützt sich im Wesentlichen auf zwei große Datenbanken: die National Vulnerability Database (NVD) des NIST und Open Source Vulnerabilities (OSV) von Google.

Beide werden aus unterschiedlichen Gründen herangezogen. Die NVD liefert offizielle CVSS-Scores und deckt über Common Platform Enumeration Matching auch proprietäre und kommerzielle Software ab, die in keinem Open-Source-Ökosystem liegt. OSV wiederum bildet Schwachstellen exakt auf Paketversionen und Commits ab und erzeugt damit deutlich weniger False Positives. Tools wie Trivy oder Dependency-Track kombinieren deshalb beide Quellen.

Bei OSV handelt es sich allerdings streng genommen nicht um eine eigenständige Advisory-Quelle, sondern um einen Aggregator. OSV bündelt Daten aus Quellen, die das OSV-Schema verwenden, darunter GitHub Security Advisories, die Go Vulnerability Database, RustSec und über zwei Dutzend weitere. Diese Advisories stammen ihrerseits aus den Vendor-Advisories und fließen parallel auch an die NVD, wo sie vom NIST angereichert werden.

Und hier wird es zäh. Während OSV die Daten aus GitHub Security Advisories meist binnen weniger Tage übernimmt, kann die Anreicherung in der NVD durchaus ein bis zwei Wochen dauern. Das NIST selbst hat eingeräumt, dass es das gestiegene Schwachstellenaufkommen nicht mehr bewältigen kann: Die CVE-Einreichungen sind zwischen 2020 und 2025 um 263 Prozent gestiegen, befeuert nicht zuletzt durch KI-gestützte Schwachstellensuche. Seit dem 15. April 2026 reichert das NIST nur noch priorisierte CVEs an: aktiv ausgenutzte Schwachstellen aus dem KEV-Katalog, Software der US-Bundesverwaltung sowie nach Executive Order 14028 als kritisch eingestufte Software. Alle übrigen landen ohne CVSS-Score, ohne CPE und ohne CWE auf dem Status „Not Scheduled“.

Besonders problematisch ist das, weil die NVD eine der wenigen Datenbanken ist, die auch kommerzielle Produkte abdeckt. OSV ist nahezu vollständig auf Open Source beschränkt.

Bei Open-Source-Scannern, die in der CI/CD-Pipeline laufen, kommt ein weiteres Problem hinzu: Sie arbeiten gegen eine lokale Kopie der OSV-Daten, die zunächst aktualisiert werden muss. Je nach Pipeline-Setup gehen so weitere Tage verloren, sodass eine verwundbare Library in der SBOM häufig erst rund eine Woche nach Bekanntwerden als Scan-Signal auftaucht. Und dann muss die Pipeline auch noch getriggert werden.

KI verschiebt den Faktor Zeit ins Negative

All das war lange kein größeres Problem, weil Exploits für reguläre Schwachstellen meist erst Tage bis Wochen nach Veröffentlichung der Reports verfügbar waren. Zero Days waren selten genug, dass sich kritische Fälle wie Log4Shell zusätzlich über Flurfunk und soziale Medien herumsprachen, bevor sie breit ausgenutzt wurden.

Die Beispiele Copy Fail und exploitarium zeigen, dass diese Annahme nicht mehr greift. Die beschriebenen KI-Fähigkeiten zur Schwachstellensuche in Silent Fixes und die durch Coding-Agents zumindest teilautomatisierte Exploit-Generierung bringen das Konzept ins Wanken. Mandiant beziffert die mittlere Time-to-Exploit für 2025 inzwischen auf etwa minus sieben Tage. Die Ausnutzung beginnt im Schnitt also eine Woche vor dem Patch. Und die Zero-Day-Diagnosefähigkeiten aktueller Frontier-Modelle haben das Potenzial, die Lage weiter zu verschärfen.

Fazit

Wir müssen sowohl das Ausliefern von Patches als auch die damit verbundene Veröffentlichung von Security Advisories neu denken. Ein grüner Scan mit einem Open-Source-Scanner ist kein Beleg für eine schwachstellenfreie SBOM. Gleiches gilt für etablierte Threat-Intel-Signale wie Exploit Prediction Scoring System (EPSS) oder Known Exploited Vulnerability (KEV): Auch sie beruhen auf der Annahme, dass die Entwicklung eines Exploits Tage bis Wochen dauert und Angreifer auf öffentlich bekannte Exploit-Datenbanken zugreifen. Die neue Regel lautet stattdessen: Jede Schwachstelle, für die es irgendwo öffentliche Evidenz gibt, ist potenziell ausnutzbar. Sei es ein Vendor-Advisory, eine Release Note, ein Commit-Diff oder auch nur ein GitHub-Issue.

Entsprechend empfiehlt es sich, einen Echtzeit-Scan-Prozess auf Basis der offiziellen Security Advisories zu etablieren. Wird eine kritische Schwachstelle gefunden, für die ein Patch verfügbar ist, muss unmittelbar gepatcht werden. Gibt es keinen Patch, ist zu prüfen, ob die Schwachstelle überhaupt ausnutzbar ist: Ist das System exponiert? Braucht der Angreifer einen Account? Fließen vom Angreifer kontrollierte Daten in die betroffene Library? Wird daraus RCE oder Root? Erst dann greifen Gegenmaßnahmen: Input-Sanitization, der Wechsel auf eine andere Library oder, im schlimmsten Fall, das Offlinenehmen des Service.

Denn der Angreifer liest dieselben frühen Signale, nur schneller und automatisiert. Selbst ein Silent Fix schützt nicht mehr, wenn der Commit-Diff öffentlich ist.

Über den Autor: Christoph Ebeling ist Gründer der IT-Sicherheitsberatung Nexode Consulting und der Application-Security-Plattform Farion.ai. Er berät unter anderem Unternehmen wie Volkswagen, Arvato und die Bundesdruckerei in IT-Sicherheitsfragen.

(ID:50886091)

Weiterführende Inhalte