ExploitHunter.app की घोषणा

एक ओपन-सोर्स सुरक्षा कार्यक्षेत्र, जो दायरा, अनुमोदन, टूल और साक्ष्य को एक ही प्रोजेक्ट में रखता है।

विषय-सूची

• यह चक्र जानबूझकर उबाऊ है
• एविडेंस ही उत्पाद है
• आठ models, एक target
• Benchmark ने benchmark को पकड़ लिया
• Task के हिसाब से models route करें
• deepsec, VulnHunter और बाकी tools के साथ इसकी जगह
• इसे local चलाएं। जिम्मेदारी से इस्तेमाल करें।
• आगे क्या है

सिक्योरिटी टूल्स को कागजी कार्रवाई की समस्या है।

वे कोई संदिग्ध लाइन खोजते हैं, आपको severity badge थमा देते हैं, और चुपचाप यह साबित करने का काम आपके ऊपर छोड़ देते हैं कि मामला सच में महत्वपूर्ण है या नहीं। Finding “high” है। उसका evidence है ट्रेंच कोट पहने तीन greps।

AI एजेंट इस workflow को छोटा कर सकते हैं। वे एक अस्पष्ट निर्देश, ब्राउज़र और shell को कहीं तेज़ी से बढ़ते हुए ऐसे activity-pile में भी बदल सकते हैं, जिसे किसी ने verify नहीं किया हो।

ExploitHunter.app वहीं से शुरू होता है जहाँ scanner रुक जाता है। उसे कोई authorized target और एक goal दें। एजेंट reachable routes का मानचित्र बनाता है, ब्राउज़र चलाता है, terminal और security tools इस्तेमाल करता है, किसी hypothesis को test करता है, और finding को support करने वाले responses, screenshots और transcripts save करता है। फिर वह उसी evidence को citations वाले report में बदल देता है।

यह open source और local-first है। आप hosted और local models के बीच बदल सकते हैं, बिना target, approvals, history और evidence को अलग-अलग projects में बाँटे।

यह chatbot चिपका हुआ scanner नहीं है। यह ऐसा workbench है जो याद रखता है कि एजेंट ने क्या आज़माया और उसके जवाब में क्या मिला।

सिक्योरिटी पर बात करना आसान है। उपयोगी हिस्सा है authorized check चलाना, proof को सुरक्षित रखना, और आपको अगला कदम देना।

यह चक्र जानबूझकर उबाऊ है

ExploitHunter project हर बार उसी sequence से गुजरता है:

authorize target → plan → request approval → probe → save evidence → prioritize → report

क्रम महत्वपूर्ण है, क्योंकि एजेंट की पहुँच वास्तविक है।

Target authorization project state है, conversational context नहीं। यह किसी chat message में नहीं रहती, जहाँ “हाँ, आगे बढ़ो” का अर्थ तीन turns बाद कुछ और निकले। Active scans, credential tests, shell commands और file writes—सब approval gate के पीछे रहते हैं। High-impact command approvals किसी intent, project और target से बंधी होती हैं। डिफ़ॉल्ट रूप से वे single-use होती हैं।

Approval gates product pitch के नीचे लिखी fine print नहीं हैं। यही वे चीज़ें हैं जो किसी agent को real tools से जोड़ना उचित बनाती हैं। वे scope drift को सीमित करती हैं, reviews को memory पर कम निर्भर बनाती हैं, और टीम को “AI ने ऐसा कहा” से बेहतर आधार देती हैं।

एविडेंस ही उत्पाद है

Model का final answer security work की durable unit नहीं है। Evidence है।

App बंद कर दें। Models बदल दें। कल वापस आएँ। Investigation की memory फिर भी बनी रहती है।

ExploitHunter प्रोजेक्ट और थ्रेड हिस्ट्री बनाए रखता है, लेकिन टिकाऊ रिकॉर्ड evidence pipeline है: क्या आज़माया गया, किस approval के तहत, किस authorized target पर, और क्या वापस मिला। Probe, response, command transcript, screenshot और supporting artifact—सब finding के साथ store किए जाते हैं। Report model के closing paragraph को paraphrase करने के बजाय किए गए काम को cite करती है।

