Anonymer GitHub-Account veröffentlicht massenhaft unveröffentlichte 0-Days

 (github.com/bikini)
1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Exploitarium ist ein GitHub-Repository, das öffentliche Proofs of Concept und Beiträge zur Schwachstellenforschung an einem Ort bündelt; neue Forschungseinträge werden als eigenständige Ordner hinzugefügt
  • Das Repository enthält PoC-Ordner zu mehreren Projekten, darunter 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk und VLC
  • Einträge, die aus früheren eigenständigen PoC-Repositories verschoben wurden, behalten die ursprünglichen READMEs und nachverfolgten Dateien bei; auf Basis frischer GitHub-Clones vom 23. Juni 2026 wurden 12 Repositories und 96 nachverfolgte Einträge geprüft, ohne Abweichungen
  • Die Prüfung verglich nicht per lockerem Dateisystem-Diff, sondern anhand von Git-Tree-Daten; relative Pfade, Git-Objekttypen, Tree-Mode, Ausführungsbit und Git-Blob-ID mussten jeweils identisch sein
  • Die Materialien im Repository werden ausdrücklich als gut gemeinte öffentliche Schwachstellenforschung bezeichnet; böswillige Nutzung ist in jedem Fall untersagt

Zweck des Exploitarium-Repositorys

  • Exploitarium ist ein konsolidiertes Archiv öffentlicher Proofs of Concept und Writeups zur Schwachstellenforschung
  • Die meisten Ordner enthalten PoCs, die früher als separate Repositories existierten, wobei die ursprünglichen READMEs und nachverfolgten Dateien erhalten bleiben
  • Neue Forschungseinträge werden direkt in diesem Repository als eigenständige Ordner hinzugefügt
  • Die Repository-Beschreibung enthält den Satz „New drops today ;) Biggest thing yet“ sowie den Discord-Kontakt @ashdfrkl

Enthaltene PoCs und Forschungseinträge

  • Die Contents-Tabelle des Repositorys listet insgesamt 23 Ordner auf
  • Aus bestehenden eigenständigen Repositories übernommene Einträge werden mit einem Commit-Hash als Source angezeigt
    • 7zip-rar5-motw-chain-poc
    • anydesk-printer-com-impersonation-poc
    • docker-cp-copyout-destination-escape
    • flowise-mcp-env-case-bypass-poc
    • ghidra-12.1.2-rce-ace-calc-poc
    • gitea-act-runner-container-options-poc
    • imagemagick-gs-delegate-hijack-poc
    • lunar-modrinth-chain-poc
    • mybb-limited-acp-to-admin
    • objdump-dlx-calc-poc
    • openvpn-connect-echo-script-ace-poc
    • vlc-vp9-reschange-crash-poc
  • Direkt hinzugefügte Einträge werden mit Datum angezeigt
    • c-ares-tcp-uaf-calc-poc: 24. Juni 2026
    • firefox-smartwindow-private-url-exfil-poc: 24. Juni 2026
    • floci-apigateway-vtl-rce-poc: 23. Juni 2026
    • ffmpeg-rasc-dlta-calc-poc: 26. Juni 2026
    • libssh2-cve-2026-55200-poc: 23. Juni 2026
    • libssh2-publickey-list-calc-poc: 25. Juni 2026
    • nghttp2-nghttpx-upgrade-queue-poison-poc: 26. Juni 2026
    • nmap-ipv6-extlen-wrap-poc: 23. Juni 2026
    • php857-streambucket-soap-rce-rpoc: 26. Juni 2026
    • rustdesk-session-permission-pocs: 25. Juni 2026
    • systeminformer-phsvc-trusted-host-lpe-poc: 24. Juni 2026

Methode der Konsolidierungsprüfung

  • Der Consolidation Check gilt für bestehende eigenständige Repository-Einträge, die per Commit-Hash aufgeführt sind
  • Die Prüfung wurde an frischen GitHub-Clones vom 23. Juni 2026 durchgeführt, bevor die bestehenden eigenständigen Repositories entfernt wurden
  • Verglichen wurden jeweils der HEAD-Tree des einzelnen Repositorys und der entsprechende Ordner in Exploitarium anhand von Git-Tree-Daten
  • Jeder nachverfolgte Eintrag musste folgende Bedingungen erfüllen
    • gleicher relativer Pfad
    • gleicher Git-Objekttyp
    • gleicher Tree-Mode einschließlich Ausführungsbit
    • gleiche Git-Blob-ID
  • Eine gleiche Git-Blob-ID bedeutet, dass die Bytes der nachverfolgten Datei identisch sind

