Only the latest code on the main branch receives security fixes.

Do not open a public GitHub issue for security vulnerabilities.

Please report them via one of the following:

• GitHub Private Advisory — Report a vulnerability (preferred)
• Email — security@veritas-vaults.network

Include as much detail as possible: steps to reproduce, affected component, and potential impact.

We will coordinate a disclosure date with you once a fix is ready.

• Bugs in third-party dependencies (report upstream)
• Issues in the Stellar network or Soroban protocol itself
• Freighter wallet internals
• Findings from automated scanners without a working proof-of-concept
• Social engineering or phishing attacks

We follow responsible disclosure. Please give us reasonable time to address the issue before any public disclosure.

Contributors who have responsibly disclosed vulnerabilities are listed here once the fix is shipped and they consent to being named.

This section documents the concrete attack surface of the Soroban Guard web frontend. It is deliberately specific to this codebase, not a generic web-app template.

Soroban Guard is a security scanner whose core value proposition is that it accepts arbitrary, potentially malicious input by design — a user submits untrusted smart-contract source code so the backend engine can find vulnerabilities in it. This creates a fundamental tension: the frontend must safely handle content that is adversarial by nature.

The threat model covers two primary attack surfaces:

1. Scan-input surface — the five ways a user can supply contract material to be scanned.
2. Integration-export surface — the outbound channels through which scan results can be delivered or stored.

There are five input modes. Each has a different trust profile and a different set of attacker-controllable variables.

What happens: The user pastes Rust (or other) source directly into the <textarea> in ScanInput.tsx. The text is forwarded as-is to POST /scan on soroban-guard-core.

Attacker goal: Inject content that survives the round-trip and executes in the browser when displayed, or that causes the backend engine to behave unexpectedly.

What happens: The URL is validated client-side (lib/stellar.ts — isValidContractId / general URL checks), then forwarded to the core API. The core API fetches the repo content server-side.

Attacker goal: Cause the core API to make an unintended outbound request (SSRF), or supply a URL that resolves to internal infrastructure rather than a public GitHub repo.

What happens: The user enters a C-address. lib/stellar.ts validates the format (isValidContractId), then the frontend calls fetchContractWasm via Soroban RPC to obtain WASM bytecode, which is forwarded to the core API.

Attacker goal: Point the scanner at a contract that embeds adversarial content in its WASM metadata, annotations, or decompiled output.

What happens: lib/gist.ts validates the Gist URL against GIST_URL_RE, calls https://api.github.com/gists/{id} to list files, then fetches each file's raw_url.

Attacker goal: Supply a Gist URL whose raw content poisons the scan or whose raw_url is a redirect to an attacker-controlled host.

What happens: lib/ipfs.ts validates the CID against CID_RE (Qm… or bafy…), then fetches https://ipfs.io/ipfs/{cid} via the public gateway with a 15 s timeout.

Attacker goal: Supply a CID that points to an arbitrarily large or adversarial file, or exploit the gateway to pivot to internal infrastructure.

Scan results can be sent to six outbound channels. In every case the attacker-controlled variable is the webhook URL or API token — either entered by the user in the UI or stored in localStorage / Vercel KV.

The shared threat across all integrations:

• The GitHub token is sent in an Authorization: token ... header to https://api.github.com.
• The issue body is built from finding fields via template interpolation — Markdown injection (e.g. embedding links or code blocks) in finding descriptions would affect the created issue but not execute code in the browser.
• Risk: Low (GitHub's issue renderer treats content as Markdown, not HTML).

• Webhook URLs are user-supplied and validated only for non-emptiness.
• Finding fields are interpolated directly into message blocks.
• Risk: Medium — see injection row in the table above.

• The Notion API token and database ID are user-supplied.
• Finding descriptions are placed into Notion paragraph blocks via the Notion REST API; Notion renders these as rich text, not HTML.
• Risk: Low (no HTML execution in Notion blocks).

• The Jira base URL, email, and API token are user-supplied.
• The issue description is built as Jira wiki markup. Jira wiki markup does not execute JavaScript.
• Risk: Low.

• The Linear API key is user-supplied.
• Issue description is Markdown. Same reasoning as GitHub.
• Risk: Low.

• Protected by API_SECRET_KEY bearer token when set (via lib/apiAuth.ts).
• In-memory store is wiped on cold start; Vercel KV store persists for 30 days.
• No server-side SSRF risk in these routes (they store/retrieve JSON blobs, not make outbound requests).
• Risk: Low when API_SECRET_KEY is set. Medium in development (unset = unauthenticated).

The following risks identified above are tracked as separate issues; fixes should not be duplicated here but the threat model cross-references them:

• XSS via CodeViewer / finding fields — related issue in batch (DOMPurify allow-list already in place; dangerouslySetInnerHTML audit ongoing).
• SSRF via custom webhook/integration endpoints — related issue in batch (no server-side URL validation today; needs allowlist or SSRF-proof proxy).
• Injection via integration notification payloads — related issue in batch (Slack mrkdwn / Discord embed injection via finding fields).
• GitHub Gist raw_url hostname validation — identified above; not yet tracked; recommend adding to the backlog.
• IPFS response body size cap — identified above; not yet tracked; recommend adding to the backlog.