Xalgorix is a self-hosted penetration-testing platform in which an LLM-driven agent works through a 22-phase methodology against authorized targets, and an independent verifier re-exploits each candidate finding before it is reported. Inconclusive findings are flagged for review rather than marked confirmed. It is aimed at penetration testing, bug bounty work, red-team attack-surface mapping, security research and continuous testing, and the project contrasts it with template scanners (Nuclei), crawling scanners (OWASP ZAP) and commercial DAST on business-logic coverage and exploit verification.
The platform combines the agent with browser automation, terminal tooling, live WebSocket telemetry, finding management with CVSS scoring and branded PDF reports. It runs on the operator's machine with their own LLM provider (OpenAI, Anthropic, DeepSeek, Gemini, Groq, Ollama, MiniMax) or any OpenAI-compatible endpoint, including a LiteLLM proxy that routes to GitHub Copilot, Azure, OpenRouter or local models. Scan data, keys and target information stay on the operator's infrastructure. The default interface is a local web dashboard for starting scans, watching runs, inspecting findings, configuring providers and generating reports, and the same binary runs as a CLI or as a system service with a built-in scheduler. A hosted cloud version runs the same engine with managed credits, out-of-band infrastructure and team workspaces.
Scans target a single host, a wildcard or multi-target set, or a web application through browser-assisted DAST, and the phases can be selected per engagement. A code-scan mode points the agent at a codebase (a Git URL, a local directory or an uploaded archive): review mode traces user input from entry point to dangerous sink and reports source-verified findings without a live target, and provision mode builds and runs the app in the agent's sandbox, then pentests the running instance.
| Phase | Focus |
|---|---|
| 1 | Reconnaissance |
| 2 | Manual vulnerability discovery |
| 3 | Directory and file discovery |
| 4 | CORS and cookie analysis |
| 5 | Authentication and session testing |
| 6 | Injection testing |
| 7 | SSRF testing |
| 8 | IDOR and broken access control |
| 9 | API and GraphQL testing |
| 10 | File upload testing |
| 11 | Deserialization and RCE |
| 12 | Race conditions and business logic |
| 13 | Subdomain takeover |
| 14 | Open redirect testing |
| 15 | Email security testing |
| 16 | Cloud and infrastructure |
| 17 | WebSocket testing |
| 18 | CMS-specific testing |
| 19 | Broken link hijacking and content spoofing |
| 20 | Exploit verification |
| 21 | Novel vulnerability discovery |
| 22 | Final report |
Features
- Exploit verification: an independent verifier reproduces each candidate finding, and inconclusive ones are flagged for review rather than reported as confirmed
- 22-phase methodology: from reconnaissance through injection, SSRF, IDOR, API, upload, RCE, race-condition, takeover and WebSocket testing to exploit verification, novel vulnerability discovery and a final report, with phases selectable per engagement
- Scan modes: single target, wildcard or multi-target enumeration, and browser-assisted DAST for auth flows, forms and JavaScript-rendered content
- Code scanning: review mode audits source without a running target, and provision mode builds and runs the app in a sandbox, then runs whitebox-guided DAST against it
- Bring your own LLM: OpenAI, Anthropic, DeepSeek, Gemini, Groq, Ollama, MiniMax or any OpenAI-compatible endpoint, with model, reasoning effort, retries and iteration limits set from the dashboard
- Web dashboard: scan management, live telemetry of tool calls, agent messages, findings and HTTP activity over WebSockets, severity filters, CVSS details and historical scan recovery
- Reports: branded PDF reports with an executive summary, verified findings, proof-of-concept evidence, remediation guidance and an uploaded logo
- Integrations: AgentMail test inboxes for verification emails and OTP flows, Discord and Telegram notifications with a minimum severity, and Caido for proxy traffic inspection
- Service mode: runs as a system service with a scheduler, binds to loopback only unless external access is configured with authentication, and exposes a REST API
- Runtime safety: resource-aware instance limits, CPU, RAM and disk thresholds, a scan concurrency budget, and rate limits and proxy rotation for outbound traffic
