Last reviewed: 2026-08-26

Please do not open a public issue for security vulnerabilities. Email the maintainer privately and allow a reasonable window for a fix before disclosure:

• Contact: open a GitHub security advisory (preferred), or email the maintainer listed on the GitHub profile.

We honour responsible disclosure and will credit reporters in the release notes unless you prefer to remain anonymous.

The main branch is the supported surface. There is no LTS branch yet.

Stellar Intel is non-custodial: no user funds, no user keys, no fiat, no KYC data. See docs/NON_CUSTODY.md. The largest class of "security" risk for users — losing funds — is structurally out of scope because we never hold them.

• No user keys. Signing is in the user's wallet (Freighter). Intents are Ed25519-signed client-side; the server only verifies signatures (docs/INTENT_API.md).
• ADMIN_SECRET_KEY gates /admin/disputes and admin reputation routes. Keep it server-side only; never expose it to the client (it is not a NEXT_PUBLIC_* var). See lib/config.ts for env validation.
• Publisher keys (Soroban oracle) are server-held and never shipped to the browser. Rotation policy is a roadmap item (docs/ROADMAP.md).
• Contract admin key — the reputation contract's admin Address is currently a single HSM-backed key. The migration path to a community-governed multisig (M-of-N Stellar account) is documented in docs/GOVERNANCE.md. The two-step propose_admin / accept_admin entrypoints on the contract are in place to execute that handoff safely once the signer set is ratified.

• SEP-10 authentication asserts the mainnet network passphrase before signing a challenge (lib/stellar/sep10.ts), preventing cross-network challenge replay.
• SEP-10 challenges are verified before signing. Strict checks, against the anchor's stellar.toml SIGNING_KEY: sequence number 0; source account and a valid signature from SIGNING_KEY; only manage_data operations, the first sourced from the connected wallet and keyed <d> auth for one of the anchor's domains, the rest sourced from SIGNING_KEY; timebounds present, finite, current and expiring within 24 hours. A toml without a SIGNING_KEY, or with a non-https WEB_AUTH_ENDPOINT, fails closed. This stops an anchor passing off a payment as a login challenge. Tolerated, because honest anchors send them and a sequence-0 transaction cannot be submitted: a missing or home-domain-valued web_auth_domain op, and a text memo.
• Anchor calls run server-side (e.g. /api/rates/[corridor]) so third-party anchor responses never execute with the user's origin/credentials.
• No fabricated rates. A failed anchor renders as unavailable; the codebase and PR template forbid stub/placeholder rates.
• Replay protection on signed intents (lib/intent/replay.ts).

• Dependencies are watched by Dependabot (.github/dependabot.yml) and reviewed in CI (dependency-review.yml), with CodeQL scanning (codeql.yml).
• An SBOM-on-release process is a roadmap item (v5).

• docs/THREAT_MODEL.md — adversaries and mitigations.
• docs/NON_CUSTODY.md — the custody boundary in detail.