Bowire.VulnDb

Community vulnerability database for the Bowire security scanner.

Multi-protocol API security templates that bowire scan consumes. One YAML/JSON file per known vulnerability or misconfiguration pattern; the scanner walks the templates, replays each one's probe against a target, evaluates the predicate against the response, and emits findings.

Anchor repo for the security-testing lane defined in Bowire's ADR. MIT-licensed; community contributions welcome via PR.

Quickstart

# Install bowire (skip if you already have it)
dotnet tool install -g Kuestenlogik.Bowire.Tool

# Fetch the curated template set into the local cache (~/.bowire/vulndb).
# Pulls the latest GitHub release; no git clone needed.
bowire vulndb update

# Run every cached template against your target — scan reads the cache by
# default, so no --templates flag is required.
bowire scan --target https://your-api.example.com

# Review what's cached
bowire vulndb list

bowire vulndb update is the only outbound call, and only because you ran it. For air-gapped / pinned installs, point --source at a repo checkout, a release .tar.gz, or a URL, or pin a release with --ref:

bowire vulndb update --source ./Bowire.VulnDb          # a local checkout / mirror
bowire vulndb update --source bowire-vulndb-templates-v0.1.0.tar.gz
bowire vulndb update --ref v0.1.0                       # pin a release

To run a single template (or one folder) explicitly — an explicit --template / --templates always wins over the cache:

bowire scan --target https://your-api.example.com --template templates/graphql/introspection-enabled.json
bowire scan --target https://your-api.example.com --templates templates/graphql

Template tree

templates/
  grpc/              ← gRPC-specific findings (reflection, oversized-message, …)
  graphql/           ← GraphQL-specific findings (introspection, deep-nesting, …)
  rest/              ← REST / generic HTTP findings (security headers, open redirect, …)
  odata/             ← OData-specific findings ($expand IDOR, $filter injection, …)
  signalr/           ← SignalR hub findings (anonymous negotiate, group bypass, …)
  websocket/         ← WebSocket findings (origin check missing, subprotocol confusion)
  socketio/          ← Socket.IO findings (anonymous handshake, …)
  sse/               ← Server-Sent Events findings (unauthenticated stream, …)
  mcp/               ← Model Context Protocol findings (anonymous tools/list, …)

What does not live here: native-transport protocols

A template's probe is replayed over HTTP — the scanner's runner is HttpClient-based. Every folder above is therefore reachable over HTTP, either natively (REST / GraphQL / OData / gRPC-Web / MCP) or via an HTTP handshake (WebSocket upgrade, SignalR negotiate, Socket.IO handshake, SSE stream).

MQTT-over-TCP has no HTTP surface, so it has no template shape. Its coverage ships as native probes inside the scanner (Kuestenlogik/Bowire, src/Kuestenlogik.Bowire.Security.Scanner/): anonymous access, wildcard-subscribe privilege, retained-message poisoning, and will-message abuse. Run them with bowire scan --target mqtt://broker:1883 --suite protocol. A new MQTT CVE is still triaged by this repo's monthly NVD sync — it just lands as a probe there rather than a template here.

Each template is a JSON file with a stable filename matching the template id (lowercased, dash-separated).

Template format

A template is a regular Bowire BowireRecording with three additional fields the scanner consumes. Minimal example:

{
  "id": "bwr-graphql-001-introspection",
  "name": "GraphQL __schema introspection enabled in production",
  "attack": true,
  "vulnerability": {
    "id": "BWR-GRAPHQL-001",
    "cwe": "CWE-200",
    "owaspApi": "API3-2023-BOPLA",
    "severity": "medium",
    "cvss": 5.3,
    "protocols": ["graphql"],
    "remediation": "Disable introspection in production…"
  },
  "steps": [
    {
      "id": "probe-1",
      "protocol": "graphql",
      "httpVerb": "POST",
      "httpPath": "/graphql",
      "body": "{\"query\":\"{ __schema { types { name } } }\"}"
    }
  ],
  "vulnerableWhen": {
    "allOf": [
      { "status": 200 },
      { "bodyJsonPath": { "path": "$.data.__schema.types", "exists": true } }
    ]
  }
}

Full schema documented in docs/template-schema.md.

Contributing

See CONTRIBUTING.md for the authoring conventions, naming rules, severity rubric, and the per-template CI-validation requirement.

Quick rules:

• One template per file. Filename = lowercased id with dashes.
• Stable id (never reuse). CI dashboards group findings by id; renaming breaks history.
• Always include a remediation field. A finding without an actionable fix is just noise.
• Pair an anyOf of detection-signals in the predicate rather than a single brittle regex. Multiple signals tolerate minor server-response variations.
• Lower the severity bound when unsure — operators filter the high-severity templates first; better to be reported as medium and run than skipped because the severity was inflated.

CI validation

Every PR runs the new + changed templates against a target deliberately misconfigured to trip the finding (Kuestenlogik.Bowire.Samples.Vulnerable). Two passes per template:

• Positive — the template MUST fire against the vulnerable sample (otherwise the predicate is broken).
• Negative — the template MUST stay silent against a patched / hardened variant (otherwise the predicate is too loose).

PRs that don't satisfy both passes are blocked. See .github/workflows/validate.yml.

NVD sync

A monthly workflow (.github/workflows/nvd-sync.yml → scripts/nvd-sync.mjs) queries the National Vulnerability Database for freshly-published CVEs on the protocol surfaces Bowire probes and opens an nvd-sync-labelled tracking issue for each one that has no template yet — the triage queue for new templates. It deduplicates against existing issues and covering templates, caps how many it opens per run, and never writes a template itself. Run it locally read-only with node scripts/nvd-sync.mjs --dry-run.

License

MIT (see LICENSE).

Why MIT here, when every other Bowire repo is Apache 2.0? This repo is a template set, not software. The scanner that consumes the templates is Apache 2.0 in Kuestenlogik/Bowire; the JSON files in this repo describe known-public vulnerabilities and misconfigurations. The de-facto convention for security-template sets is MIT — projectdiscovery/nuclei-templates ships under MIT, and Bowire's scanner reads both sets through the same engine. Matching the convention keeps the two interchangeable. Templates are factual descriptions of public vulnerabilities and misconfigurations; the JSON shape itself is the contribution.