Xalgorix Uses AI and a 22-Phase Methodology for Automated Penetration Testing

Xalgorix is an open-source, self-hosted penetration testing platform that uses an AI agent to discover vulnerabilities and a separate verification process to test whether each finding can be reproduced.

The platform follows a 22-phase methodology covering reconnaissance, authentication, injection flaws, access control, APIs, cloud infrastructure, exploit verification, and report generation.

Its main selling point is a verification-first workflow. Xalgorix attempts to reproduce suspected vulnerabilities before marking them as confirmed, although organizations should still require human review before acting on automated findings.

Xalgorix separates vulnerability discovery from verification

Most automated scanners identify patterns that may indicate a vulnerability. Security teams must then determine whether the finding represents a real and exploitable weakness.

Xalgorix uses an autonomous LLM agent for discovery and a separate verifier for exploitation checks. A candidate issue must pass this second stage before the platform labels it as confirmed.

This approach follows a central principle in the OWASP Web Security Testing Guide: security testing should combine structured checks with evidence that demonstrates the actual impact of a weakness.

Stage	Purpose	Expected output
Discovery	Identify possible vulnerabilities and attack paths	Candidate findings
Analysis	Review context, application behavior, and possible impact	Prioritized test cases
Verification	Attempt to reproduce the suspected weakness independently	Proof-of-concept evidence or a manual-review flag
Reporting	Document confirmed issues and remediation guidance	Structured penetration testing report

The platform follows a 22-phase testing methodology

Xalgorix divides an engagement into 22 phases designed to resemble the workflow of a human penetration tester.

Teams can reportedly run the full methodology or select only the phases relevant to the authorized scope. This can help separate web application testing from infrastructure, API, or source-code assessments.

The methodology covers common vulnerability classes included in the OWASP testing framework, along with cloud, WebSocket, CMS, and business logic checks.

Phase range	Primary focus
1 to 5	Reconnaissance, file discovery, CORS, cookies, authentication, and session security
6 to 12	Injection, SSRF, access control, APIs, file uploads, deserialization, RCE, and business logic
13 to 19	Subdomains, redirects, email security, cloud infrastructure, WebSockets, CMS testing, and broken links
20	Independent exploit verification
21	Novel or previously undocumented vulnerability research
22	Final report generation

Early phases map the target and its attack surface

The first stages focus on understanding the target before aggressive testing begins.

Reconnaissance may include identifying hosts, technologies, endpoints, directories, files, cookies, cross-origin policies, and authentication flows.

This information gives the AI agent context for later decisions. An endpoint that appears harmless in isolation may become important when combined with a weak session control or an exposed administrative function.

• Domain and subdomain discovery
• Service and port enumeration
• Technology identification
• Directory and file discovery
• Cookie attribute analysis
• Cross-origin resource sharing checks
• Authentication and session mapping

The platform reportedly orchestrates established tools instead of replacing every scanner with an LLM-generated request.

Testing covers injection and server-side flaws

Later phases examine SQL injection, command injection, server-side request forgery, unsafe deserialization, and remote code execution.

These tests require careful controls because successful exploitation can alter data, disrupt services, or provide access to internal systems.

Xalgorix reportedly uses tools such as Nuclei and sqlmap while allowing the AI agent to interpret results and choose follow-up actions. The Nuclei documentation describes its template-based approach to detecting known security conditions.

Test category	Example risk
SQL injection	Unauthorized database access or modification
Command injection	Operating system command execution
SSRF	Access to internal services or cloud metadata
Unsafe deserialization	Code execution or object manipulation
File upload	Web shell placement or stored malicious content
Remote code execution	Control of the affected application or server

Xalgorix also looks for access-control failures

Signature-based scans often struggle with business logic and authorization problems because these weaknesses depend on user roles and application context.

Xalgorix claims to reason through insecure direct object references, broken object-level authorization, role boundaries, and multi-step workflows.

An AI agent may compare requests from separate user accounts, modify resource identifiers, and determine whether one user can access another user’s records.

