If you discover a security vulnerability in OpenObscure, please report it responsibly using GitHub's private vulnerability reporting.

1. Go to the OpenObscure GitHub repository → Security tab → Report a vulnerability
2. Include:
   • Description of the vulnerability
   • Steps to reproduce
   • Affected component(s) (L0 Core proxy, L1 plugin, L2 crypto)
   • Potential impact assessment
   • Suggested fix (if any)

Do not open a public issue for security vulnerabilities — use GitHub's private reporting to ensure the issue can be assessed and fixed before public disclosure.

OpenObscure is a community-maintained open-source project. Response times depend on contributor availability and the nature of the vulnerability. We aim to:

1. Acknowledge reports promptly
2. Assess severity and impact
3. Develop and release a fix, coordinating disclosure with the reporter
4. Disclose publicly after the fix is available

Critical vulnerabilities (key extraction, proxy bypass, plaintext PII leaks) will be prioritized. Community contributions to fixes are welcome and encouraged.

• Bypass of PII detection (input that should be caught but isn't)
• FPE key extraction without OS keychain access
• Transcript decryption without the passphrase
• L0 Core proxy bypass (traffic reaching LLM without passing through proxy)
• File Access Guard bypass (reading denied paths)
• Memory leaks of plaintext PII
• Denial of service against the proxy
• Dependency vulnerabilities with exploitable paths in OpenObscure
• ONNX model substitution attacks (replacing SCRFD/BlazeFace/PaddleOCR models with malicious ones)
• Response integrity model bypass (crafting text that evades both R1 dictionary and R2 classifier detection)
• Image processing bypass (crafting images where faces/text aren't detected)
• Resource exhaustion via image processing (OOM, CPU spin on adversarial inputs)
• Base64 bomb attacks (crafted base64 strings that decode to extremely large images)

• Attacks requiring root/admin access to the host OS (see Threat Model — this is explicitly out of scope)
• Attacks requiring a compromised host agent process
• PII types not yet covered (tracked in roadmap)
• Regex evasion using obfuscated/unusual PII formats (report these as feature requests, not vulnerabilities)
• Vulnerabilities in LLM providers, the host agent itself, or upstream dependencies without a demonstrated exploit path through OpenObscure

OpenObscure's security depends on the secrecy of keys, never on the secrecy of code. All algorithms used (FF1, AES-256-GCM, Argon2id) are public NIST/OWASP standards. Publishing source code does not weaken the system.

Three independent layers (L0-L2) ensure that a failure in one layer does not expose all PII. L0 (proxy) and L1 (plugin) operate at different interception points — compromising one does not bypass the other.

• No telemetry — zero outbound connections beyond forwarded LLM requests
• No default credentials — FPE key must be explicitly generated with --init-key
• No cloud dependencies — everything runs locally on the user's device
• Passthrough-first auth — OpenObscure never provisions or stores LLM API keys by default

OpenObscure supports multiple secret storage backends to accommodate both desktop and headless (Docker, CI, VPS) environments. The priority chain for each secret is:

FPE master key (32 bytes, AES-256) — see FPE Configuration for full setup and rotation:

1. OPENOBSCURE_MASTER_KEY environment variable (64 hex chars) — for headless/Docker/CI
2. OS keychain (macOS Keychain, Windows Credential Store, Linux keyutils/Secret Service) — for desktop
3. Encrypted file (~/.openobscure/master.key.enc) — fallback for environments without keychain or env vars
4. Fail (503 — proxy refuses to start without a key)

L0/L1 auth token (32 bytes, hex):

1. OPENOBSCURE_AUTH_TOKEN environment variable — for headless environments
2. ~/.openobscure/.auth-token file (permissions 0600 on Unix) — auto-generated on first run
3. Auto-generate with OsRng and write to file

Security trade-offs: Environment variables are intentionally supported because containerized and headless environments lack OS keychain access. Env vars are visible to process inspectors (e.g., /proc/*/environ on Linux). This is the standard pattern used by Docker secrets, Kubernetes secrets, and HashiCorp Vault. For maximum security on desktop environments, prefer OS keychain over env vars.

Secrets are never written to:

• Source code or config files
• Log output (all logging passes through PII scrubbing)

The FPE key and transcript passphrase are independent — compromising one does not expose the other.

• All dependencies are audited for license and security before inclusion (see LICENSE_AUDIT.md in each component)
• Rust dependencies use cargo audit for known vulnerability scanning
• L1 plugin has one optional runtime dependency (@openobscure/scanner-napi for native PII scanning). All other Node.js dependencies are dev-only (build/test).
• ONNX models are sourced from HuggingFace with checksum verification

• L0 and L2 are written in Rust — memory-safe by default (no buffer overflows, use-after-free, or data races)
• L1 is TypeScript with strict mode — type-checked at compile time
• PII values are never logged — only match counts and types are recorded
• Integration tests verify FPE roundtrip correctness and PII redaction completeness

• Release binaries built with opt-level = "s", LTO, symbol stripping, panic = "abort"
• No debug symbols in release builds
• Binary verifiability is a goal — see open_source_strategy.md for the build verification approach

The image pipeline introduces additional attack surfaces that are actively mitigated:

The R2 cognitive firewall introduces a TinyBERT ONNX classifier for persuasion detection:

The /_openobscure/health and /_openobscure/ner endpoints require the X-OpenObscure-Token header (32-byte hex, stored at ~/.openobscure/.auth-token with 0600 permissions). If you run L0 behind a reverse proxy (Nginx, Caddy, Traefik), ensure /_openobscure/* routes are not exposed externally — they should only be reachable from localhost or the L1 plugin process.

The crash buffer (crash_buffer = true in [logging]) is disabled by default. Without it, forensic log data is permanently lost after an OOM kill or SIGKILL. For production deployments where forensic completeness matters (HIPAA, PCI-DSS incident response), enable the crash buffer:

[logging]
crash_buffer = true
crash_buffer_size = 4194304  # 4MB

See Crash Recovery for forensic workflow details.

The following files under ~/.openobscure/ contain security-relevant data. Remove them when uninstalling OpenObscure:

The FPE master key is stored in the OS keychain — remove it separately using keyring delete openobscure fpe-master-key or your platform's keychain manager.

OpenObscure has not undergone a formal third-party security audit. The cryptographic implementation uses well-tested library implementations (RustCrypto ecosystem) rather than custom primitives. Community review is welcomed and encouraged.

If you or your organization are interested in sponsoring a formal audit, please reach out.