Blitzstrike

What blitzstrike does

blitzstrike packages a three-stage security-audit methodology as a TypeScript MCP server running on Bun. BLITZ maps the attack surface by locating unauthenticated entry points, dangerous sinks, and authentication boundaries. EAGLE-EYE examines source structure and traces whether a sink is reachable from an input. STRIKE performs live checks and applies the result before a finding is reported.

The server also covers several focused assessment areas. These include deterministic Solidity auditing with executable Foundry proof, live logic-bug probing for sibling enumeration and differential IDOR checks, CWE and CVE intelligence, DNS sinkhole detection, and out-of-band proof. Its data layer contains escalation chains and a catalog of security tools and skills.

How it works

An MCP client supplies a target and, for active testing, a scope and mode. The LLM plans and routes the work, while blitzstrike provides deterministic scanning, analysis, validation, knowledge, and guardrails. A filesystem path is routed to the source pipeline; a URL is routed to the live pipeline.

The main orchestration entry point is run_engagement. It can enforce scope, perform triage, enrich results with escalation-chain data, and produce findings in one call. Agents can instead invoke individual reconnaissance, analysis, verification, and intelligence tools. Live verification uses marker reflection, a negative control, and a baseline. Scope controls include exclusion awareness, no-DoS behavior, and mode gating.

Setup and configuration

The server can run without a local checkout through npx -y blitzstrike, or from source after cloning the repository and running bun install. Start the MCP transport with blitzstrike serve --mcp; stdio is the default transport. The project advertises Bun 1.4+ and also supports a Bun or Node runtime check through doctor.

blitzstrike doctor checks the runtime, the security-tool catalog, credentials, and data layers. blitzstrike install detects supported local agent configurations and merges the server entry without replacing existing MCP servers. Use --dry-run to preview that change, or configure a client manually with the serve --mcp command and no required environment variables for the base server.

FOFA searches require FOFA_EMAIL and FOFA_KEY. The NVD lookup does not require an API key. Heavy payload and template datasets can be fetched on demand with sync-data.

Tools and capabilities

• blitz_scan and blitz_file enumerate unauthenticated entry points and dangerous sinks with file and line references.
• eagle_eye inspects a function body, in-scope sinks, and authentication gates.
• eagle_grep performs sink-focused searches inside function bodies and marks hits as guarded or unguarded.
• enrich_scan matches discovered sinks to escalation chains.
• strike_verify performs live HTTP checks; strike_resolve attaches a verdict to a finding.
• scope_check applies testing boundaries before active requests.
• run_engagement coordinates the three audit tiers in one call.
• live_recon provides passive-first reconnaissance covering fingerprinting, WAF and technology detection, crawling, parameters, subdomains, Wayback data, API discovery, and port scanning.
• fofa_search, nvd_lookup, and list_chains provide external or bundled intelligence.
• tool_lookup, list_tools, and skill_lookup expose the security-tool and skills knowledge base.

Limitations and notes

Active testing depends on a correctly defined scope and mode. FOFA functionality needs its two credentials, while the broader server can run without them. The LLM remains responsible for planning, routing, delegation, and judgment; blitzstrike supplies the execution mechanisms and guardrails. The server is intended for authorized security assessment, and its scope controls should be used to keep live testing within the permitted target.