ExploitHunter.app wird vorgestellt
Eine quelloffene Sicherheitswerkbank, die Scope, Freigaben, Tools und Belege in einem Projekt bündelt.
Inhaltsverzeichnis
- Der Ablauf ist absichtlich langweilig
- Die Belege sind das Produkt
- Acht Modelle, ein Ziel
- Der Benchmark hat den Benchmark erwischt
- Modelle nach Aufgabe routen
- Wo es neben deepsec, VulnHunter und anderen steht
- Lokal ausführen. Verantwortungsvoll nutzen.
- Was als Nächstes kommt
Sicherheitstools haben ein Papierproblem.
Sie finden eine verdächtige Zeile, verpassen ihr ein Schweregrad-Badge und überlassen es dann stillschweigend dir, nachzuweisen, ob sie relevant ist. Der Fund ist „kritisch“. Die Belege sind drei greps im Trenchcoat.
KI-Agenten können diesen Ablauf verkürzen. Sie können aber ebenso aus einer vagen Anweisung, einem Browser und einer Shell sehr viel schneller einen Haufen ungeprüfter Aktivität machen.
ExploitHunter.app setzt dort an, wo der Scanner aufhört. Gib ihm ein autorisiertes Ziel und ein Ziel vor. Der Agent kartiert erreichbare Routen, steuert einen Browser, führt Terminal- und Sicherheitstools aus, prüft eine Hypothese und speichert die Antworten, Screenshots und Transkripte, die den Fund belegen. Anschließend erstellt er aus diesen Belegen einen Bericht mit Zitaten.
Das Projekt ist Open Source und local-first. Du kannst zwischen gehosteten und lokalen Modellen wechseln, ohne Ziel, Freigaben, Verlauf und Belege auf mehrere getrennte Projekte verteilen zu müssen.
Es ist kein Scanner, an den man einen Chatbot geklebt hat. Es ist eine Arbeitsumgebung, die sich merkt, was der Agent versucht hat und was dabei zurückkam.
Über Sicherheit zu reden ist billig. Der nützliche Teil besteht darin, die autorisierte Prüfung auszuführen, den Nachweis zu bewahren und dir den nächsten Schritt zu übergeben.
Der Ablauf ist absichtlich langweilig
Ein ExploitHunter-Projekt durchläuft jedes Mal dieselbe Abfolge:
authorize target → plan → request approval → probe → save evidence → prioritize → report
Die Reihenfolge ist wichtig, weil der Agent tatsächlich Zugriff hat.
Die Autorisierung des Ziels ist Projektzustand, kein Gesprächskontext. Sie steckt nicht in einer Chatnachricht, in der „klar, mach nur“ drei Nachrichten später eine neue Bedeutung bekommen kann. Aktive Scans, Anmeldedatentests, Shell-Befehle und Dateischreibvorgänge liegen allesamt hinter einer Freigabesperre. Freigaben für Befehle mit hoher Auswirkung sind an eine Absicht, ein Projekt und ein Ziel gebunden. Standardmäßig gelten sie nur einmal.
Die Freigabesperren sind kein Kleingedrucktes unter dem Produktversprechen. Sie sind der Grund, warum es vertretbar ist, einen Agenten mit echten Tools zu verbinden. Sie begrenzen das Abdriften des Umfangs, machen Prüfungen weniger abhängig vom Gedächtnis und geben dem Team etwas Besseres als „Die KI hat es gesagt“.
Die Belege sind das Produkt
Die abschließende Antwort des Modells ist nicht die dauerhafte Einheit der Sicherheitsarbeit. Die Belege sind es.
Schließe die Anwendung. Wechsle das Modell. Komm morgen wieder. Die Untersuchung hat ihr Gedächtnis behalten.
ExploitHunter bewahrt den Verlauf von Projekten und Threads, aber der dauerhafte Datensatz ist die Beweiskette: Was wurde versucht, unter welcher Freigabe, gegen welches autorisierte Ziel und was kam dabei zurück? Der Probeversuch, die Antwort, das Befehlsprotokoll, der Screenshot und das unterstützende Artefakt werden zusammen mit dem Finding gespeichert. Der Bericht zitiert die Arbeit, statt den abschließenden Absatz des Modells zu paraphrasieren.
Findings können anschließend in die Nachverfolgung von Maßnahmen, die Analyse von Varianten, die Untersuchung von Angriffspfaden und einen Bericht einfließen, den ein Reviewer Zeile für Zeile prüfen kann.
Es gibt auch einen eigennützigen Vorteil: Debugging hört auf, mystisch zu sein. Wenn der Agent etwas übersieht, Tools übermäßig verwendet, eine Schlussfolgerung erfindet oder ein Artefakt nicht speichert, ist der Fehler im Datensatz sichtbar. Wir korrigieren das Produkt, statt mit einem Screenshot einer Chatblase zu streiten.
Acht Modelle, ein Ziel
Weil jeder Lauf einen Datensatz hinterlässt, wird der Vergleich von Modellen nicht mehr zu einer Bauchgefühl-Übung.
Ich habe acht Modellrouten dieselbe schwierige Juice-Shop-Aufgabe gegeben und sie durch den echten Anwendungspfad von ExploitHunter laufen lassen. Dasselbe Ziel. Dieselben Tools. Derselbe Beweisvertrag. Wenn ein Lauf nicht belegen konnte, welches Modell ausgeführt wurde, oder seine Ausgabe nicht erhalten blieb, bekam er keine Zeile. Benchmarks mögen Mehrdeutigkeit. Rechnungen eher selten.
| Modellroute | Judge | Kosten | Laufzeit | Tool-Aufrufe | Einordnung | |---|---:|---:|---:|---:|---| | Kimi K3 | 10.0/10 | $0.220184 | 223.4s | 8.0 | Höchste Qualität zum niedrigeren Preis der beiden Modelle mit perfekter Punktzahl | | Claude Opus 4.8 | 10.0/10 | $1.633301 | 115.9s | 8.0 | Dieselbe Qualität wie Kimi, fast doppelt so schnell, aber 7,4× so teuer | | DeepSeek V4 Flash | 9.33/10 | $0.058695 | 395.5s | 32.0 | Beste Punktzahl unterhalb der beiden perfekten Routen | | GPT-5.6 Luna | 8.67/10 | $0.016304 | 52.2s | 3.3 | Bestes Ergebnis bei Kosten und Geschwindigkeit | | GPT-5.6 Terra | 8.0/10 | $0.124046 | 107.5s | 6.0 | Bei gleicher Punktzahl günstiger und schneller als Sol | | GPT-5.6 Sol | 8.0/10 | $0.368514 | 229.6s | 10.0 | Leistungsfähig, wird in diesem Ausschnitt aber von Terra dominiert | | Qwen 3.6 Flash | 5.5/10 | $0.085678 | 96.9s | 16.5 | Die günstigere Konfiguration steigerte die Effizienz, bei der Qualität besteht aber weiterhin Rückstand | | GPT OSS 120B | 5.0/10 | $0.062529 | 36.6s | 4.3 | Schnell und günstig, aber für die Standardroute zu volatil |
Lies das als Routing-Policy, nicht als Siegertreppchen.
Luna ist der effiziente Ausgangspunkt. DeepSeek kauft weitere zwei Drittel eines Judge-Punkts für ungefähr das 3,6-Fache der Kosten, die 7,6-fache Laufzeit und die 9,6-fache Zahl an Tool-Aufrufen. Kimi erreicht 10/10 ohne die Opus-Rechnung. Opus erreicht dieselbe Punktzahl rund 108 Sekunden früher, für weitere 1,41 $. GPT OSS bleibt ein beaufsichtigtes Experiment, und Terra spricht bei dieser Aufgabe stärker für sich als Sol.
Nur Luna, DeepSeek und Kimi liegen auf dieser Frontier. Die anderen Routen sind nicht nutzlos. Sie brauchen einen Grund jenseits von Rohpunktzahl und Kosten: Opus kauft Geschwindigkeit, Terra erfüllt eine Einschränkung bei der Modellfamilie ohne die Sol-Rechnung, und GPT OSS ist günstig genug, um unter Aufsicht damit zu experimentieren.
Die ausführliche Fassung mit Methodik, Tool-Budgets, Negativkontrollen und den Situationen, in denen sich Modelle blamieren, obwohl das Befehlsprotokoll die Antwort bereits enthält, steht in Security Agents Need Model Routers, Not Model Rankings.
Der Benchmark hat den Benchmark erwischt
Das wichtigste Ergebnis war kein Modellsieg. Es war ein Fehler des Scorers.
Der erste Bericht zur Archivwiederherstellung gab Kimi 5/10 und GLM 9/10. Die Aufgabe selbst war erfolgreich. Beide Agenten stellten harbor-lantern-47 wieder her, und eine unabhängige hostseitige Prüfung mit unzip -t -P bewies, dass dieses Passwort funktionierte, während die Alternativen dies nicht taten.
Der Judge hatte ein rohes Cybench-Audit für verbotene Tools auf eine native ExploitHunter-Aufgabe angewendet, bei der Evidence-Writes erforderlich waren. Er bestrafte genau das Verhalten, das der Harness verlangte. Derselbe Modellausstoß. Derselbe gespeicherte Trace. Falsche Bewertungsgrundlage.
Nach Entfernung des irrelevanten Audits steigt Kimi von 5/10 auf 10/10. GLM bleibt bei 9/10. Die korrigierten Bewertungen wurden als browser-e2e-llm-judge-corrected in die ursprünglichen Langfuse-Traces zurückgeschrieben, und eine schreibgeschützte API-Prüfung am 17. Juli bestätigte beide Werte anhand der persistierten Trace-IDs.
Diese Fünf-Punkte-Differenz ist der Grund, warum ExploitHunter Traces, Evidence, Scorer-Versionen, Kosten, Token, Tool-Budgets und Harness-Fehler speichert, statt eine Evaluation auf eine heroische Zahl zu reduzieren. Wenn ein Benchmark seine Arbeit nicht zeigen kann, ist er nur ein weiteres Modell, das eine selbstbewusste Behauptung aufstellt.
Modelle nach Aufgabe routen
ExploitHunter unterstützt nicht einfach nur eine lange Liste von Modellanbietern. Es behandelt sie wie eine Werkbank.
Ein Reconnaissance-Durchlauf, eine Exploit-Prüfung, ein Browser-Flow, die Evidence-Synthese und ein Remediation-Vorschlag sind allesamt Security-Arbeit. Es sind aber nicht dieselben Modellaufgaben.
Capital Ones VulnHunter setzt konsequent auf einen für Claude/Claude Code optimierten Workflow zur Quellcodeanalyse. ExploitHunter setzt auf etwas anderes: Projektscope, Freigaben, Tools und Evidence bleiben stabil, während die Modellroute je nach Aufgabe wechselt.
Breite Web-Reconnaissance kann von einem günstigen, schnellen Modell mit einem knappen Tool-Budget profitieren. Ein abgeschottetes lokales Labor kann Datenschutz und Offline-Inferenz bevorzugen. Eine schwierige Validierung oder ein Abschlussbericht kann eine langsamere Frontier-Route rechtfertigen. ExploitHunter verschiebt die Arbeit zwischen diesen Spuren, während Ziel, Verlauf, Freigaben, Tools und Artefakte an ihrem Platz bleiben.
Das richtige Modell ist eine Routing-Entscheidung, kein Logo auf einem Einstellungsbildschirm.
ExploitHunter unterstützt gehostete Anbieter ebenso wie Ollama und LM Studio. Führe es als lokalen Node-Service oder als Electron-Desktop-App aus. Lass die gehosteten API-Schlüssel leer, und ein kompatibles lokales Modell hält die Kandidatenarbeit von kostenpflichtigen Anbietern fern. Verwende eine gehostete Route, wenn Geschwindigkeit oder ein schwierigeres Problem dies rechtfertigt. Halte sensible Arbeit lokal, wenn diese Grenze wichtiger ist, als ein paar Sekunden Laufzeit einzusparen.
Es gibt keinen moralischen Sieg darin, jede Security-Aufgabe an das teuerste verfügbare Modell zu schicken. Es gibt nur eine Rechnung.
Wo es neben deepsec, VulnHunter und anderen steht
ExploitHunter ist bewusst breiter angelegt als ein Harness für Code-Scanner. Es nimmt einen Kandidaten in ein laufendes Zielsystem, untersucht ihn mit Browser- und Terminal-Tools, bewahrt den Beleg auf und übergibt anschließend einen verifizierten Fund an das System, das ihn beheben soll.
Mehrere Projekte decken inzwischen unterschiedliche Teile dieses Workflows ab. Gut so. Security-Teams brauchen Tools, die Arbeit aneinander übergeben, keine weitere Kategorie mit Winner-takes-all-Anspruch.
| Tool | Wo es stark ist | Worin sich ExploitHunter unterscheidet | |---|---|---| | Vercel deepsec | Ein Harness mit Fokus auf Codebases: statische Kandidatenerkennung, Untersuchung durch Coding-Agents, erneute Validierung, Anreicherung und optionales großflächiges Verteilen auf Sandboxen. | Deepsec eignet sich für Repository-Analysen und PR-orientierte Nacharbeit. ExploitHunter stellt ein autorisiertes Forschungsprojekt in den Mittelpunkt, das eine laufende Anwendung, einen Browser, ein Netzwerk-Labor, ein Terminal, persistente Evidence und explizite Freigaben durch den Operator umfassen kann. | | Capital One VulnHunter | Angreiferorientierte Quellcodeanalyse, strukturierte Falsifizierung von Findings und fokussierte Vorschläge zur Behebung im Code. | Die Überschneidung ist real: Evidence und die Reduzierung von False Positives sollten zum Mindeststandard gehören. ExploitHunter ist weniger an ein Coding-Harness oder einen einzelnen Modellpfad gebunden und konzentriert sich stärker darauf, die Untersuchung zu koordinieren, bevor eine Codeänderung vorgeschlagen wird. | | GitHub Security Lab Taskflow Agent | Deklarative, MCP-fähige Taskflows, insbesondere die Triage von CodeQL-Alerts und Variantenanalyse. GitHub berichtet, dass damit ungefähr 30 Schwachstellen aus der Praxis gefunden wurden. | Die richtige Grundlage, wenn der Input ein wiederholbarer Code-Scanning-Workflow ist. ExploitHunter ist die Werkbank für explorative, toolgestützte Forschung, bei der Scope, Freigaben und Evidence eine längere Untersuchung überstehen müssen. | | OpenHands Vulnerability Fixer | Scanner-Ausgaben von Trivy oder anderen Tools in priorisierte Fixes, Tests und Pull Requests überführen. | Eine Remediation-Fabrik. ExploitHunter sitzt früher im Ablauf: feststellen, dass der Fund real ist, den Grund dafür dokumentieren und dem Fix-System ein gut belegtes Problem übergeben. | | Assay | Offline-Policy-Durchsetzung, deterministisches Replay und kryptografische Evidence-Bundles für Agent-Tool-Aufrufe. | Ergänzend, kein Konkurrent. Es ist genau die Art von Laufzeitkontrolle nach dem Prinzip „standardmäßig verweigern“, die agentische Forschungs-Workspaces unterhalb ihrer eigenen Freigabeschicht einsetzen können sollten. |
Ein sinnvoller Stack umfasst wahrscheinlich mehr als eines dieser Tools: Ein Quellcode-Scanner bringt Kandidaten hervor, ein Taskflow triagiert wiederkehrende Muster, ein Research-Workspace verifiziert die gefährlichen Fälle, und ein Remediation-Agent macht aus verifizierter Arbeit einen prüfbaren Patch. Die Übergaben sind wichtiger, als ein Security-Maskottchen zum Sieger zu krönen.
Lokal ausführen. Verantwortungsvoll nutzen.
ExploitHunter steht unter der MIT-Lizenz, ist Open Source und für Arbeiten gedacht, zu denen du autorisiert bist. Das Repository enthält ein lokal gehärtetes Juice-Shop-Ziel und Netzwerk-Labore mit mehreren Services. Damit kannst du den gesamten Workflow durchspielen, ohne einen Agenten auf etwas anzusetzen, das dir nicht gehört.
git clone https://github.com/justsml/ExploitHunter.app.git
cd ExploitHunter.app
pnpm install
cp .env.example .env
pnpm dev
Öffne anschließend http://localhost:3210.
Wähle eine Modellroute, autorisiere ein Ziel, das dir gehört oder für das du ausdrücklich eine Testberechtigung hast, und gib dem Agenten ein Ziel vor. Lass ihn die Arbeit abbilden, genehmige nur die Aktionen, die du tatsächlich ausführen willst, und beobachte, wie sich die Belege ansammeln, statt im Chatverlauf zu verschwinden.
Das ist die langweilige Variante agentischer Security.
Und genau diese Variante möchte ich auf meiner Seite haben, wenn es interessant wird.
Was als Nächstes kommt
Die nächste Aufgabe ist nicht, eine noch größere Behauptung über autonomes Hacking aufzustellen. Es geht darum, den Recherchekreislauf vertrauenswürdiger zu machen: bessere Berichte über wiederholte Durchläufe, strengere Validierung von Belegen, mehr lokale Modelle, klarere Sichtbarkeit der Freigaben und einen schnelleren Weg von einem verifizierten Fund zu einem Patch, den ein Mensch tatsächlich mergen möchte.
Security-Agenten brauchen keinen unbegrenzten Raum zum Improvisieren. Sie brauchen genug Reichweite, um uns zu überraschen, harte Grenzen für diese Reichweite und Belege, wenn sie Erfolg melden.
Das ist ExploitHunter: ein Ort, an dem Modelle, Tools, Labs, Freigaben, Belege und die Nacharbeit auf dasselbe Problem angesetzt werden.
Richte es jetzt auf etwas, das du kaputtmachen darfst.