Do not open a public GitHub issue for security vulnerabilities.

Please report security issues by emailing:

security@xlm-ns.org

Include as much of the following as you can:

• A clear description of the vulnerability and its potential impact.
• The affected component(s): contract name, CLI command, SDK method, or configuration path.
• Steps to reproduce or a minimal proof-of-concept.
• Any mitigating factors you are aware of.

You will receive an acknowledgement within 2 business days.

If you do not receive a response within 4 business days, follow up at the same address with "REMINDER" in the subject line.

We follow coordinated disclosure. We will not disclose a vulnerability publicly until a patch is available and the reporter has had a chance to review it, unless the vulnerability is already being actively exploited.

We ask reporters to observe the same embargo until the coordinated date.

We use a simplified four-level scale:

Critical and High findings are patched and released as soon as possible. Medium and Low findings are batched into the next scheduled release.

• All Soroban contracts under contracts/ deployed to Stellar testnet or mainnet.
• The xlm-ns-cli binary and all subcommands.
• The xlm-ns-sdk and xlm-ns-common crates when used as library dependencies.
• Configuration parsing and signer key handling in the CLI.

• Third-party infrastructure (Stellar core, Soroban RPC nodes, Axelar gateway).
• Vulnerabilities that require the attacker to already control the victim's Stellar private key.
• Issues in dependencies that are already publicly disclosed — report those upstream and open a non-security PR here to bump the version.
• Social-engineering attacks against maintainers.

The high-level trust boundaries for xlm-ns are documented in the README under Security and Threat Model. Key assumptions relevant to vulnerability reports:

1. No privileged recovery path — the registry and registrar have no admin override. Ownership changes only through the normal expiry/grace/claimable flow or explicit owner-initiated transfer. A report claiming that "the admin cannot reclaim a stolen name" is by design, not a bug.

2. Auth is enforced by Soroban — every mutation requires Address::require_auth(). A finding that bypasses this is Critical.

3. Signer secrets are never stored in structs — the CLI reads secrets from environment variables at signing time only. A finding that causes secrets to be written to disk, logs, or network is High.

4. The SDK is currently mock-based — it does not make live RPC calls. Security findings against the mock layer are Low unless they affect the real-client path when it ships.

We can receive reports in English. PoC code in Rust, shell, or Python is preferred.

We do not currently run a paid bug-bounty programme. Reporters of confirmed High or Critical vulnerabilities will be credited in the release notes and security advisory (with their consent) and offered a spot on the project's acknowledgements page.