• IDOR and BOLA testing
• Horizontal privilege escalation
• Vertical privilege escalation
• Role and permission comparisons
• Session token handling
• Multi-step business process abuse
• Race condition testing

These checks still require well-defined test accounts and authorization. An automated agent cannot safely infer which user data it may access without an engagement scope.

API and GraphQL testing forms a dedicated stage

Modern applications often expose REST, GraphQL, and internal APIs that carry sensitive business data.

Xalgorix includes API discovery and testing within its methodology. It can reportedly examine authentication, object authorization, input validation, excessive data exposure, and undocumented operations.

The platform may combine crawling with tools such as httpx and Katana to identify reachable endpoints. Nuclei can then apply known checks through the ProjectDiscovery scanning engine.

API area	Potential weakness
Authentication	Missing, weak, or reusable credentials
Object authorization	Access to another user’s records
GraphQL schema	Exposed types, fields, or administrative operations
Rate limits	Brute-force or resource-consumption attacks
Input validation	Injection and malformed request handling
Response data	Excessive exposure of sensitive information

Phase 20 verifies candidate vulnerabilities

Phase 20 provides the main distinction between Xalgorix and a conventional scanning pipeline.

The platform sends candidate findings to an independent exploit verifier. The verifier attempts to reproduce the issue without relying only on the discovery agent’s conclusion.

If the verifier succeeds, Xalgorix can include request details, responses, affected endpoints, and proof-of-concept evidence in the report.

1. The discovery agent identifies suspicious behavior.
2. It records the target, parameters, evidence, and expected impact.
3. A separate verifier receives the candidate finding.
4. The verifier attempts to reproduce the result.
5. Successful tests become confirmed findings.
6. Unreproduced results receive a manual-review status.

Verification can reduce false positives, but it cannot guarantee complete accuracy. Timing, permissions, application state, and defensive controls can change test results.

Novel vulnerability discovery remains an ambitious claim

Phase 21 focuses on new or previously undocumented vulnerabilities that do not match existing scanner signatures.

The AI agent may explore unexpected parameter combinations, state transitions, chained weaknesses, and application-specific logic.

However, users should distinguish automated anomaly discovery from confirmation of a zero-day vulnerability. A finding needs technical reproduction, impact analysis, vendor coordination, and independent review before receiving that label.

• Unexpected workflow transitions
• Chained low-severity weaknesses
• Unusual trust relationships
• Application-specific authorization failures
• Input combinations missing from scanner templates
• Inconsistent behavior between similar endpoints

The platform bundles common security tools

Xalgorix is reportedly built with Go and TypeScript and distributed as a standalone binary or Docker image.

Its toolset includes established reconnaissance, crawling, fuzzing, network scanning, and exploitation utilities.

Tool	Primary use
nmap	Network and service discovery
masscan	High-speed port scanning
subfinder	Passive subdomain discovery
httpx	HTTP service probing
Katana	Web crawling and endpoint discovery
ffuf	Web fuzzing and content discovery
Gobuster	Directory, DNS, and virtual-host enumeration
Nuclei	Template-based vulnerability checks
sqlmap	SQL injection testing

Bundling the platform inside a container can simplify deployment. Docker notes that containers isolate processes but still require secure configuration, image updates, and controlled access to host resources in its Docker Engine security guidance.

Users can connect their preferred language model

Xalgorix describes a bring-your-own-model architecture rather than tying the platform to one AI provider.

The listed options include OpenAI, Anthropic, Google Gemini, DeepSeek, Groq, Ollama, and MiniMax. Local-model support can help organizations keep prompts and target data inside their own environment.

Self-hosting does not automatically guarantee that no information leaves the network. A cloud-based model provider will still receive prompts sent through its API unless the deployment uses a local model.

Deployment approach	Data consideration
Local model through Ollama	Model prompts can remain inside the organization
Cloud LLM API	Prompts and scan context may reach the selected provider
Self-hosted Xalgorix with cloud model	Tool data remains local until the platform sends model requests
Fully local deployment	Gateway, tools, model, and reports remain under local control