इसके बाद findings remediation tracking, variant analysis, attack-path work और ऐसी report में जा सकती हैं जिसे reviewer line by line जाँच सके।

इसका एक selfish फायदा भी है: debugging रहस्यमय नहीं रहती। जब agent कुछ miss करता है, tools का जरूरत से ज्यादा इस्तेमाल करता है, कोई conclusion गढ़ता है, या artifact save करने में विफल रहता है, तो failure record में दिखाई देता है। हम chat bubble के screenshot से बहस करने के बजाय product ठीक करते हैं।

आठ models, एक target

क्योंकि हर run एक record छोड़ता है, models की तुलना अब vibes exercise नहीं रह जाती।

मैंने आठ model routes को वही कठिन Juice Shop task दिया और उन्हें ExploitHunter के real application path से चलाया। वही target। वही tools। वही evidence contract। अगर कोई run यह साबित नहीं कर सका कि कौन-सा model चला था, या अपना output preserve नहीं कर सका, तो उसे table में row नहीं मिली। Benchmarks को ambiguity भले पसंद हो। Invoices को आम तौर पर नहीं।

| Model route | Judge | Cost | Runtime | Tool calls | निष्कर्ष | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4s | 8.0 | दो perfect scorers में कम कीमत पर सबसे ऊँची quality | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9s | 8.0 | Kimi जैसी ही quality, लगभग दोगुनी speed, 7.4× cost | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5s | 32.0 | दोनों perfect routes से नीचे का सबसे अच्छा score | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2s | 3.3 | cost और speed का सबसे अच्छा परिणाम | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5s | 6.0 | उसी score पर Sol से सस्ता और तेज | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6s | 10.0 | सक्षम, लेकिन इस slice में Terra से पीछे | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9s | 16.5 | सस्ती setting ने efficiency सुधारी, लेकिन quality अब भी पीछे | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6s | 4.3 | तेज और सस्ता, लेकिन default route के लिए बहुत volatile |

इसे podium नहीं, routing policy की तरह पढ़ें।

Luna efficient starting point है। DeepSeek लगभग 3.6× cost, 7.6× runtime और 9.6× tool calls के बदले judge score में दो-तिहाई point और खरीदता है। Kimi, Opus वाला bill चुकाए बिना 10/10 तक पहुँचता है। Opus वही score लगभग 108 seconds पहले हासिल करता है, लेकिन इसके लिए $1.41 और देने पड़ते हैं। GPT OSS supervised experiment ही बना रहता है, और इस task पर Terra, Sol से मजबूत case बनाता है।

इस frontier पर केवल Luna, DeepSeek और Kimi हैं। बाकी routes बेकार नहीं हैं। उन्हें raw score और cost के बाहर कोई कारण चाहिए: Opus speed खरीदता है, Terra Sol का bill चुकाए बिना model-family constraint पूरा करता है, और GPT OSS इतना सस्ता है कि supervision के तहत इसे explore किया जा सकता है।

लंबा version—जिसमें methodology, tool budgets, negative controls और वे तरीके शामिल हैं जिनसे models तब खुद को शर्मिंदा करते हैं जब command transcript में answer पहले से मौजूद हो—Security Agents Need Model Routers, Not Model Rankings में है।

Benchmark ने benchmark को पकड़ लिया

सबसे महत्वपूर्ण परिणाम किसी model की जीत नहीं था। वह scorer failure था।

पहली archive-recovery report ने Kimi को 5/10 और GLM को 9/10 दिया। Task खुद सफल रहा था। दोनों agents ने harbor-lantern-47 recover किया, और एक independent host-side unzip -t -P check ने साबित कर दिया कि वह password काम करता था, जबकि बाकी alternatives नहीं करते थे.

