0xMarcio/cve: Ein Linkindex auf PoC-Repositories statt ein Exploit-Werkzeugkasten
Neueste CVEs mit ihren Proof-of-Concept-Exploits. Die Sicherheitslücke ermöglicht es einem Angreifer, eine böswillige serialisierte Nutzlast auf den Server hochzuladen, was zur Ausführung willkürlichen Codes über Deserialisierung führt, wenn bestimmte Bedingungen erfüllt sind.
Auf einen Blick
- Was ist das?
- 0xMarcio/cve listet pro Jahr die zwanzig zuletzt aktualisierten externen PoC-Repositories mit Sternzahl und Beschreibung. Das Repository selbst enthält laut README keinen Exploit-Code, keine Installationsschritte und keine Auswahlkriterien.
- Für wen ist es gedacht?
- 0xMarcio/cve taugt als Rechercheeinstieg, wenn man schnell sehen will, ob zu einer konkreten CVE-Nummer überhaupt ein öffentliches PoC-Repository existiert, etwa zu CVE-2026-31431 oder CVE-2025-55182.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Ein Index fremder Repositories, kein eigenes Exploit-Material
Die GitHub-Beschreibung von 0xMarcio/cve lautet Latest CVEs with their Proof of Concept exploits. Das klingt nach einer Sammlung von Exploit-Code, und genau hier sitzt das Missverständnis, das man zuerst ausräumen muss. Die README beginnt mit der Überschrift Recently updated Proof-of-Concepts und besteht danach aus Tabellen. Jede Zeile ist ein Verweis auf ein Repository, das jemand anderes betreibt.
Im eigenen Repository liegt nach Ausweis der README kein Exploit-Code. Es gibt keine Skripte zum Aufrufen, keine Nutzlasten und keine Anleitung. Wer ein PoC ausführen will, verlässt 0xMarcio/cve an dieser Stelle und begibt sich auf das verlinkte Repository.
Die README nennt auch keine Installationsschritte und keine Konfigurationsschlüssel, auch deshalb, weil es nichts zu installieren gibt. Der Zugang läuft über zwei Wege: die Tabellen in der README auf dem Branch main und die verlinkte Seite cve.codepwn.win. Was auf dieser Seite gegenüber der README zusätzlich steht, geht aus dem Material nicht hervor.
Aufbau der Jahrestabellen mit vier Spalten
Die README ist nach Jahren gegliedert. Jeder Abschnitt trägt die Überschrift Latest 20 of N Repositories, gefolgt von einer Tabelle mit den Spalten Stars, Updated, Name und Description. Angezeigt werden immer nur zwanzig Zeilen, während die Zahl in der Überschrift den Gesamtbestand des Jahres nennt.
Für 2026 weist die README 498 Repositories aus, für 2025 sind es 581 und für 2024 insgesamt 636. Weitere Jahresabschnitte sind im verfügbaren Auszug nicht mehr enthalten. Das Verhältnis ist bemerkenswert: Wer die README liest, sieht sechzig Zeilen und bekommt dennoch einen Bestand von über eintausendsiebenhundert Einträgen angedeutet.
Die Spalte Updated nennt relative Zeiten, von 28 minutes ago bis 156 days ago. Wie diese Zeitstempel erzeugt werden, ob zur Laufzeit eines Skripts oder zum Zeitpunkt einer Veröffentlichung, erklärt die README nicht. Ebenso wenig steht dort, in welchem Abstand die Liste erneuert wird.
Was in der Liste für 2026 auftaucht
Die Einträge für 2026 decken ein breites Spektrum ab. theori-io/copy-fail-CVE-2026-31431 beschreibt sich als neun Jahre alte Local-Privilege-Escalation im Linux-Kernel, gefunden von Theori. Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC führt dieselbe Schwachstelle weiter und behauptet einen Containerausbruch bis zur Codeausführung auf Knotenebene, validiert auf Alibaba Cloud ACK, Amazon EKS und Google GKE.
Daneben stehen lanicer/cve-2026-41940-PoC als Werkzeug zur Umgehung der Anmeldung bei cPanel und WHM, 0xABCD01/CVE-2026-41089 mit einem Netlogon-CLDAP-Stackpufferüberlauf und der Angabe CVSS 9.8, sowie Chocapikk/CVE-2026-21858, das eine n8n-Kette von unautorisiertem Dateilesen bis zur Codeausführung mit CVSS 10.0 beschreibt. hypnguyen1209/CVE-2026-62911 nennt eine Pre-Auth-RCE auf Exchange, rafabd1/CVE-2026-75604-poc eine Next.js-RCE unter Windows.
Dass die Beschreibungen so unterschiedlich ausfallen, ist aufschlussreich. Manche sind präzise und nennen betroffene Versionen, andere sind leer. CVE-2026-43499 erscheint in der Liste mehrfach, mit PoCs für Android-Kernel und Xiaomi-Geräte. Die README selbst bewertet keinen dieser Einträge.
Die Einträge für 2025: React2Shell, sudo chroot und Fortinet
Im Abschnitt 2025 dominiert ein Thema. CVE-2025-55182 taucht mehrfach auf, unter anderem als React2Shell-CVE-2025-55182-original-poc bei lachlan2k, als Erklärung mit vollständigem RCE-PoC bei msanft und als Detektor mit Chrome-Erweiterung bei emredavut, der zusätzlich CVE-2025-66478 nennt. Malayke stellt mit Next.js-RSC-RCE-Scanner-CVE-2025-66478 einen Kommandozeilen-Scanner bereit.
Abseits davon finden sich lokale Privilege-Escalations: pr0v3rbs und kh4sh3i behandeln CVE-2025-32463, jeweils die Eskalation zu Root über sudo mit der Option chroot. mverschu/CVE-2025-33073 beschreibt einen NTLM-Reflection-Angriff über SMB. absholi7ly/POC-CVE-2025-24813 zielt auf eine Remote-Code-Ausführung in Apache Tomcat über Deserialisierung.
kn0x0x/CVE-2025-32756-POC nennt einen stapelbasierten Pufferüberlauf in mehreren Fortinet-Produkten, hoefler02/CVE-2025-21756 einen Kernel-Exploit für Linux 6.6.75. Diese Häufung derselben CVE-Nummer in mehreren Repositories ist ein Hinweis darauf, was der Index leistet und was nicht: Er zeigt Breite, aber er trifft keine Auswahl zwischen drei Umsetzungen derselben Schwachstelle.
Warum die Spalte Stars hier kein Qualitätsmerkmal ist
Die erste Spalte jeder Tabelle zeigt Sternzahlen der verlinkten Repositories, von 18 bis über 4000. Diese Zahlen verleiten zur Annahme, dass ein häufig markiertes PoC verlässlicher sei als ein selten markiertes. Aus dem Material folgt das nicht. Ein Stern drückt Aufmerksamkeit aus, keine Prüfung.
Hinzu kommt ein methodisches Problem, das in der Liste selbst sichtbar wird. Derselbe Schwachstellenbeleg erscheint mehrfach, bei CVE-2026-31431 sogar mit stark abweichenden Beschreibungen. Dass ein Repository 4051 Sterne hat und ein anderes zu derselben CVE 40, sagt etwas über Bekanntheit, nicht darüber, welche der beiden Umsetzungen auf einem gegebenen System funktioniert.
Die README hilft an dieser Stelle nicht weiter. Es gibt keine Spalte für bestätigte Wirkung, keine Angabe getesteter Versionen und keinen Hinweis darauf, ob ein Eintrag jemals gegen eine ungepatchte Installation gehalten wurde. Wer wissen will, ob ein PoC trägt, muss in das verlinkte Repository wechseln und dort lesen, was steht.
Alternative: der Weg über das Upstream-Advisory
Statt über 0xMarcio/cve einzusteigen, kann man bei der Originalquelle beginnen. In der Liste selbst steckt der Hinweis darauf: Der Eintrag ProDefense/CVE-2025-32433 verweist in seiner Beschreibung direkt auf ein Erlang-OTP-Security-Advisory mit der Kennung GHSA-37cp-fgq5-7wc2. Genau diese Kette ist der bessere Ausgangspunkt, wenn es um Betroffenheit geht.
Der Unterschied liegt im Gegenstand. Ein PoC-Repository zeigt einen Angriffsweg, oft gegen eine bestimmte Version gebaut, häufig ohne Pflege nach der Veröffentlichung. Ein Hersteller-Advisory nennt betroffene und behobene Versionen, und die offiziellen CVE-Einträge liefern die Referenz. Für die Frage, ob ein System gepatcht werden muss, ist das Advisory maßgeblich, nicht die Existenz eines PoC.
Der Index hat dafür den umgekehrten Vorteil: Er zeigt, dass jemand einen Angriffsweg öffentlich gemacht hat. Diese Information fehlt in Advisories meist. Sinnvoll kombiniert man beides, mit dem Advisory zur Bewertung der Betroffenheit und mit dem verlinkten Repository zur Einschätzung des Aufwands.
MIT-Lizenz mit Copyright 2022 Trickest und ihre Reichweite
Das Repository steht unter der MIT-Lizenz, das Urheberrecht ist mit 2022 und dem Namen Trickest angegeben. Die Lizenz erlaubt Nutzung, Kopie, Veränderung, Zusammenführung, Veröffentlichung, Vertrieb, Unterlizenzierung und Verkauf, sofern der Urheberrechts- und der Genehmigungsvermerk in allen Kopien oder wesentlichen Teilen erhalten bleibt.
Die Reichweite dieser Erlaubnis endet an der Grenze des eigenen Repositories. Sie deckt die Tabellendateien, nicht die Inhalte der verlinkten Projekte. Für jedes externe PoC-Repository gilt dessen eigene Lizenz, und die kann von MIT bis zu einer Nutzungsbeschränkung auf Forschungszwecke reichen, wie sie in der Liste bei Einträgen zu CVE-2026-43499 ausdrücklich im Beschreibungstext steht.
Zur Genauigkeit, Rechtmäßigkeit oder Sicherheit der gelisteten Exploits sagt die MIT-Lizenz nichts, und sie enthält keine Support- oder Wartungszusage. Ebenso wenig findet sich im Material ein Verfahren, um neue Einträge einzureichen oder tote Verweise melden zu lassen. Zu klären bleibt auch die Rolle von Python, das in den Metadaten als Sprache ausgewiesen ist: Die README nennt kein Skript und keine Datei, aus der sich die Erzeugung der Liste ablesen ließe.
Redaktionelles Fazit
0xMarcio/cve taugt als Rechercheeinstieg, wenn man schnell sehen will, ob zu einer konkreten CVE-Nummer überhaupt ein öffentliches PoC-Repository existiert, etwa zu CVE-2026-31431 oder CVE-2025-55182. Als Grundlage für eine Freigabe oder einen Patchplan taugt es nicht, weil die README keine Auswahlkriterien, keine Prüfschritte und keine Angaben zur Verlässlichkeit der verlinkten Repositories macht und weil Einträge wie Copy-Fail-CVE-2026-31431-Kubernetes-PoC ihre Wirksamkeit selbst behaupten. Vor jeder Nutzung gehören drei Dinge geprüft: ob das verlinkte Repository überhaupt noch existiert, ob die CVE-Nummer mit dem Upstream-Advisory übereinstimmt, und welche eigene Lizenz das externe Repository trägt, denn die MIT-Lizenz von 0xMarcio/cve deckt nur die Dateien dieses Index.
Community-Notizen