Organizations should inspect model-provider retention settings, regional processing, contracts, and privacy controls before sending proprietary source code or vulnerability data.

A local dashboard displays testing activity

Xalgorix reportedly provides a web dashboard on local port 9137.

The interface displays scan progress, tool calls, agent decisions, and findings through live WebSocket updates.

Administrators should avoid exposing this interface directly to the internet. Dashboards containing target details, commands, credentials, and vulnerability evidence require authentication and network restrictions.

• Bind the dashboard to localhost or a private management network.
• Require authentication before allowing remote access.
• Place remote access behind a VPN or secured reverse proxy.
• Protect scan logs and proof-of-concept evidence.
• Do not expose port 9137 through a public cloud security group.

Xalgorix supports several testing modes

The platform can reportedly test one application, wildcard scopes, multiple targets, source repositories, and locally provisioned applications.

Wildcard mode can help red teams map a broad attack surface. Source mode examines a repository without requiring a running application.

Provision mode builds and starts an application locally before testing the live instance. This could help development teams validate exploitable weaknesses before deployment.

Mode	Use case
Single target	Test one approved application or host
Multi-target	Assess several authorized systems in one engagement
Wildcard	Map subdomains and broader attack surfaces
Source	Review a code repository directly
Provision	Build an application and test the local running instance

Automated exploitation requires strict safety controls

A tool that attempts to verify vulnerabilities can change data, create accounts, trigger external requests, or interrupt services.

Organizations should use Xalgorix only on systems they own or have explicit permission to test. The testing scope should define approved hosts, accounts, hours, techniques, and data-handling rules.

Container isolation can reduce some operational risks, but it does not protect the target from destructive commands. The Docker security documentation also warns that powerful container privileges and host mounts can weaken isolation.

1. Obtain written authorization before starting a scan.
2. Define approved IP addresses, domains, and repositories.
3. Exclude production actions that may cause damage.
4. Use dedicated test accounts and non-production data.
5. Set request limits and concurrency controls.
6. Review exploit attempts before enabling aggressive phases.
7. Preserve logs for audit and incident investigation.

Reports include evidence and remediation guidance

Xalgorix compiles findings into branded PDF reports containing severity details, proof-of-concept evidence, and remediation recommendations.

The project also claims support for CVSS scoring. A score can help with prioritization, but teams must also consider asset importance, exposure, exploitability, and existing controls.

Optional Discord, Telegram, and AgentMail integrations can deliver alerts or reports. Organizations should ensure these channels do not expose credentials, source code, or exploit details to unauthorized recipients.

• Confirmed vulnerability description
• Affected endpoint or component
• Proof-of-concept request and response
• Technical impact
• CVSS severity assessment
• Remediation guidance
• Manual-review findings

Human review remains necessary

Independent verification can reduce false positives, but automated exploitation does not replace an experienced penetration tester.

An AI agent may misunderstand business intent, miss hidden dependencies, use unsafe test inputs, or overstate the impact of a successful response.

Human testers should review confirmed findings, validate business impact, remove sensitive data from reports, and decide whether further testing remains safe.

Automated platform strength	Human responsibility
Rapid reconnaissance	Confirm that every discovered asset belongs to the approved scope
Repeated test execution	Assess whether the test may damage production systems
Exploit reproduction	Validate business impact and rule out environmental artifacts
Report generation	Review accuracy, clarity, and sensitive evidence
Suggested remediation	Adapt fixes to the organization’s architecture and risk model

Xalgorix needs independent evaluation

Xalgorix presents a useful model for automated security testing by separating discovery from exploit verification.

However, organizations need independent benchmarks covering vulnerability coverage, false positives, false negatives, cost, scan duration, and operational safety.

Comparisons with OWASP ZAP, Nuclei, commercial DAST products, and human penetration testers should use the same targets and ground truth. Until such results appear, teams should treat the platform as an additional testing tool rather than a replacement for established security assessments.

FAQ