अनाम GitHub अकाउंट ने बड़ी संख्या में गैर-प्रकाशित 0-day सार्वजनिक किए

 (github.com/bikini)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Exploitarium एक GitHub repository है जो सार्वजनिक proof-of-concept और vulnerability research लेखों को एक जगह इकट्ठा करती है, और नए research items को self-contained folders के रूप में जोड़ा जाता है
  • repository में 7-Zip, AnyDesk, Docker, Firefox, FFmpeg, Ghidra, Gitea, ImageMagick, libssh2, Nmap, OpenVPN, PHP, RustDesk, VLC आदि कई projects से जुड़े PoC folders शामिल हैं
  • मौजूदा standalone PoC repositories से लाए गए items में मूल README और tracking files को सुरक्षित रखा गया, और 23 जून 2026 के fresh GitHub clone के आधार पर 12 repositories और 96 tracked items की पुष्टि की गई, जिसमें कोई mismatch नहीं मिला
  • verification ढीले file system diff से नहीं, बल्कि Git tree data की तुलना से की गई, और relative path, Git object type, tree mode, execute bit, तथा Git blob ID सब एक जैसे होने पर ही pass माना गया
  • repository की सामग्री को अच्छे इरादे वाले public vulnerability research के रूप में बताया गया है, और किसी भी स्थिति में malicious use पर रोक की मांग की गई है

Exploitarium repository का उद्देश्य

  • Exploitarium सार्वजनिक proof-of-concept और vulnerability research writeups को एकीकृत करने वाला archive है
  • अधिकतर folders में वे PoC हैं जो पहले अलग repositories के रूप में मौजूद थे, और इनमें मूल README तथा tracking files सुरक्षित रखी गई हैं
  • नए research items इस repository के भीतर सीधे self-contained folders के रूप में जोड़े जाते हैं
  • repository परिचय में “New drops today ;) Biggest thing yet” वाक्य और Discord संपर्क @ashdfrkl शामिल है

शामिल PoC और research items

  • repository की Contents तालिका में कुल 23 folders सूचीबद्ध हैं
  • मौजूदा standalone repositories से लाए गए items में Source के रूप में commit hash दिखाया गया है
    • 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
  • सीधे जोड़े गए items तिथि के साथ दिखाए गए हैं
    • c-ares-tcp-uaf-calc-poc: 24 जून 2026
    • firefox-smartwindow-private-url-exfil-poc: 24 जून 2026
    • floci-apigateway-vtl-rce-poc: 23 जून 2026
    • ffmpeg-rasc-dlta-calc-poc: 26 जून 2026
    • libssh2-cve-2026-55200-poc: 23 जून 2026
    • libssh2-publickey-list-calc-poc: 25 जून 2026
    • nghttp2-nghttpx-upgrade-queue-poison-poc: 26 जून 2026
    • nmap-ipv6-extlen-wrap-poc: 23 जून 2026
    • php857-streambucket-soap-rce-rpoc: 26 जून 2026
    • rustdesk-session-permission-pocs: 25 जून 2026
    • systeminformer-phsvc-trusted-host-lpe-poc: 24 जून 2026

एकीकरण verification का तरीका

  • Consolidation Check commit hash से सूचीबद्ध मौजूदा standalone repository items पर लागू होता है
  • verification, मौजूदा standalone repositories हटाए जाने से पहले, 23 जून 2026 के fresh GitHub clone पर किया गया था
  • तुलना का तरीका प्रत्येक standalone repository के HEAD tree और Exploitarium के भीतर उसके संबंधित folder को Git tree data के आधार पर मिलाना था
  • हर tracked item को निम्न शर्तें पूरी करनी थीं
    • वही relative path
    • वही Git object type
    • execute bit सहित वही tree mode
    • वही Git blob ID
  • वही Git blob ID होने का मतलब है कि tracked file के bytes पूरी तरह समान हैं

verification के नतीजे और preservation का दायरा

  • verification 12 repositories और 96 tracked items पर की गई और mismatch की संख्या 0 रही
  • repository उन PoC की सामग्री को सुरक्षित रखती है
  • अलग repositories का metadata मूल repository history में बना रहता है
    • stars
    • issues
    • pull requests
    • releases
    • separate Git history
  • सीधे जोड़े गए items को इस repository की commit history से track किया जाता है

