Un compte GitHub anonyme publie en masse des 0-day non divulgués

 (github.com/bikini)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Exploitarium est un dépôt GitHub qui rassemble au même endroit des proof-of-concept publics et des articles de recherche sur les vulnérabilités, et les nouvelles entrées de recherche y sont ajoutées sous forme de dossiers autonomes
  • Le dépôt contient des dossiers PoC liés à de nombreux projets, dont 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk et VLC
  • Les éléments migrés depuis d’anciens dépôts PoC autonomes conservent leur README d’origine et leurs fichiers suivis ; sur la base d’un fresh GitHub clone au 23 juin 2026, 12 dépôts et 96 éléments suivis ont été vérifiés sans aucune divergence
  • La vérification n’a pas reposé sur un diff lâche du système de fichiers, mais sur une comparaison des données Git tree ; le chemin relatif, le type d’objet Git, le tree mode, le bit d’exécution et le Git blob ID devaient tous être identiques pour être validés
  • Le dépôt précise que ses contenus relèvent d’une recherche publique sur les vulnérabilités menée de bonne foi et exige, en toute circonstance, l’interdiction d’un usage malveillant

Objectif du dépôt Exploitarium

  • Exploitarium est une archive unifiée de proof-of-concept publics et de writeups de recherche sur les vulnérabilités
  • La plupart des dossiers contiennent des PoC qui existaient auparavant dans des dépôts séparés, avec conservation du README d’origine et des fichiers suivis
  • Les nouvelles entrées de recherche sont ajoutées directement dans ce dépôt sous forme de dossiers autonomes
  • La présentation du dépôt inclut la phrase « New drops today ;) Biggest thing yet » ainsi que le contact Discord @ashdfrkl

PoC et éléments de recherche inclus

  • Le tableau Contents du dépôt liste au total 23 dossiers
  • Les éléments importés depuis d’anciens dépôts autonomes affichent un commit hash comme source
    • 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
  • Les éléments ajoutés directement sont indiqués avec leur date
    • c-ares-tcp-uaf-calc-poc : 24 juin 2026
    • firefox-smartwindow-private-url-exfil-poc : 24 juin 2026
    • floci-apigateway-vtl-rce-poc : 23 juin 2026
    • ffmpeg-rasc-dlta-calc-poc : 26 juin 2026
    • libssh2-cve-2026-55200-poc : 23 juin 2026
    • libssh2-publickey-list-calc-poc : 25 juin 2026
    • nghttp2-nghttpx-upgrade-queue-poison-poc : 26 juin 2026
    • nmap-ipv6-extlen-wrap-poc : 23 juin 2026
    • php857-streambucket-soap-rce-rpoc : 26 juin 2026
    • rustdesk-session-permission-pocs : 25 juin 2026
    • systeminformer-phsvc-trusted-host-lpe-poc : 24 juin 2026

Méthode de vérification de la consolidation

  • Consolidation Check s’applique aux anciens dépôts autonomes listés avec un commit hash
  • La vérification a été effectuée sur un fresh GitHub clone daté du 23 juin 2026, avant la suppression des anciens dépôts autonomes
  • La méthode consiste à comparer les données Git tree du tree HEAD de chaque dépôt autonome avec le dossier correspondant dans Exploitarium
  • Chaque élément suivi devait satisfaire aux conditions suivantes
    • même chemin relatif
    • même type d’objet Git
    • même tree mode, y compris le bit d’exécution
    • même Git blob ID
  • Un Git blob ID identique signifie que les octets du fichier suivi sont identiques

Résultats de la vérification et périmètre de conservation

  • La vérification a porté sur 12 dépôts et 96 éléments suivis, avec 0 divergence
  • Le dépôt conserve le contenu de ces PoC
  • Les métadonnées des dépôts séparés restent dans l’historique des dépôts d’origine
    • stars
    • issues
    • pull requests
    • releases
    • historique Git séparé
  • Les éléments ajoutés directement sont suivis dans l’historique des commits de ce dépôt

