Vigolium v0.1.13-beta

Den første åpne utgivelsen er publisert Vigolium v0.1.13-beta — av sårbarhetsskanneren for webapplikasjoner, som kombinerer klassisk deterministisk skanning med agentbasert revisjon basert på LLM. Prosjektet er tilgjengelig på GitHub og distribueres under lisensen GNU AGPLv3; den kommersielle delen er flyttet til skyen Cloud Console, mens kjernen av skanneren er erklært som åpen.

Vigolium tilbyr to hoveddriftsmodi: vigolium scan — vanlig flerstegs skanning med innholdsøkting, spidering via nettleser, aktiv og passiv revisjon; og vigolium agent — agentmodus, der LLM velger moduler, planlegger angrep, genererer brukerdefinerte JavaScript-utvidelser og kombinerer dynamisk testing med revisjon av kildekoden.

Ifølge oppdatert modulkatalog, Vigolium inkluderer 251 valideringsmoduler, av dem 154 aktive og 97 passive. Aktive moduler sender endrede forespørsel og benytter fuzzing, injeksjoner og atferdsanalyse, passive — analyserer allerede eksisterende forespørsel/tilbud-par uten å generere ekstra trafikk.

Funksjoner

• Native Scan — vanlig deterministisk skanning.
  Modus vigolium scan er ment for raske og reproduserbare kontroller. Den går gjennom flere faser: ekstern datainnsamling, innholdsopdagelse, browser/SPA-spidering og revisjon. Denne modus er praktisk for CI, regelmessige kontroller og tilfeller der det er viktig å få et forutsigbart resultat uten LLM-deltakelse.

• Agentic Scan — agentrevisjon med LLM.
  Modus vigolium agent bruker innebygd runtime olium. Agenten kan selv finne endpoints, velge moduler, kjøre kontroller, analysere kode, utføre SAST og revidere funn. Scenarier for Autopilot, Swarm og Query-modus støttes: fra autonom skanning av mål til engangsforespørsel for kodegjennomgang, finne endpoints og oppdage hemmeligheter.

• Sjekker XSS, SQLi, NoSQLi, SSTI, LFI, RCE, XXE og SSRF.
  I modulkatalogen listes tester for reflektert XSS, SQL-injeksjoner med feil og boolean-basert blind SQLi, NoSQL-injeksjoner, server-side template injection, lokal filinkludering, kommandoinjeksjon, XXE, SSRF og out-of-band-sårbarheter. For funn brukes en alvorlighetsgradsskala fra kritisk til info og en tillitsnivå-skala certain, firm, tentative.

• OAST-sjekker for 'blinde' sårbarheter.
  Vigolium kan sjekke blind XSS, blind SSRF, blind XXE og blind RCE gjennom callback-mekanismer, inkludert via interactsh. Dette er nødvendig i situasjoner der sårbarheten ikke vises direkte i HTTP-svaret, men serveren gjør eksterne DNS/HTTP-forespørsel eller utfører utsettelser.

• Verdi-bevisst mutasjon — mutasjon av parametere med hensyn til betydningen av verdien.
  Skanneren klassifiserer parametere etter semantisk type: tall, UUID, JWT, e-post og andre alternativer, før den tilpasser mutasjoner til konteksten. Dette skal redusere støy sammenlignet med grov substitusjon av identiske payloads i alle felt.

• Støtte for ulike inngangsformater.
  Som inngang kan man sende URL-er, OpenAPI/Swagger-spesifikasjoner, Postman-samlinger, data fra Burp Suite, cURL og Nuclei JSONL. Det støttes også å sende URL-er via stdin og starte separate faser med skanning.

• Autentisert skanning og kontroller for IDOR/BOLA.
  Vigolium støtter flere sesjoner samtidig: sesjoner kan overføres inline, lastes opp fra filer eller beskrives som komplette login-flows med token-uttrekk. Dette brukes for å sjekke horisontal og vertikal tilgangskontroll, inkludert IDOR/BOLA og heving av privilegier.

• Sjekker for rammeverk og typiske lekkasjer.
  I modullisten finnes det sjekker for Next.js, Spring/Java, Django, Flask, FastAPI, Laravel, Symfony, Rails, Express og ASP.NET/IIS. For eksempel for Spring sjekkes åpne Actuator-endepunkter, Spring Boot Admin, Spring Cloud Config, H2 Console, Jolokia og konsoller for Java-applikasjonsservere; for Next.js — lekkasjer gjennom /_next/data, SSRF i Image Optimizer og omgåelser av middleware.

• JavaScript-utvidelser.
  Brukeren kan skrive sine egne moduler og hooks på JavaScript via den innebygde JS-motoren med HTTP API som tar hensyn til sesjoner. Et viktig begrensning: slike utvidelser kan utføre vilkårlige kommandoer og er ikke isolert av en sandkasse, så de må betraktes som vanlig kjørbar kode.

• En egen triage-fase for resultater.
  I LLM-assistert sikkerhetstesting oppstår ofte problemet med plausible, men ikke-reproduserbare funn. Forfatteren av Vigolium beskriver triage som et eget gjennomløp: først samler skanneren kandidater, deretter kontrolleres hvert funn på nytt mot bevis.

• Budsjettbegrensninger for agentmodus.
  For agent-based scanning, it is possible to limit tokens, the number of tool calls, the number of triage iterations, and total execution time. This is important for CI and pentests with a fixed time: the agent should not endlessly "dig" into one target and waste the budget on low-value hypotheses.

• Reports, queue, and scaling.
  In Native Scan, 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 are declared. Output options include console, JSONL, and HTML.

• Server mode, API, and integration with Burp Suite.
  Vigolium can be launched as an API server, take traffic, include 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 the 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 planning audits.

Installasjon

The project offers installation via shell script, npm, Docker, Homebrew, Bun, and building from source. Requirements for building from source are indicated in the README Go 1.26+ og 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: the agent mode starts without a sandbox and gains full access to the shell, file system, and host network, and extensions can also execute arbitrary commands. Therefore, it is recommended to run agent checks in a disposable container or virtual machine limited to the specific testing parameters.

Kilde: linux.org.ru