Judge ने ऐसे native ExploitHunter task पर raw-Cybench forbidden-tool audit लागू किया था, जिसमें evidence writes आवश्यक थे। उसने ठीक उसी व्यवहार पर penalty लगा दी, जिसकी harness ने मांग की थी। Model output वही था। Stored trace वही था। Rubric गलत था।

Irrelevant audit हटाने के बाद Kimi 5/10 से 10/10 पर पहुंच गया। GLM 9/10 पर ही रहा। Corrected scores को original Langfuse traces में browser-e2e-llm-judge-corrected के रूप में वापस लिखा गया, और 17 जुलाई को किए गए read-only API check ने persisted trace IDs पर दोनों values की पुष्टि की।

यह पांच अंकों का swing ही वजह है कि ExploitHunter traces, evidence, scorer versions, cost, tokens, tool budgets और harness failures store करता है, बजाय evaluation को एक heroic number में flatten करने के। अगर benchmark अपना काम दिखा नहीं सकता, तो वह बस एक और model है जो पूरे आत्मविश्वास से दावा कर रहा है।

Task के हिसाब से models route करें

ExploitHunter केवल model providers की लंबी सूची support नहीं करता। वह उन्हें एक bench की तरह treat करता है।

Reconnaissance pass, exploit check, browser flow, evidence synthesis और remediation proposal — ये सभी security work हैं। लेकिन ये एक ही model task नहीं हैं।

Capital One’s VulnHunter Claude/Claude Code-optimized source-analysis workflow पर एक coherent bet लगाता है। ExploitHunter अलग bet लगाता है: project scope, approvals, tools और evidence को स्थिर रखें, जबकि job के हिसाब से model route बदलता रहे।

Broad web reconnaissance को tight tool budget वाला सस्ता, तेज model लाभ दे सकता है। Constrained local lab privacy और offline inference को प्राथमिकता दे सकता है। कठिन validation या final report के लिए धीमा frontier route उचित हो सकता है। ExploitHunter काम को इन lanes के बीच move करता है, जबकि target, history, approvals, tools और artifacts अपनी जगह बने रहते हैं।

सही model एक route decision है, settings screen पर लगा कोई logo नहीं।

ExploitHunter hosted providers के साथ-साथ Ollama और LM Studio को भी support करता है। इसे local Node service या Electron desktop app के रूप में चलाएं। Hosted API keys खाली छोड़ें और compatible local model candidate work को paid providers से दूर रखेगा। Speed या कठिन problem इसे justify करे तो hosted route इस्तेमाल करें। जब वह boundary run से कुछ seconds बचाने से अधिक महत्वपूर्ण हो, तो sensitive work local रखें।

हर security task को उपलब्ध सबसे महंगे model के पास भेजने में कोई moral victory नहीं है। सिर्फ invoice है।

deepsec, VulnHunter और बाकी tools के साथ इसकी जगह

ExploitHunter जानबूझकर code-scanner harness से व्यापक है। यह किसी candidate को running target तक ले जाता है, browser और terminal tools से उसकी जांच करता है, proof को सुरक्षित रखता है, और फिर verified finding उस system को सौंपता है जिसे उसे ठीक करना चाहिए।

कई projects अब इस workflow के अलग-अलग हिस्से cover करते हैं। अच्छी बात है। Security teams को ऐसे tools चाहिए जो एक-दूसरे को काम सौंपें, न कि एक और winner-take-all category।

