envseal is a security-critical tool currently in beta. We take every vulnerability seriously.

envseal is actively hardening toward 1.0. The Lockdown-mode vault and core crypto are designed to be unbreakable, but vulnerabilities in other areas are expected at this stage. GUI prompt handling, policy edge cases, race conditions, non-Lockdown tiers, and other surfaces are all actively being strengthened. Finding and reporting these issues is exactly how we get to 1.0.

We welcome all findings. Nothing gets dismissed.

We have a three-tier submission structure. All tiers are valid. We don't dismiss findings based on difficulty.

The hardest challenge. Extract the hidden flag from a Lockdown-mode vault.

envseal ctf start # set up the challenge
envseal ctf rules # detailed rules
envseal ctf verify # verify a flag

envseal claims that once a secret enters the write-only vault, nobody can extract it. Not a human, not an AI agent, not both working together. The CTF is how we prove it.

What's allowed: Everything. Memory reads, binary replacement, PATH poisoning, LD_PRELOAD, GUI automation, config tampering, side channels, kernel modules, any creative software technique.

What's banned: Physical hardware memory readers only (DMA via Thunderbolt/PCIe, cold boot attacks, JTAG debuggers). These bypass all software on earth and are not envseal-specific vulnerabilities.

Reward: Hall of Fame + highest prestige.

Bypass any Lockdown-mode protection without extracting the flag itself.

Examples:

• Disable self-integrity verification without detection
• Bypass screen recorder or input injector detection
• Evade dataflow tracking
• Exceed concurrent secret limits
• Inject via denied pipe mode

Reward: Credited vulnerability + fix.

Any security issue in Standard or Hardened mode.

Examples:

• GUI popup automation bypass
• Policy HMAC verification weakness
• Secret name injection / path traversal
• Audit log tampering
• Race conditions in concurrent injection
• Environment variable smuggling past blocklist
• Native UI issues in the egui desktop app

Reward: Credited vulnerability + fix.

Submit findings to: security@santh.dev

Or open a private security advisory on GitHub.

Include:

• Description of the vulnerability
• Steps to reproduce
• Your assessment of impact
• Your name/handle for credit (optional)
• Which tier you believe it falls under

• Acknowledge: Within 24 hours
• Triage: Within 7 days
• Fix: Within 30 days for Tier 1-2, 90 days for Tier 3
• Credit: In the release notes and Hall of Fame

The following are in scope:

• envseal core library
• envseal-cli (binary name envseal)
• envseal-gui native desktop app (desktop-native/, egui/eframe)
• envseal-mcp Rust MCP server
• Documentation site

The following are out of scope:

• Physical hardware attacks (DMA, cold boot, JTAG)
• Social engineering of the vault owner
• Denial of service (deleting vault files with filesystem access)

• Argv-binding: Enabled by default for all new approvals. Policy rules are scoped to specific command-line arguments to prevent unauthorized access by the same binary running different scripts. Existing legacy rules remain unscoped until re-approved.
• Hardware-sealed master key: Enabled automatically on every supported platform. The master key on disk (master.key) is wrapped twice. Passphrase (Argon2id) on the inside, hardware seal (DPAPI / Secure Enclave / TPM 2.0) on the outside. A master.key copied to a different machine fails to unwrap with Error::CryptoFailure("hardware-unseal of master.key failed. Likely a different user logon, a different physical device, or a wiped TPM/SEP keypair"). Run envseal doctor to see the active tier; tier 3 (passphrase-only) is loud and warns. Bypassing the hardware seal qualifies as a Tier 2 finding.

These are the claims that, if broken, are immediate Tier 1 / Tier 2 findings. They are the ones we want you to attack hardest:

1. The master key cannot leave the device. A master.key file copied off-machine, plus the user's passphrase, must not produce plaintext on any other device. Cryptographic break of DPAPI / SEP / TPM2 sealing, side-channel extraction of the device-bound wrap key, or recovering the wrap key from RAM dumps would all qualify.
2. No release without GUI approval. Calling envseal inject / envseal pipe / envseal supervised without a corresponding GUI approval click must fail. Bypasses via spoofed dialogs, headless approval forging, GUI automation that the threat-assessment doesn't detect (xdotool/ydotool/wtype/SendInput/CGEventPost/AppleScript), or relay-mode downgrade attacks all qualify.
3. No leak through stdio or descendants in Lockdown. A supervised child running under --sandbox=lockdown must not be able to spawn a grandchild that exfiltrates the secret over network/disk/IPC. The Windows JobObject is now applied via CREATE_SUSPENDED + AssignProcessToJobObject + NtResumeProcess so there is no race window between spawn and assignment; demonstrating an escape via process explosion, breakaway flags, or a side-channel inside the job qualifies.
4. Argv-binding is sound. An approval for wrangler deploy must not implicitly extend to wrangler --shell evil.sh. Bypasses via argv canonicalization differences, fingerprint collisions, or rule-fallback semantics qualify.

These are hard limits of the current threat model. Finding them is not a vulnerability, just the documented edge:

• Physical access at the keyboard is in the trust boundary. Anyone who can see the screen and click the GUI popup is treated as the owner.
• Linux without TPM 2.0 access falls back to passphrase-only sealing. This is announced loudly by envseal doctor and the file format records Backend::None so it cannot be silently confused with a tier-1 vault. To fix: install tpm2-tools or accept tier 3.
• macOS Hardened tier denies network and IOKit but not file writes. By design, since most developer tooling needs file I/O. Use Lockdown when you want filesystem isolation too.
• memfd_secret requires Linux 5.14+ with CONFIG_SECRETMEM=y. Older kernels fall back to mlock, which protects against swap but not root.

The following invariants are covered by automated tests at the envelope-byte level (v2_envelope_with_mismatched_backend_id_is_rejected, write_then_read_corrupted_inner_still_fails_unseal_chain), but the true cross-device denial story is only provable on physical hardware. We hand-test these on every release; if you're auditing, please reproduce.

1. On machine A: envseal store sentinel-key → enter passphrase correct horse battery staple. Verify with echo "$(envseal inject sentinel-key=K -- printenv K)".
2. Copy ~/.config/envseal/master.key (Linux/macOS) or %USERPROFILE%\.config\envseal\master.key (Windows) to machine B under the same path.
3. On machine B: envseal list should fail when it tries to unwrap master.key. The expected error is one of:

• Windows: hardware-unseal of master.key failed. Likely a different user logon, a different physical device, or a wiped TPM/SEP keypair
• macOS: same string with the SEP backend
• Linux: same string with the TPM2 backend (tier 1) OR a clean passphrase-decryption failure (tier 3, no TPM)

4. Even with the correct passphrase typed, the unwrap fails before the passphrase is consulted. DPAPI/SEP/TPM unseal happens first.
5. envseal doctor on machine B reports tier 2. Windows DPAPI (or equivalent) and the empty [vault] block (no openable vault).

If at any point machine B successfully unwraps the copied master.key, that's an immediate Tier 1 finding. Please file.