Only the latest main branch of this repository is supported with security fixes.

Please do not report security vulnerabilities through public GitHub issues.

Use GitHub's private vulnerability reporting: Security → Report a vulnerability on this repository (or open a private advisory). Include a description, reproduction steps, and your assessment of impact if possible.

We will acknowledge reports within 7 days and aim to ship a fix within 90 days. We credit reporters in the release notes unless you prefer anonymity.

• buildWitness runs entirely locally. privateInputs (the holder secret, attributes, the issuer signature) never leave the process. Callers must keep it that way: requestProof only POSTs to a proverUrl you control (a local process), never a third-party server.
• Reads (getPolicy / isCleared / passes) are simulation-only — no account, no signature. Point rpcUrl at an RPC you trust; a malicious RPC could lie about is_cleared, so a corridor operator's payout contract should ultimately do this check on-chain, not just in the SDK.
• enter goes through a fee-sponsoring tx-relayer so the holder's Stellar account is not linked to the pass. The relayer sees the proof + public inputs (all public) but not the witness. It cannot forge a pass.
• holder_secret is generated with a CSPRNG — use randomSecret(); assertStrongSecret() rejects obviously weak values. Low entropy makes nullifiers grindable and weakens hiding.
• issueCredential / sign are issuer-side. The issuer's Grumpkin private key signs credential statements — protect it like any signing key; on compromise, bump the credential epoch and drop the key from corridor allowlists.

• Send EligibilityWitness.privateInputs to a remote server.
• Reuse a holder secret across identities, or an auditorNonce across blobs.
• Hand the issuer the raw holder_secret — send holder_binding.
• Trust isCleared from an untrusted rpcUrl as the sole payout gate.