Restrictions d’usage

  • Le dépôt indique explicitement que les contenus ne doivent en aucun cas être utilisés de manière malveillante
  • Il précise que ces contenus ont pour but une recherche publique sur les vulnérabilités menée de bonne foi et de susciter davantage d’intérêt pour ce domaine de la cybersécurité
  • La formule « Cybercrime is cringe » souligne l’interdiction des usages abusifs

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Avis sur Hacker News

  • J’ai regardé côté Ghidra en l’essayant moi-même, et ce n’est pas très impressionnant : https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
    Le premier point suppose de pouvoir écraser un binaire dans le répertoire des outils Swift. Si vous écrasez un binaire que Ghidra exécute, il est évident que vous obtenez une exécution de code
    Pour le deuxième, je ne connais pas bien TraceRMI, donc c’est difficile à juger, mais il faut noter que « RMI » signifie Remote Method Invocation (appel de méthode à distance)
    Le troisième est difficile à considérer comme une vulnérabilité : il montre seulement qu’il est possible d’atteindre le code natif du parseur 7zip. Il peut y avoir un bug dans le parseur 7zip, mais sans cela, ça ne veut rien dire

    • Côté nmap, en survolant, cela semble potentiellement de gravité élevée. En pratique, ce n’est peut-être pas grand-chose, mais comme c’est autour du code de parsing, il y a pas mal de chances de pouvoir construire un flux de sauts
      Ce serait ironique de pouvoir obtenir un reverse shell sur quelqu’un qui lance un scan nmap. Si j’avais des tokens illimités, je demanderais à Claude d’écrire un exploit et j’irais fouiller l’historique pour voir qui a rendu ça possible
      En supposant, très grossièrement, qu’une exécution arbitraire de code (ACE) soit possible, cela ressemblerait au genre de bug qui ferait envie aux services de renseignement : si un observateur utilise nmap, quelques paquets IPv6 pourraient modifier la trace observée, ou donner accès au PC d’un chercheur qui utilise nmap
    • Ce serait assez drôle si tout cela n’était en fait que des CVE déjà connues, avec le prochain Shai-Hulud caché dedans, en attendant que des amateurs de sécurité les téléchargent à la hâte et se fassent infecter
    • Le cas Ghidra est assez faible, mais j’ai vérifié les éléments qui m’intéressaient côté c-ares, libssh2, ffmpeg, et ils semblent tous fonctionner même avec les derniers commits upstream, ce qui est étrange
    • En lisant des phrases comme « si vous écrasez un binaire que Ghidra exécute, vous obtenez une exécution de code » ou « RMI signifie appel de méthode à distance », cela me rappelle quelqu’un qui avait soumis un rapport de vulnérabilité manifestement vibe-codé, affirmant avoir trouvé une méthode d’exécution SQL arbitraire
      Le projet visé était un serveur SQL : https://github.com/tursodatabase/turso/pull/4322
    • Le cas Gitea est un peu intéressant, mais semble difficile à exploiter réellement. Ce serait plausible si Gitea ou un autre système n’isole pas correctement les tâches dans une VM dédiée
      GitHub Actions ferait probablement quelque chose de similaire, et il semble qu’on ne considère pas cela comme exploitable en partant du principe que l’utilisateur a déjà des droits root locaux non isolés par namespace

  • J’en ai examiné quelques-uns assez attentivement, et ce n’était pas si intéressant. Le cas Docker est juste un bug bizarre, pas une vulnérabilité, et encore moins quelque chose qu’on pourrait appeler un « 0-day »
    Le cas nghttpx de nghttp2 est plus intéressant et pourrait servir au phishing, mais la file de requêtes est non déterministe, donc cibler une victime précise est pratiquement impossible
    Le cas VLC est juste un crash/bug évident. VLC plante déjà souvent avec des codecs bizarres, ce n’est pas nouveau
    Je ne sais pas si j’ai raté quelque chose

    • Si VLC plante sur mon ordinateur, et si je devais remercier Dieu chaque jour de ne pas utiliser VLC, je débrancherais immédiatement la machine et je réfléchirais sérieusement aux conditions dans lesquelles il serait sûr de la rallumer

  • Il faudrait une nouvelle catégorie du genre 0-days-vibes-vulns. Dans ce brave nouveau monde des vulnérabilités, ce serait bien d’avoir une étiquette qui repère et traite les em dashes, afin que les vieux fossiles comme moi puissent encore se redresser uniquement devant des vulnérabilités artisanales, faites à la main avec soin
    Un peu comme le label des œufs de poules élevées en plein air

    • C’est ce qui m’agace le plus dans le monde actuel. Tous les em dashes sont maintenant traités comme un signal d’IA. Autrefois, c’était une grande marque de respect parmi notre peuple
    • En plus, ce n’est même pas un em dash, et ça a suffi à générer un énorme fil de discussion
    • « Et par pitié, n’utilise pas de M dash quand tu écris »… l’entrée continue pendant une heure à s’étendre sur des résultats médiocres

  • L’IA a toujours tendance à tout signaler comme un problème. Parce que le « nombre » de découvertes est perçu comme une mesure d’intelligence
    Dans les revues de code, elle signale aussi énormément de non-problèmes. La sortie de Mythos a pu être gonflée de la même manière, et ce qui a surpris les gens n’était peut-être pas la gravité, mais le nombre de problèmes signalés

    • Je suis développeur open source, et ces deux dernières semaines j’ai reçu trois alertes « CWE ». Elles étaient toutes correctes, mais il s’agissait de choses très mineures comme « si ce fichier de log de debug est un lien symbolique, on peut écraser un fichier » ou « si l’utilisateur peut insérer des codes d’écran OSC dans la sortie Git, il peut écrire des données arbitraires à l’écran »
      Ces modèles d’IA font sonner tout comme un exploit. Je ne sais pas si c’est bon pour l’écosystème
      Maintenant, je regarde tout ce qui arrive avec davantage de suspicion. Est-ce un vrai exploit, ou juste quelqu’un qui accumule les trophées pour dire « nous avons ouvert 39 CWE la semaine dernière, confiez l’audit de votre code à notre entreprise de “sécurité” » ?
    • Ce n’est pas ce que j’ai entendu de personnes ayant travaillé directement avec Mythos. D’après elles, les vulnérabilités générées étaient généralement réelles et significatives

  • Est-ce que tout cela correspond vraiment à des 0-days ? Beaucoup semblent venir de CVE déjà publiques ou de code corrigé en upstream
    De nos jours, le terme « 0-day » a largement perdu son sens, et les gens semblent souvent l’utiliser pour désigner n’importe quel exploit

    • Le dépôt affirme ceci
      « C’est une archive unique de PoC d’exploits publics et d’articles de recherche sur des vulnérabilités. Au moment où je les publie, rien n’a été signalé. Vous pouvez les signaler vous-même et prendre le crédit quand un CVE sortira, lulz. Ne les exploitez pas. Je fais cela pour attirer davantage de gens dans ce domaine, et j’ai toujours considéré que cette méthode était la plus efficace »
      C’est à peu près proche de la définition d’un zero-day. Que le contenu du dépôt corresponde à cette affirmation est une toute autre question
    • Dans ce genre de situation, même RCE a perdu son sens. La partie « à distance » signifie généralement, quand elle a un sens, quelque chose comme une session SSH root

  • L’IA devenant assez sophistiquée pour trouver ce genre de choses, ce type de ressources va affluer pendant un moment. Je pense que cela diminuera naturellement quand les vraies vulnérabilités seront corrigées
    Bien sûr, il en restera toujours dans une certaine mesure, mais je m’attends à ce que leur niveau baisse et que les exploits découverts deviennent de plus en plus complexes. Nous sommes actuellement dans une période de transition

    • Je pense que l’expression « l’IA devient assez intelligente pour les trouver » prête à confusion. Ce n’est pas qu’elle « devient intelligente », c’est plutôt qu’elle est davantage adaptée à des usages précis, avec des jeux de données mieux sélectionnés, de meilleurs harnais de test, de meilleurs prompts, un meilleur étiquetage des résultats, et une documentation accumulée des échecs comme des réussites
      J’espère que les résultats s’amélioreront globalement, mais ce genre de formulation anthropomorphique donne l’impression que l’IA elle-même change ou évolue somehow
      En réalité, ce sont les universitaires qui font de la recherche fondamentale, l’industrie qui la commercialise, et les chercheurs en sécurité qui empaquettent les outils et les processus sous forme de services, qui travaillent activement à l’améliorer. Il n’existe pas de « chose » indépendante
    • On semble déjà être en plein dedans, mais plutôt que de diminuer, le « signalement » devient plus bruyant et plus ambigu, ce qui rend plus difficile l’évaluation du niveau réel de menace ou des vecteurs d’attaque
    • Toute mise à jour logicielle crée ou réintroduit de telles vulnérabilités
    • Honnêtement, la complexité d’exécution devient elle aussi une barrière de plus en plus basse avec le temps

  • On dirait que quelqu’un fait tourner un grand modèle de langage et publie les résultats. Cela donne cette impression parce qu’il y a un mélange très large, allant de choses ridicules comme « exécution de code arbitraire si vous remplacez un binaire système ! » à des éléments qui pourraient être réels
    C’est typiquement le genre de résultats qu’on obtient en donnant à un LLM un prompt du style « trouve un exploit et écris un PoC »
    Si on l’entraîne sur les rapports Metasploit des 15 dernières années, j’imagine qu’il pourrait trouver les mêmes bugs que des gens ont réintroduits dans du nouveau code
    [1] https://en.wikipedia.org/wiki/Metasploit

  • Il y a une mention disant de ne pas utiliser les ressources de ce dépôt à des fins malveillantes, en aucune circonstance. Il s’agirait d’une recherche sur les vulnérabilités publiée de bonne foi, avec pour objectif d’inciter davantage de personnes à s’intéresser à ce domaine de la cybersécurité
    Ça me rappelle le message devant certaines recettes de The Anarchist Cookbook : « C’est vraiment dangereux, ne faites surtout pas ça. Voici comment faire »

    • Dans l’ancien livre, il n’y avait pas la mention « …à des fins malveillantes », si ?

  • Comme vulnérabilités de sécurité, ce n’est pas très impressionnant. Pour la plupart, il vaudrait mieux parler de simples bugs

    • Pas d’accord. L’exécution de code dans FFmpeg est vraiment vicieuse
    • Toutes les vulnérabilités ne sont au final que des bugs

  • On dirait un mélange de copies réécrites de CVE existants et de nouvelles failles de faible gravité. Je les qualifie de faible gravité parce qu’il semble que l’utilisateur doive déjà faire quelque chose d’intrinsèquement risqué
    C’est mon avis à deux centimes après un rapide survol
    Cela dit, ce sont quand même des découvertes intéressantes. Je pense que certaines pourraient devenir plus graves si elles étaient chaînées
    Par exemple, pour le cas ovpn, on pourrait imaginer enregistrer l’app VPN comme application d’ouverture par défaut sous Windows, ou comme gestionnaire de protocole pour des URL du type openvpn://, puis combiner ça avec une iframe et un peu de social engineering bien ficelé. C’est juste une idée qui me vient

    • C’est là que c’est déroutant. Certains éléments ressemblent à du bruit de bas niveau, mais d’autres sont vraiment critiques
      Les cas Floci, libssh2, c-ares, FFmpeg, PHP semblent tous bien réels
      En revanche, le cas Ghidra, pas vraiment. J’ai l’impression que c’était peut-être un dossier de recherche à moitié avancé, publié tel quel