WARDEN is alpha software. The 0.1.x series receives security fixes on a best-effort basis. Once a stable 1.x line ships, older series will be clearly marked end-of-life here.

Please do not file public GitHub issues for security vulnerabilities.

Use one of the following private channels:

1. GitHub Security Advisories (preferred). Open a draft advisory at: https://github.com/purpshell/warden/security/advisories/new This keeps the report private until a fix is ready and allows coordinated disclosure.

2. Email. Send a description to the maintainer, Rajeh "purpshell" Taher, at rajeh@reforward.dev. Encrypt with PGP if the report is sensitive; a public key will be posted alongside this address once the project has a formal security contact.

Include in your report:

• A clear description of the vulnerability and the affected component
• Steps to reproduce (a minimal malformed .wasm or command sequence is ideal)
• The impact you believe it has
• Whether you have a suggested fix

Expected response timeline. You will receive an acknowledgement within 5 business days. A triage decision (confirm, decline, or request clarification) will follow within 14 days. Fixes for confirmed vulnerabilities in the supported release series will be prioritised and released with a coordinated disclosure notice.

The single most important thing to understand about WARDEN's threat surface: warden ingest reads an arbitrary .wasm file and a .js glue file supplied by the user. These inputs are fully untrusted binary/text data from third-party vendors or adversaries. Treat them the same way you would treat any other attacker-controlled binary.

The core ingestion and fingerprinting path is implemented in pure Python with no native extensions (see src/warden/ingest/ and src/warden/oracle/). The design goal is fail-soft on malformed input: the parser is tolerant and degrades a function it cannot disassemble to raw bytes (recording the error) rather than aborting the whole parse. It does not eval or exec any wasm instruction stream. It reads sections, decodes instructions, and extracts structural metadata.

WARDEN never executes the target .wasm in the core path. There is no interpreter, JIT, or sandbox in the default install. A malformed or malicious .wasm file can at worst cause:

• A Python exception (parser bug, out-of-bounds read of a bytes buffer)
• Excessive memory or CPU use (a pathological module with millions of functions)
• Incorrect analysis output (misread sections producing wrong fingerprints or symbol names)

None of the above should escape the Python process. If you find a case where a crafted .wasm causes memory corruption or process escape in the pure-Python path, that is a high-severity finding and should be reported immediately.

warden verify <wasm> can detect and use a wasm2c or w2c2 toolchain if one is present. The differential verifier lifts a target .wasm to C and recompiles and executes the resulting code on the host. This is a fundamentally different threat category:

• Lifted C code executes natively on your machine. A carefully crafted .wasm could produce C that exploits the C compiler or the lifted binary itself.
• Run the differential verifier only inside a sandbox: a container, VM, or other isolation boundary with limited filesystem, network, and process access.
• The differential_plan function (called by warden verify) reports ready: true only when a compatible toolchain is detected. Do not enable it in automated pipelines that ingest untrusted .wasm files without a sandbox in place.

This guidance applies equally to any external tool integration (Ghidra, wasm-tools, wasm-validate). These are separate processes invoked by WARDEN but maintain their own security properties.

When warden agent runs with the anthropic backend (pip install -e '.[agents]', model claude-opus-4-8 by default), it sends function bodies and context to an external API and writes the proposed names back to the knowledge base. Treat these names as untrusted:

• A proposed name is not a guarantee of correctness; it carries a confidence score and provenance tag (agent) that distinguishes it from human or oracle entries.
• A malicious .wasm could embed strings or export names designed to manipulate the LLM's naming proposals (prompt-injection via the binary content). Review low-confidence agent output before promoting it to downstream consumers.
• Human-set names (warden set-name) have provenance human and confidence: 1.0 and are locked against agent overwrite by default. Use them to anchor ground truth.

The project database (warden.db by default, a SQLite file) stores all ingested data and recovered annotations. Treat it with the same trust level as the .wasm files it was built from, as it may contain strings, names, and evidence from untrusted sources. Do not place it in a world-readable location if the target binary or its names are sensitive.

• Run warden ingest and warden agent on untrusted .wasm files in a dedicated, low-privilege environment.
• Reserve the differential verifier (warden verify) for sandboxed environments only.
• Review agent-proposed names (provenance agent) before using them in production exports or downstream pipelines.
• Pin a specific warden-re version in automated workflows so a supply-chain update does not silently change analysis behavior.
• Keep ANTHROPIC_API_KEY out of your project database and out of version control; it is read from the environment at agent-pass time.

WARDEN is released under the MIT License.