Prüfergebnis und Umfang der Bewahrung

  • Die Prüfung umfasste 12 Repositories und 96 nachverfolgte Einträge; Abweichungen gab es 0
  • Das Repository bewahrt die Inhalte dieser PoCs
  • Die Metadaten der separaten Repositories verbleiben in der Historie der ursprünglichen Repositories
    • Stars
    • Issues
    • Pull Requests
    • Releases
    • separate Git-Historie
  • Direkt hinzugefügte Einträge werden über die Commit-History dieses Repositorys nachverfolgt

Nutzungsbeschränkung

  • Das Repository weist ausdrücklich darauf hin, die Materialien unter keinen Umständen böswillig zu verwenden
  • Als Zweck der Materialien werden gut gemeinte öffentliche Schwachstellenforschung und das Ziel genannt, mehr Menschen für diesen Bereich der Cybersicherheit zu interessieren
  • Der Satz „Cybercrime is cringe“ unterstreicht das Verbot von Missbrauch

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Die Ghidra-Sache habe ich mir durch eigenes Ausprobieren angesehen, und sie ist nicht besonders beeindruckend: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
    Beim ersten Punkt muss man ein Binary im Swift-Tool-Verzeichnis überschreiben können. Wenn man ein Binary überschreibt, das Ghidra ausführt, ist Codeausführung natürlich die Folge.
    Beim zweiten Punkt kenne ich mich mit TraceRMI nicht gut genug aus, um es zu beurteilen, aber erwähnenswert ist, dass „RMI“ für Remote Method Invocation steht.
    Der dritte Punkt ist schwer als Schwachstelle zu werten; er zeigt nur, dass nativer 7zip-Parser-Code erreichbar ist. Im 7zip-Parser könnten Bugs stecken, aber ohne einen solchen ist das bedeutungslos.

    • Die nmap-Sache sieht nach kurzem Durchsehen potenziell nach hohem Schweregrad aus. In Wirklichkeit könnte es auch nichts Besonderes sein, aber weil es in der Nähe von Parser-Code liegt, ist die Chance recht hoch, einen Sprungfluss zu erzeugen.
      Es wäre schon ironisch, wenn man bei jemandem, der einen nmap-Scan durchführt, eine Reverse Shell bekommen könnte. Wenn Tokens unbegrenzt wären, würde ich Claude wohl einen Exploit schreiben lassen und dann in der Historie nachsehen, wer das ermöglicht hat.
      Grob spekuliert, unter der Annahme, dass Arbitrary Code Execution (ACE) möglich ist: Wenn ein Beobachter nmap nutzt, wäre das eher ein Bug, auf den Nachrichtendienste scharf wären – etwa weil man mit ein paar IPv6-Paketen den beobachteten Trace verändern oder auf den PC eines Forschers zugreifen könnte, der nmap verwendet.
    • Es wäre ziemlich lustig, wenn das alles bereits bekannte CVEs wären, in denen der nächste Shai-Hulud versteckt ist, und man nur darauf wartet, dass Sicherheits-Hobbyisten sie hastig herunterladen und sich infizieren.
    • Die Ghidra-Sache ist ziemlich schwach, aber als ich mir die für mich interessanten Fälle bei c-ares, libssh2, ffmpeg angesehen habe, scheinen sie alle auch mit den neuesten Upstream-Commits noch zu funktionieren, was seltsam ist.
    • Aussagen wie „Wenn man ein Binary überschreibt, das Ghidra ausführt, kommt es zu Codeausführung“ oder „RMI ist Remote Method Invocation“ erinnern mich an den Fall, in dem jemand einen offensichtlich vibe-gecodeten Schwachstellenbericht eingereicht und behauptet hat, eine Methode für beliebige SQL-Ausführung gefunden zu haben.
      Das Zielprojekt war ein SQL-Server: https://github.com/tursodatabase/turso/pull/4322
    • Der Gitea-Fall ist ein wenig interessant, wirkt aber schwer praktisch auszunutzen. Plausibel wäre es nur, wenn Gitea oder ein anderes System Jobs nicht sauber in einer dedizierten VM isoliert.
      GitHub Actions dürfte sich ähnlich verhalten, und offenbar geht man nicht davon aus, dass es ausnutzbar ist, wenn ein Nutzer lokal bereits Root-Rechte hat, die nicht per Namespace isoliert sind.

  • Ich habe mir einige davon ziemlich gründlich angesehen, und sie waren nicht sonderlich interessant. Der Docker-Fall ist einfach ein merkwürdiger Bug, keine Schwachstelle, und schon gar nichts, was man „0-day“ nennen würde.
    Der nghttpx-Fall in nghttp2 ist interessanter und könnte für Phishing nutzbar sein, aber die Request-Queue ist nicht deterministisch, sodass es praktisch fast unmöglich ist, ein bestimmtes Opfer zu treffen.
    Der VLC-Fall ist einfach ein offensichtlicher Crash/Bug. VLC crasht ohnehin häufig bei seltsamen Codecs, das ist also nichts Neues.
    Vielleicht übersehe ich etwas.

    • Wenn VLC auf meinem Rechner crashen würde, und wenn ich jeden Tag Gott dafür danken müsste, dass ich VLC nicht benutze, würde ich sofort den Stecker ziehen und ernsthaft darüber nachdenken, unter welchen Bedingungen es sicher wäre, ihn wieder einzuschalten.

  • Es scheint eine neue Kategorie wie 0-days-vibes-vulns zu brauchen. In dieser schönen neuen Welt der Schwachstellen wäre ein Label hilfreich, das em dashes erkennt und aussortiert, damit alte Fossilien wie ich weiterhin nur bei liebevoll von Hand gefertigten, handwerklichen Schwachstellen aufhorchen müssen.
    So ähnlich wie ein Freiland-Label für Eier.

    • Das ist derzeit das Nervigste überhaupt. Jeder em dash gilt inzwischen als KI-Signal. Früher war er unter unserem Volk ein Zeichen großen Respekts.
    • Das ist nicht einmal ein em dash, und allein daraus ist ein riesiger Thread entstanden.
    • „Und bitte benutze beim Schreiben keine M dash“ … die Eingabe zieht sich eine Stunde lang mit Gerede über minderwertige Ergebnisse hin.

  • KI neigt immer dazu, alles als Issue zu melden. Die „Anzahl“ der Funde wird als Maß für Intelligenz gesehen.
    Beim Code Review meldet sie genauso viele Nicht-Issues. Auch die Mythos-Ausgabe könnte auf diese Weise aufgebläht sein, und vielleicht hat eher die Zahl der gemeldeten Issues die Leute erschreckt als deren Schweregrad.

    • Ich bin Open-Source-Entwickler und habe in den letzten zwei Wochen drei „CWE“-Meldungen bekommen. Alle waren zwar korrekt, aber es waren lauter sehr triviale Dinge wie „Wenn diese Debug-Logdatei ein symbolischer Link ist, kann man eine Datei überschreiben“ oder „Wenn ein Nutzer OSC-Bildschirmcodes in Git-Ausgaben einfügen kann, kann er beliebige Daten auf den Bildschirm schreiben“.
      Diese KI-Modelle lassen alles wie einen Exploit klingen. Ich weiß nicht, ob das gut für das Ökosystem ist.
      Inzwischen betrachte ich alles Eingehende mit mehr Misstrauen: Ist das ein echter Exploit, oder sammelt jemand nur Erfolge, um sagen zu können: „Wir haben letzte Woche 39 CWEs eröffnet, beauftragt unsere ‚Security‘-Firma mit einem Code-Audit“?
    • Das unterscheidet sich von dem, was ich von Leuten gehört habe, die direkt mit Mythos gearbeitet haben. Mir wurde gesagt, die generierten Schwachstellen seien überwiegend real und relevant gewesen.

  • Sind das alles echte 0-days? Viele scheinen aus bereits veröffentlichten CVEs oder aus Code zu stammen, der upstream schon gefixt wurde.
    Heutzutage hat der Begriff „0-day“ weitgehend seine Bedeutung verloren; oft wirkt es so, als würden Leute ihn für beliebige Exploits verwenden.

    • Das Repository behauptet Folgendes:
      „Ein zentrales Archiv für öffentliche Exploit-PoCs und Schwachstellenforschungsartikel. Zum Zeitpunkt meines Uploads war nichts davon gemeldet. Ihr könnt es selbst melden und euch die Anerkennung holen, wenn ein CVE herauskommt, lulz. Nicht missbrauchen. Ich mache das, um mehr Leute in dieses Feld zu bringen, und habe diese Methode immer für die effizienteste gehalten.“
      Das liegt ungefähr nahe an der Definition eines Zero-Day. Ob der Inhalt des Repositories zu dieser Behauptung passt, ist eine ganz andere Frage.
    • In solchen Situationen hat auch RCE seine Bedeutung verloren. Der Teil „remote“ bedeutet, wenn er überhaupt etwas heißt, meist eher so etwas wie eine SSH-Root-Session.

  • Da KI inzwischen ausgereift genug ist, um solche Dinge zu finden, wird es eine Weile eine Flut solcher Materialien geben. Ich denke, sobald die echten Schwachstellen behoben sind, wird das von selbst weniger werden.
    Natürlich wird immer ein gewisser Rest bleiben, aber ich erwarte, dass das Niveau sinkt und die gefundenen Exploits immer komplexer werden. Im Moment befinden wir uns in einer Übergangsphase.

    • Ich finde, die Formulierung „KI ist schlau genug geworden, um das zu finden“ führt in die Irre. Es geht nicht darum, dass sie „schlauer“ wird, sondern darum, dass sie stärker auf bestimmte Einsatzzwecke zugeschnitten wird: besser kuratierte Datensätze, bessere Harnesses, bessere Prompts, bessere Ergebnis-Labels sowie mehr Dokumentation von Fehlschlägen und Erfolgen.
      Ich hoffe, dass die Ergebnisse insgesamt besser werden, aber solche anthropomorphisierenden Formulierungen lassen es so klingen, als würde sich die KI selbst somehow verändern oder weiterentwickeln.
      Tatsächlich sind es die akademische Forschung, die Grundlagenarbeit leistet, die Industrie, die sie kommerzialisiert, und Sicherheitsforscher, die Tools und Prozesse zu Services bündeln, die aktiv Verbesserungen vorantreiben. Ein eigenständiges „Es“ gibt es nicht.
    • Wir scheinen bereits mitten in dieser Phase zu sein, aber statt weniger zu werden, wird das „Reporting“ lauter und unklarer, sodass es schwieriger geworden ist, das tatsächliche Bedrohungsniveau oder die Angriffsvektoren einzuschätzen.
    • Jedes Software-Update erzeugt solche Schwachstellen neu oder führt sie wieder ein.
    • Ehrlich gesagt wird auch die Komplexität der Ausführung mit der Zeit zu einer immer niedrigeren Hürde.

  • Es sieht so aus, als würde jemand ein großes Sprachmodell laufen lassen und die Ergebnisse veröffentlichen. Die Bandbreite reicht von lächerlichen Dingen wie „wenn man das System-Binary austauscht, gibt es beliebige Codeausführung!“ bis hin zu Sachen, die echt sein könnten, deshalb wirkt es so.
    Das sind typische Ergebnisse, wenn man einem LLM einen Prompt wie „finde einen Exploit und schreibe einen PoC“ gibt.
    Wenn man es mit Metasploit-Berichten der letzten 15 Jahre trainiert, könnte es vermutlich dieselben Bugs finden, die Leute wieder in neuen Code hineingeschrieben haben.
    [1] https://en.wikipedia.org/wiki/Metasploit

  • Es gibt einen Hinweis, dass die Materialien in diesem Repository unter keinen Umständen böswillig verwendet werden sollen. Es handle sich um gut gemeinte Veröffentlichung von Schwachstellenforschung, mit dem Ziel, mehr Menschen dafür zu interessieren, diesen Bereich der Cybersicherheit zu erkunden.
    Das erinnert mich an die Botschaft vor irgendeinem Rezept aus The Anarchist Cookbook: „Das ist wirklich gefährlich, also mach es auf keinen Fall. So geht es.“

    • Stand in dem alten Buch nicht kein „… böswillig“?

  • Als Sicherheitslücken sind sie nicht besonders beeindruckend. Die meisten sollte man wohl eher einfach als simple Bugs bezeichnen.

    • Stimme ich nicht zu. Codeausführung in FFmpeg ist wirklich fies.
    • Jede Schwachstelle ist am Ende einfach nur ein Bug.

  • Es sieht nach einer Mischung aus umgeschriebenen Kopien bestehender CVEs und neueren Dingen mit niedriger Schwere aus. Ich nenne sie deshalb niedrig, weil der Nutzer offenbar ohnehin schon etwas im Kern Gefährliches tun muss.
    Nur meine zwei Cent nach einem schnellen Überfliegen.
    Interessante Funde sind es trotzdem. Einige könnten meiner Meinung nach durch Chaining ernster werden.
    Beim ovpn-Fall könnte man zum Beispiel die VPN-App unter Windows als Standard-App zum Öffnen registrieren oder als Protokoll-Handler für URL-Schemata wie openvpn:// eintragen und das dann mit einem iframe und geschicktem Social Engineering kombinieren. Nur ein Gedanke, der mir gerade kam.

    • Genau das ist der verwirrende Punkt. Ein Teil wirkt wie Low-Level-Rauschen, aber manches ist wirklich kritisch.
      Die Fälle Floci, libssh2, c-ares, FFmpeg, PHP sehen alle echt aus.
      Der Ghidra-Fall dagegen eher nicht. Ich frage mich, ob das ein halb fertiger Forschungsordner war, der einfach unverändert veröffentlicht wurde.