Initial open release published Vigolium v0.1.13-beta — a vulnerability scanner for web applications that combines traditional deterministic scanning with agent-based auditing based on LLM. The project is available on GitHub and is distributed under a license GNU AGPLv3; the commercial part is moved to the cloud Cloud Console, while the core scanner is stated to be open-source.
Vigolium offers two main modes of operation: vigolium scan — a standard multi-step scan with content discovery, browser spidering, active and passive auditing; and vigolium agent — an agent mode where LLM selects modules, plans attacks, generates custom JavaScript extensions, and combines dynamic testing with source code auditing.
According to data current module reference, Vigolium includes 251 verification modules, of which 154 are active and 97 are passive. Active modules send altered requests and apply fuzzing, injections, and behavioral analysis, while passive ones analyze existing request/response pairs without generating additional traffic.
Capabilities
Native Scan — standard deterministic scanning.
The vigolium scan mode is designed for quick and reproducible checks. It goes through several phases: external data gathering, content discovery, browser/SPA-spidering, and auditing. This mode is convenient for CI, regular checks, and cases where it's crucial to obtain predictable results without LLM involvement.Agentic Scan — agent-based auditing with LLM.
The vigolium agent mode uses an integrated runtime olium. The agent can autonomously search for endpoints, select modules, run checks, analyze code, perform SAST, and recheck findings. Autopilot, Swarm, and Query mode scripts are supported: from autonomous scanning of targets to one-off requests for code reviews, endpoint searches, and secret discovery.Checks for XSS, SQLi, NoSQLi, SSTI, LFI, RCE, XXE, and SSRF.
The module reference lists checks for reflected XSS, SQL injections via errors and boolean-based blind SQLi, NoSQL injections, server-side template injection, local file inclusion, command injection, XXE, SSRF, and out-of-band vulnerabilities. Findings use a severity scale from critical to info and a confidence scale of certain, firm, tentative.OAST checks for 'blind' vulnerabilities.
Vigolium can detect blind XSS, blind SSRF, blind XXE, and blind RCE through callback mechanisms, including via interactsh. This is necessary for cases where the vulnerability does not manifest directly in the HTTP response, but the server makes an external DNS/HTTP request or performs a delayed action.Value-aware mutation - mutation of parameters considering the semantics of the value.
The scanner classifies parameters by semantic type: number, UUID, JWT, email, and other options, then selects mutations based on context. This should reduce noise compared to naively substituting the same payloads in all fields consecutively.Support for various input formats.
As input, you can provide URLs, OpenAPI/Swagger specifications, Postman collections, data from Burp Suite, cURL, and Nuclei JSONL. URL input through stdin and running separate scanning phases are also supported.Authenticated scanning and IDOR/BOLA checks.
Vigolium supports multiple sessions simultaneously: sessions can be passed inline, loaded from files, or described through full login flows with token extraction. This is used for checking horizontal and vertical access control, including IDOR/BOLA and privilege escalation.Framework checks and typical leaks.
The module list includes checks for Next.js, Spring/Java, Django, Flask, FastAPI, Laravel, Symfony, Rails, Express, and ASP.NET/IIS. For example, for Spring, it checks open Actuator endpoints, Spring Boot Admin, Spring Cloud Config, H2 Console, Jolokia, and Java application server consoles; for Next.js — leaks through /_next/data, SSRF in Image Optimizer, and bypasses middleware.JavaScript extensions.
Users can write their own modules and hooks in JavaScript through the built-in JS engine with an HTTP API that considers sessions. An important limitation: such extensions can execute arbitrary commands and are not sandboxed, so they should be treated as regular executable code.Separate triage phase for results.
In LLM-assisted security testing, there is often the problem of plausible but non-reproducible findings. The author of Vigolium describes triage as a separate pass: first, the scanner collects candidates, then a separate check revalidates each finding against the evidence.Budget constraints for agent mode.
For agent-based scanning, you can limit tokens, number of tool calls, triage iterations, and total execution time. This is crucial for CI and pentests with fixed timelines: the agent should not endlessly "dig" into one target, burning the budget on low-value hypotheses.Reports, queue, and scaling.
Native Scan features a competitive worker pool, per-host rate limiting, a hybrid queue in memory, on disk, or in Redis, as well as self-sufficient HTML reports. Outputs are available in console, JSONL, and HTML formats.Server mode, API, and integration with Burp Suite.
Vigolium can run as an API server, accept traffic, enable a transparent HTTP proxy, and automatically scan the received data. A separate burp-vigolium extension is mentioned for Burp Suite, allowing live traffic to be sent to the Vigolium server.Workbench and Console.
In addition to CLI, the project describes Workbench — a self-hosted dashboard for visualizing results, managing projects, and tracking findings. Console — a cloud commercial layer for managed scanning, centralized reporting, collaboration, and audit planning.
Installation
The project offers installation via shell script, npm, Docker, Homebrew, Bun, and building from source. The README specifies requirements for building from source Go 1.26+ and bun 1.3.11+.
curl -fsSL https://vigolium.com/install.sh | bash
npm install -g @vigolium/vigolium
docker pull j3ssie/vigolium:latest
docker run —rm j3ssie/vigolium:latest scan -h
Developers specifically warn that Vigolium is an offensive security tool: agent mode runs without a sandbox and gains full access to the shell, file system, and host network, while extensions can also execute arbitrary commands. Therefore, agent checks are recommended to be run in a disposable container or a virtual machine, limited to the scope of the specific testing.
Source: linux.org.ru
