If you discover a security vulnerability in stellar-zkLogin, please do not open a public GitHub issue.
Email your findings to the maintainers with:
- A description of the vulnerability
- Steps to reproduce (proof of concept if possible)
- The affected component (contract name, circuit, or script)
- Your assessment of severity and impact
- Acknowledgment within 48 hours
- Assessment within 7 days
- Fix timeline communicated within 14 days
- Public disclosure after fix is deployed (coordinated with reporter)
We will credit reporters in the security advisory unless they prefer to remain anonymous.
The following are in scope:
- Soroban contracts (
contracts/*/src/lib.rs) - Circom circuit (
circuits/identity-attestation/src/identity_attestation.circom) - Deployment scripts (
scripts/) - Trusted setup process
The following are out of scope:
- The attestation server (separate repo)
- Mobile client implementations (separate repo)
- OAuth provider vulnerabilities (report to Google/Apple directly)
stellar-zkLogin uses a semi-trusted model. For the full threat analysis, trust boundary diagram, and known limitations, see docs/SECURITY_MODEL.md.
- OAuth provider correctly authenticates users
- Attestation server correctly validates tokens (does not forge attestations)
- Trusted setup ceremony had at least one honest participant
- Soroban runtime correctly executes contract logic
- The attestation server is an additional trust assumption compared to fully trustless systems (e.g., Sui zkLogin's JWK oracle)
- BN254 provides ~100-128 bit security (industry standard for ZK-SNARKs, below NIST 128-bit recommendation)
- Groth16 requires a trusted setup — if all ceremony participants collude, proofs can be forged
An internal white-hat audit identified 14 on-chain findings. Fixes are in progress. A third-party audit is planned before mainnet deployment.
See docs/SECURITY_MODEL.md for the full audit status table.