एक अनाम GitHub खाता बड़ी मात्रा में अघोषित 0-दिनों के PoC डाल रहा है

शोषणों का दायरा और गुणवत्ता

• कई पाठक विशिष्ट PoC (Ghidra, Docker, VLC, c-ares, libssh2, FFmpeg, PHP, nmap, Gitea) की जाँच करते हैं और एक व्यापक मिश्रण पाते हैं:
  • कुछ वास्तव में गंभीर लगते हैं (जैसे, c-ares UAF, libssh2, FFmpeg RCE, कुछ nmap parsing issues, कुछ Rustdesk / logic bugs)।
  • अन्य तुच्छ हैं, गलत वर्गीकृत हैं, या पहले से ही खतरनाक स्थितियाँ मांगते हैं (डिस्क पर binaries को overwrite करना, पहले से PHP code execution होना, केवल test-only code, crash-only cases)।
• कई लोग नोट करते हैं कि “RCE” शब्द कभी-कभी ढीले तौर पर इस्तेमाल होता है (जैसे, SSH root session, या “code execution leads to code execution”), और कई आइटम उच्च-प्रभाव वाली vulnerabilities की बजाय सामान्य bugs जैसे लगते हैं।

“0‑day” किसे कहते हैं

• परिभाषा को लेकर असहमति:
  • एक पक्ष: “0‑day” का मतलब है “vendor या public को पता चलने से पहले जंगली (wild) में exploit किया गया।”
  • दूसरा: “0‑day exploit” उस exploit को कहा जाता है जो तब उपलब्ध हो जब vendor के पास patch करने के लिए शून्य दिन हों; “0‑day vulnerability” तब ऐसी कोई भी vulnerability है जिस पर ऐसा exploit लागू हो।
• कुछ का तर्क है कि इस शब्द को बढ़ा-चढ़ाकर और अत्यधिक इस्तेमाल किया जा रहा है, जिसका अर्थ केवल “कोई भी अप्रकाशित bug” रह गया है।

LLMs, fuzzing, और automation

• बहुत सारे निष्कर्षों को लेकर यह मजबूत संदेह है कि किसी LLM या automated harness ने उन्हें उत्पन्न किया, क्योंकि मात्रा, शैली, और अच्छे-बुरे परिणामों के मिश्रण से ऐसा लगता है।
• कुछ का कहना है कि वर्तमान मजबूत models पहले से ही बड़ी संख्या में वास्तविक bugs खोज सकते हैं; अन्य लोग शिकायत करते हैं कि AI-चालित reports अक्सर severity बढ़ा-चढ़ाकर बताती हैं या non-issues को flag करती हैं।
• चर्चा के अनुसार repo का अपडेटेड README दावा करता है कि एक custom fuzzing workflow है जिसे strict harness के तहत एक AI model ने automate किया है।

Open source बनाम security through obscurity

• एक पक्ष चिंतित है कि open code और LLMs mass exploit discovery को बहुत आसान बना देते हैं और “security through obscurity” में फिर से रुचि जगा सकते हैं।
• दूसरे जवाब देते हैं:
  • हमलावर binaries को वैसे भी reverse-engineer कर सकते हैं।
  • Open source को कई आँखों का लाभ मिलता है और AI-assisted auditing भी मिलती है।
  • OSS को मजबूत करने के लिए केवल एक पक्ष को मजबूत model चाहिए, जबकि proprietary code में एक ही vendor के tools बनाम सभी attackers के tools होते हैं।

Disclosure ethics और defenders पर बोझ

• कुछ लोग बिना vendor को सूचित किए PoCs को सार्वजनिक रूप से bulk में डालना गैर-जिम्मेदाराना मानते हैं, और तर्क देते हैं कि जोखिम users पर आता है, maintainers पर नहीं।
• अन्य कहते हैं:
  • Responsible disclosure बहुत धीमी है, अक्सर बिना इनाम के होती है, और कभी-कभी कानूनी धमकियों से मिलती है।
  • सार्वजनिक dumps exclusive government/black-market use से बचाते हैं और बेहतर practices के लिए मजबूर कर सकते हैं (जैसे, release से पहले AI red-teaming)।
• Security engineers कम-severity या AI-निर्मित reports से आने वाले “noise” की शिकायत करते हैं, लेकिन मानते हैं कि छोटे bugs कभी-कभी गंभीर exploit paths में chain हो सकते हैं।

व्यापक सुरक्षा संदर्भ

• साथ की चर्चाएँ इन विषयों को भी छूती हैं:
  • U.S. SSN/bank-number-आधारित पहचान की नाज़ुकता और ACH के जरिए fraud।
  • Crypto holdings के आसपास kidnapping/physical risks।
  • उच्च-जोखिम parsers (media players, AV engines, network analyzers, CI runners) को sandbox करने की आवश्यकता और यह मानना कि nmap, VLC, और Wireshark जैसे tools high-value targets हैं।