Bullet

Bullet is a browser-driven web recon and attack-validation tool that runs from your terminal. Point it at a target you’re allowed to test, connect it to a real Chromium browser over CDP, and it’ll pull apart the app the same way a human would: traffic, JS bundles, DOM state, storage, routes, endpoints, auth surfaces, secrets, and anything else that looks useful.

It opens the app, watches what happens, builds a graph of what it found, ranks the interesting leads, and can optionally push further with brute modules, external scanners, or an AI agent. Results land as JSON, markdown, and a local dashboard so you can come back later and understand what actually happened.

Use this only on systems you own or have explicit permission to test. Seriously.

bun install
bun run tui

From there:

1. Enter the target URL.
2. Pick a Chromium-based browser with remote debugging support, or connect to one that is already exposing CDP.
3. Choose a mode. If you’re just getting a feel for the app, start with Recon Bundle. If you want the whole thing, use Full Attack.
4. Watch the run from the TUI, then open the generated dashboard/report from output/<runId>/.

AI mode defaults to OpenCode Zen's DeepSeek V4 Flash Free, with Ministral available as a fallback. You can swap models through config/env if you want a different provider or model chain:

# primary model
echo 'AGENT_MODEL=opencode-zen:deepseek-v4-flash-free' >> .env

# optional fallbacks, comma-separated
echo 'AGENT_FALLBACK_MODELS=mistral:ministral-8b-latest' >> .env

Use OPENCODE_API_KEY for OpenCode Zen and MISTRAL_API_KEY for Ministral fallback runs.

The app itself is OS-agnostic. Browser auto-detection has the most built-in paths on macOS, but you can connect to any Chromium-based browser as long as CDP is reachable.

Bullet is built around one idea: the browser already knows a ton about the app, so start there instead of guessing blindly.

flowchart TD
  A[Chromium browser over CDP] --> B[Harvest network, JS, DOM, forms, cookies, storage]
  B --> C[Knowledge graph + asset inventory]
  C --> D[Lead scoring + attack-chain correlation]
  D --> E{Validation enabled?}
  E -->|No| F[Reports + dashboard]
  E -->|Yes| G[Brute modules, external tools, or AI agent]
  G --> H[Findings, evidence, chains]
  H --> F

Core pieces:

• CDP harvesters capture network requests, responses, scripts, forms, cookies, local/session storage, and DOM hints.
• JS analysis walks bundles and looks for secrets, routes, API clients, and interesting string usage.
• Knowledge graph links endpoints, assets, secrets, findings, auth context, and attack chains instead of leaving you with disconnected logs.
• Lead scoring tries to rank what is actually worth looking at by impact and exploitability.
• Brute modules cover directories, params, APIs, credentials, subdomains, vhosts, and quick SQLi checks depending on config.
• External tools can call katana, ffuf, arjun, subfinder, dnsx, httpx, nmap, nuclei, sqlmap, dalfox, and related helpers when installed and enabled.
• AI Mode gives the graph and ranked leads to a model chain. DeepSeek V4 Flash Free through OpenCode Zen is the default path, with Ministral as a fallback.

Brute force behavior, concurrency, scope, CAPTCHA handling, and external tool toggles live under Brute Config in the TUI.

Every run gets its own output/<runId>/ directory. The main things you’ll care about are:

• dashboard/index.html for the local visual report
• report.md when you want a clean markdown writeup
• findings.json for normalized findings
• intel/chains.json and intel/leads.json for correlated paths and ranked leads
• harvest/ for raw-ish browser evidence: network, DOM, JS, storage
• agent/ for AI session artifacts when AI Mode was used

The dashboard is usually the easiest place to start: severity charts, ranked leads, chains, asset inventory, network logs, auth matrix data, rendered markdown, and a collapsible JSON explorer in one place.

Inside the TUI you also get views for Findings, Attack Chains, Asset Inventory, Security Report, Network Log, Auth Matrix, Job Queue, Output Files, Tool Status, and scan History.

bun run tui        # start the terminal UI
bun run dev        # TUI with watch reload
bun run web        # build web UI and start HTTP API on port 3001
bun run dev:web    # API + Vite dev server for the web UI
bun run build:web  # build the web UI
bun run lint       # oxlint over src/
bun run fmt        # oxfmt over src/

Environment variables go in .env:

See BBOT Collaboration for full details on running BBOT actively or ingesting reports.

Wordlists live in wordlists/. Runtime scan settings are mostly handled in the TUI so you don’t have to keep editing config files mid-run.

• CDP has to be reachable. If the browser is not running with remote debugging, Bullet will prompt you to launch/connect one.
• AI Mode can get active. It may ask for approval to use browser fetches, brute actions, or scanner tools. Keep scope tight.
• Missing external tools are fine. Bullet will skip those phases instead of exploding, but check Tool Status if a run feels too quiet.
• Large apps get noisy fast. Lead scoring and context compaction help, but you still want sane scope/rate limits.
• This is not a magic vulnerability printer. It gives you structured evidence and good leads; you still need to verify impact like a normal human.

Apache-2.0. License