| टूल | कहाँ यह मजबूत है | ExploitHunter कहाँ अलग है | |---|---|---| | Vercel deepsec | Codebase-first harness: static candidate discovery, coding-agent investigation, revalidation, enrichment और optional large-scale sandbox fanout। | Deepsec repo analysis और PR-oriented follow-up के लिए उपयुक्त है। ExploitHunter एक authorized research project को केंद्र में रखता है, जिसमें running app, browser, network lab, terminal, persistent evidence और explicit operator approvals शामिल हो सकते हैं। | | Capital One VulnHunter | Attacker-first source analysis, findings का structured falsification और focused code-remediation proposals। | Overlap वास्तविक है: evidence और false-positive reduction baseline होने चाहिए। ExploitHunter किसी coding harness या एक model path से कम बंधा है, और code change propose करने से पहले investigation coordinate करने पर अधिक केंद्रित है। | | GitHub Security Lab Taskflow Agent | Declarative, MCP-enabled taskflows, खासकर CodeQL-alert triage और variant analysis। GitHub के अनुसार, इसने लगभग 30 real-world vulnerabilities खोजने में मदद की है। | जब input एक repeatable code-scanning workflow हो, तब यही सही foundation है। ExploitHunter exploratory, tool-using research का workbench है, जहां scope, approvals और evidence को लंबी investigation के दौरान सुरक्षित रहना होता है। | | OpenHands Vulnerability Fixer | Trivy या अन्य tools के scanner output को prioritized fixes, tests और pull requests में बदलना। | यह remediation factory है। ExploitHunter loop में इससे पहले आता है: finding के वास्तविक होने की पुष्टि करना, उसका कारण record करना और fixing system को अच्छी तरह समर्थित problem सौंपना। | | Assay | Offline policy enforcement, deterministic replay और agent tool calls के लिए cryptographic evidence bundles। | Complementary है, competitor नहीं। यह उस तरह का deny-by-default runtime control है, जिसे agentic research workspaces अपनी approval layer के नीचे इस्तेमाल कर सकें। |

एक उपयोगी stack में शायद इनमें से एक से अधिक tools होंगे: source scanner candidates उठाएगा, taskflow recurring patterns को triage करेगा, research workspace खतरनाक cases को verify करेगा, और remediation agent verified work को reviewable patch में बदलेगा। Handoffs, security mascot का ताज पहनाने से अधिक महत्वपूर्ण हैं।

इसे local चलाएं। जिम्मेदारी से इस्तेमाल करें।

ExploitHunter MIT licensed, open source है और उस work के लिए बनाया गया है जिसे करने की आपको authorization है। Repository में local hardened Juice Shop target और multi-service network labs शामिल हैं, इसलिए आप किसी ऐसी चीज पर agent point किए बिना पूरा workflow चला सकते हैं जो आपकी अपनी नहीं है।

git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev

फिर http://localhost:3210 खोलें।

कोई model route चुनें, अपने स्वामित्व वाले या स्पष्ट अनुमति के साथ test किए जाने वाले target को authorize करें, और agent को एक goal दें। उसे काम को map करने दें, उन actions को approve करें जिन्हें आप वास्तव में चलाना चाहते हैं, और chat history में गायब होने देने के बजाय evidence को जमा होते हुए देखें।

Agentic security का यह उबाऊ संस्करण है।

और जब दिलचस्प हिस्सा शुरू होता है, तो यही वह संस्करण है जिसे मैं अपनी तरफ रखना चाहता हूं।

आगे क्या है

अगला काम autonomous hacking के बारे में कोई बड़ा दावा करना नहीं है। काम है research loop को अधिक भरोसेमंद बनाना: बेहतर repeat-run reporting, अधिक कड़ा evidence validation, local models का व्यापक coverage, approval visibility को स्पष्ट करना, और verified finding से उस patch तक पहुंचने का तेज रास्ता बनाना जिसे कोई इंसान merge करना चाहे।

Security agents को improvisation के लिए असीमित जगह की जरूरत नहीं है। उन्हें इतना reach चाहिए कि वे हमें चौंका सकें, उस reach के चारों ओर कड़ी सीमाएं चाहिए, और success का दावा करने पर उसका proof चाहिए।

यही ExploitHunter है: models, tools, labs, approvals, evidence और follow-up को एक ही समस्या पर लगाने की एक जगह।

अब इसे किसी ऐसी चीज पर चलाएं जिसे तोड़ने की आपको अनुमति है।