उपयोग पर प्रतिबंध

  • repository स्पष्ट रूप से कहती है कि किसी भी परिस्थिति में सामग्री का malicious उपयोग न करें
  • यह भी कहा गया है कि सामग्री का उद्देश्य अच्छे इरादे वाला public vulnerability research है और cyber security के इस क्षेत्र में अधिक लोगों की रुचि बढ़ाना है
  • “Cybercrime is cringe” वाक्य के जरिए दुरुपयोग-निषेध पर जोर दिया गया है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • Ghidra वाला हिस्सा मैंने खुद चलाकर देखा, लेकिन बहुत प्रभावशाली नहीं लगा: https://github.com/bikini/exploitarium/blob/main/ghidra-12.1...
    पहले वाले में Swift tools directory की binary को overwrite कर पाना जरूरी है। अगर आप वही binary overwrite कर दें जिसे Ghidra चलाता है, तो code execution होना तो स्वाभाविक है
    दूसरे वाले पर फैसला करना मुश्किल है क्योंकि मुझे TraceRMI अच्छी तरह नहीं पता, लेकिन यह बात नोट करने लायक है कि “RMI” का मतलब Remote Method Invocation है
    तीसरे को vulnerability कहना मुश्किल है; यह सिर्फ दिखाता है कि native 7zip parser code तक पहुँचा जा सकता है। 7zip parser में bug हो सकता है, लेकिन अगर वह bug नहीं है तो इसका कोई मतलब नहीं

    • nmap वाला हिस्सा सरसरी तौर पर देखने पर संभावित रूप से high severity लग रहा है। असल में शायद कुछ खास न हो, लेकिन parser code के आसपास होने की वजह से jump flow बनाने की संभावना काफी ज्यादा है
      अगर nmap scan करने वाले व्यक्ति से reverse shell लिया जा सके तो यह काफी ironic होगा। अगर tokens unlimited हों, तो मैं Claude से exploit लिखवाता और यह history खंगालता कि इसे संभव किसने बनाया
      मोटे अनुमान से मान लें कि arbitrary code execution (ACE) संभव है, तो अगर observer nmap इस्तेमाल करता है, IPv6 packets के कुछ पैकेटों से observe की जा रही trace को बदलना या nmap इस्तेमाल करने वाले researcher के PC तक पहुँच पाना—यह कुछ वैसा bug होगा जिसे intelligence agencies लपकना चाहेंगी
    • अगर ये सब पहले से ज्ञात CVE ही हों, और इनके भीतर अगला Shai-Hulud छिपा दिया गया हो, ताकि security hobbyists जल्दबाजी में download करते हुए infect हो जाएँ—तो यह काफी मजेदार setup होगा
    • Ghidra वाला मामला काफी weak है, लेकिन जिन c-ares, libssh2, ffmpeg हिस्सों में मेरी दिलचस्पी थी, उन्हें चेक करने पर लगा कि वे latest upstream commits पर भी काम करते हैं, जो अजीब है
    • “Ghidra जिस binary को चलाता है उसे overwrite करने पर code execution होता है”, “RMI remote method invocation है” जैसी बातें देखकर मुझे वह घटना याद आई जब किसी ने साफ तौर पर vibe-coded vulnerability report submit की थी और दावा किया था कि उसने arbitrary SQL execution का तरीका ढूँढ लिया है
      target project खुद SQL server था: https://github.com/tursodatabase/turso/pull/4322
    • Gitea वाला मामला थोड़ा दिलचस्प है, लेकिन real-world exploitation मुश्किल लगती है। अगर Gitea या कोई दूसरा system dedicated VM में काम को ठीक से isolate नहीं करता, तभी यह plausible लगता है
      GitHub Actions भी शायद ऐसा ही व्यवहार करेगा, और ऐसा लगता है कि वे इसे exploitable नहीं मानते क्योंकि assumption है कि user के पास पहले से local में namespace-isolated न किया गया root access है

  • मैंने कुछ को काफी ध्यान से देखा, लेकिन वे इतने रोचक नहीं लगे। Docker वाला बस एक अजीब bug है, vulnerability नहीं, और खास तौर पर “0-day” कहलाने लायक तो नहीं
    nghttp2 के nghttpx वाला मामला ज्यादा दिलचस्प है और phishing में इस्तेमाल हो सकता है, लेकिन request queue non-deterministic है, इसलिए किसी खास victim को target करना व्यवहार में लगभग असंभव है
    VLC वाला तो साफ-साफ crash/bug है। VLC अजीब codecs इस्तेमाल करने पर वैसे भी अक्सर crash हो जाता है, इसलिए यह नया नहीं है
    पता नहीं मैं कुछ miss कर रहा हूँ या नहीं

    • अगर VLC मेरे computer पर crash हो, और मुझे हर दिन भगवान का शुक्रिया अदा करना पड़े कि मैं VLC इस्तेमाल नहीं करता, तो मैं तुरंत power plug निकाल दूँगा और गंभीरता से सोचूँगा कि किन conditions में इसे फिर से चालू करना safe होगा

  • लगता है 0-days-vibes-vulns जैसी कोई नई category चाहिए। vulnerabilities की इस brave new world में em dash पहचानते और संभालते हुए, ऐसा label अच्छा होगा जिससे मेरे जैसे पुराने fossil अब भी सिर्फ हाथ से मेहनत से बनी artisanal vulnerabilities पर ही ध्यान दे सकें
    कुछ-कुछ eggs के free-range label जैसा

    • आजकल की दुनिया में यही सबसे ज्यादा चुभने वाली बात है। हर em dash अब AI signal जैसा treat होता है। पहले यह हमारे लोगों के बीच बड़े सम्मान की निशानी था
    • वह तो em dash भी नहीं है, फिर भी सिर्फ उसी से एक विशाल thread बन गया
    • “और कृपया लिखते समय M dash मत इस्तेमाल करो”… prompt एक घंटे तक खराब output की शिकायतों में खिंचता चला गया

  • AI में हमेशा हर चीज को issue की तरह report करने की tendency होती है। क्योंकि पाए गए “number” को intelligence का पैमाना मान लिया जाता है
    code review में भी यह उतने ही सारे non-issues report करता है। Mythos का output भी इसी तरह inflate हुआ हो सकता है, और लोगों को severity नहीं बल्कि reported issues की संख्या ने चौंकाया हो सकता है

    • मैं open-source developer हूँ और पिछले 2 हफ्तों में मुझे तीन “CWE” notifications मिले। सभी technically सही थे, लेकिन बहुत मामूली चीजें थीं, जैसे “अगर यह debug log file symbolic link हो तो file overwrite हो सकती है”, “अगर user Git output में OSC screen code डाल सके तो screen पर arbitrary data लिख सकता है”
      ये AI models हर चीज को exploit जैसा सुनाने लगे हैं। पता नहीं यह ecosystem के लिए अच्छा है या नहीं
      अब मैं आने वाली हर चीज को ज्यादा शक से देखने लगा हूँ। क्या यह सचमुच exploit है, या बस achievement जमा कर रहे हैं ताकि कह सकें, “पिछले हफ्ते हमने 39 CWE खोले। अपनी ‘security’ company से code audit कराइए”
    • Mythos के साथ सीधे काम कर चुके लोगों से मैंने जो सुना है, उससे यह अलग है। मैंने सुना कि generated vulnerabilities आम तौर पर वास्तविक और meaningful थीं

  • क्या ये सब सच में 0-day हैं? इनमें से काफी पहले से public CVE या upstream में fixed code से आए हुए लगते हैं
    आजकल “0-day” term का मतलब काफी हद तक खत्म हो गया है, और लगता है लोग इसे किसी भी exploit के लिए इस्तेमाल कर देते हैं

    • repository ऐसा दावा करती है
      “यह public exploit PoC और vulnerability research posts का single archive है। जब मैं upload करता हूँ, तब कुछ भी reported नहीं होता। खुद report करें और CVE निकले तो credit ले लें lulz. misuse न करें। मैं और लोगों को इस field में लाने के लिए ऐसा करता हूँ, और हमेशा मुझे यही तरीका सबसे efficient लगा है”
      मोटे तौर पर यह zero-day की definition के करीब तो है। repository की content उस दावे से मेल खाती है या नहीं, यह पूरी तरह अलग सवाल है
    • ऐसी situation में RCE का मतलब भी खत्म हो गया है। “remote” वाला हिस्सा, अगर आम तौर पर कोई मतलब रखता है, तो लगभग SSH root session जैसा होता है

  • AI इतना परिष्कृत हो गया है कि ऐसी चीज़ें ढूंढ सके, इसलिए कुछ समय तक ऐसी सामग्री की बाढ़ आएगी। असली vulnerabilities ठीक हो जाएंगी तो मुझे लगता है कि यह स्वाभाविक रूप से घटेगा
    बेशक कुछ न कुछ हमेशा बचा रहेगा, लेकिन स्तर नीचे जाएगा और मिलने वाले exploits धीरे-धीरे और जटिल होते जाएंगे। अभी यह transition period है

    • “AI इतना स्मार्ट हो गया है कि ढूंढता है” कहना मुझे भ्रामक लगता है। यह “स्मार्ट” नहीं हो रहा, बल्कि खास use cases के लिए और ज्यादा tuned हो रहा है; बेहतर curated datasets, बेहतर harnesses, बेहतर prompts, बेहतर result labeling, और failures व successes की documentation जमा हो रही है
      उम्मीद है कि नतीजे कुल मिलाकर बेहतर होंगे, लेकिन ऐसी anthropomorphic phrasing से लगता है जैसे AI अपने-आप somehow बदल रहा है या evolve कर रहा है
      असल में fundamental research करने वाली academia, commercialization करने वाली industry, और tools व processes को service के रूप में package करने वाले security researchers इसे सक्रिय रूप से बेहतर बना रहे हैं। कोई अलग-थलग “वह चीज़” नहीं है
    • लगता है हम पहले से ही उसी चरण के बीच में हैं, लेकिन घटने के बजाय “reporting” और ज्यादा शोरगुल भरी और अस्पष्ट हो गई है, जिससे वास्तविक threat level या attack vector का आकलन करना और मुश्किल हो गया है
    • हर software update ऐसी vulnerabilities को नया बनाता है या फिर से वापस ले आता है
    • सच कहें तो execution complexity भी समय के साथ धीरे-धीरे कम बाधा बनती जा रही है

  • ऐसा लगता है जैसे कोई large language model चला रहा है और उसके results publish कर रहा है। इसमें “system binary बदल दो तो arbitrary code execution!” जैसी हास्यास्पद चीज़ों से लेकर सच हो सकने वाली चीज़ों तक, बहुत तरह का मिश्रण है, इसलिए ऐसा लगता है
    LLM को “exploit ढूंढो और PoC लिखो” जैसा prompt देने पर अक्सर ऐसे ही results आते हैं
    पिछले 15 वर्षों की Metasploit reports पर train कर दिया जाए, तो लगता है यह वही bugs ढूंढ सकता है जिन्हें लोगों ने नए code में फिर से लिख दिया है
    [1] https://en.wikipedia.org/wiki/Metasploit

  • एक लाइन है कि किसी भी परिस्थिति में इस repository की सामग्री का malicious use न करें। कहा गया है कि यह अच्छे इरादे से की गई public vulnerability research है, और मकसद है कि ज्यादा लोग cybersecurity के इस क्षेत्र को explore करने में दिलचस्पी लें
    The Anarchist Cookbook की किसी recipe से पहले वाला संदेश याद आता है: “यह बहुत खतरनाक है, इसलिए इसे बिल्कुल न करें। इसे करने का तरीका यह है”

    • पुरानी किताब में “…maliciously” जैसा शब्द नहीं था, है ना?

  • security vulnerability के तौर पर यह बहुत impressive नहीं है। ज्यादातर को बस simple bugs कहना बेहतर होगा

    • सहमत नहीं हूं। FFmpeg code execution सच में बहुत nasty है
    • हर vulnerability आखिरकार बस एक bug ही होती है

  • ऐसा लगता है कि existing CVEs की दोबारा लिखी गई copies और नई low-severity चीज़ों का मिश्रण है। मैं इन्हें low severity इसलिए कह रहा हूं क्योंकि लगता है user को पहले से ही मूल रूप से खतरनाक action करना होगा
    जल्दी से देखकर मेरी 2 cents राय है
    फिर भी ये interesting findings हैं। मुझे लगता है कुछ को chain किया जाए तो वे ज्यादा गंभीर हो सकते हैं
    उदाहरण के लिए ovpn वाला मामला और Windows में VPN app को default open app के रूप में register करना, या openvpn:// जैसे URL locations के लिए protocol opener के रूप में register करने के बाद iframe और चालाक social engineering को मिलाना—शायद ऐसा कुछ हो सकता है। बस अचानक आया विचार है

    • यही confusing हिस्सा है। कुछ low-level noise जैसे लगते हैं, लेकिन कुछ सच में critical हैं
      Floci, libssh2, c-ares, FFmpeg, PHP वाले मामले सभी असली लगते हैं
      वहीं Ghidra वाला उतना नहीं। लगता है यह कोई आधा-चल रहा research folder था और शायद उसे बस वैसे ही publish कर दिया गया