Skip to content

Security: XfeaturesGroup/XfeaturesVaultEnclave

Security

SECURITY.md

Security policy

Reporting a vulnerability

Please do not open a public issue for a security problem.

Report it privately through GitHub's private vulnerability reporting on this repository.

Please include:

  • what you can do that you should not be able to do,
  • whether it requires a compromised edge, a compromised daemon host, or neither,
  • the exact request(s) or commands involved, and
  • which guarantee in docs/THREAT-MODEL.md it breaks.

That last point matters most. This system's central claim is that Cloudflare — fully compromised, subpoenaed, or simply malicious — can be handed nothing more than ciphertext, blinded handles, and traffic metadata. A report that breaks that claim, or that shows plaintext reaching disk, is the highest-severity thing this project can receive.

What is in scope

  • Cryptography: the AEAD associated data scheme, key derivation, the blinding scheme for usernames, nonce handling, the envelope format.
  • Memory protection: any path by which key material or a decrypted secret reaches swap, a crash dump, or freed-and-unwiped heap.
  • Account isolation: anything that lets one account's request read, modify, or infer the existence of another account's data.
  • The Worker's authorization and quota enforcement: version-guard bypass, quota bypass, the reserved __auth__ id, rate limiting.
  • The daemon's local API: authentication bypass, the browser-refusal gate (XVE-03), session isolation, the password-in-transit handling during login.
  • Audit integrity: anything that lets an actor act without a truthful audit record, or that lets a stolen service token inject false log entries.

What is already known

Some properties are deliberate and documented, not defects:

  • POST /v1/seal ends every session on the host, not just the caller's. A denial of service one account can inflict on others sharing the daemon, never a disclosure. See docs/SECURITY-ASSUMPTIONS.md.
  • p_cost = 4 provides no real strengthening against a parallel attacker, because the underlying Argon2 implementation is single-threaded. Documented in src/crypto/format.rs and in docs/SECURITY-ASSUMPTIONS.md.
  • The Windows build cannot block debugger attach. No kernel-level barrier exists there; the Linux/musl build is the one to run where that matters.
  • A brief window where a password exists outside locked memory: in hyper's read buffer during POST /v1/login. Mitigated several ways, never eliminated — see docs/SECURITY-ASSUMPTIONS.md.

Our own review

This codebase has been through an internal adversarial review covering nine findings (XVE-01 through XVE-09), each with a regression test verified to fail against the vulnerable code before the fix landed, plus two further defects found during the fix and during cross-platform build verification. The full history is in docs/THREAT-MODEL.md.

This is not a substitute for an independent penetration test, and it is not a claim that the system is free of defects.

There aren't any published security advisories