SVB is designed so a malformed or hostile file is rejected cleanly — never crash, hang, or emit broken output. If you find a way past that contract, we want to hear about it.

Please use GitHub's private vulnerability reporting (Security tab → Report a vulnerability) rather than a public issue.

Include, if you can:

• The minimal .svg or .svb file that triggers the behavior.
• The command (CLI/API/browser) and what happened — crash, hang, OOM, malformed output.
• Your Node version.

You do not need to check whether the bug is new or already known — report it anyway. Known hardening history (EOF guards, declared-count bounds, decompression cap, expansion budget) is documented in SPEC §12 and DESIGN.md; duplicates just get closed with a pointer.

• In scope: the reference encoder, decoder, validator, and CLI in src/; the demo Service Worker.
• By design, not a vulnerability: the format carries no executable constructs and cannot carry scripts, event handlers, CSS, or foreignObject — that is the point of the format, see SPEC §1.
• Known limits: the reference implementation is JavaScript (memory-safe runtime); DoS-style findings are still valid reports and welcome.

Two independent mutators exercise the decoder:

1. Deterministic mutator (src/fuzz.js, runs in CI): bitflips, truncation, byte storms, splices, header corruption, trailing garbage. Part of every test run.
2. Radamsa (optional, not in CI): a grammar-agnostic mutator with no knowledge of SVB. Latest campaign (2026-09-06, seed 20260906, 6,000 mutants from the conformance vectors + demo samples, batches under a 60 s watchdog):

Reproduce with npm run fuzz:radamsa (requires radamsa); test/radamsa.test.js runs a 300-mutant batch whenever the binary is present.

None — this is a small open-source project. Credit in the release notes and the changelog is what we can offer, and it is given gladly.