xchain-node is the CLI that installs and manages every other XChain service as Docker containers. It runs with elevated host privileges, generates per-service configs and credentials, downloads coin-node binaries from official sources, and can restore database bootstraps. A flaw in any of these paths can affect the entire XChain stack on the operator's host, so we treat reports seriously and respond fast.

If you've found a security issue, please do not open a public issue or pull request. Use the private channels below.

Open a draft advisory at:

https://github.com/XChain-Platform/xchain-node/security/advisories/new

This is the fastest path. The advisory is private until we publish it.

Email security@dankest.llc with:

• A description of the issue and the threat it poses.
• Reproduction steps or a proof-of-concept (a crafted config, input, or invocation that triggers the bug).
• The affected version (see CHANGELOG.md and the version badge in README.md) and the environment (host OS, Docker version, which services were installed).
• Any patches or mitigations you'd like considered.

For sensitive reports, encrypt the email body to our PGP key. The fingerprint will be published alongside the first signed release artifact; until then, the email channel is acceptable for first contact and we will coordinate an encrypted exchange before you share proof-of-concept details.

We do not currently offer a paid bug bounty. We do offer public credit in release notes and the advisory itself, unless you prefer to remain anonymous.

If we cannot meet a timeline, we will tell you why and propose a new one. We will not silently let a report age.

• The install and update flow as it runs with host-level privileges: any path where an attacker-controlled input (config values, branch names, coin names, network names) escapes into a shell command or leads to arbitrary code execution on the host.
• How generated configs handle credentials: .env files written to disk, RPC passwords, database user credentials, and the validator Ed25519 signing key generated by validator init. Any path that leaks these outside their intended scope.
• Supply-chain integrity of fetched binaries and snapshots: SHA-256 verification of downloaded coin-node binaries (bitcoind, litecoind, dogecoind) and database bootstrap archives. Any path where a tampered or substituted artifact is accepted.
• The cross-arch coin-binary cache and how stale or mismatched binaries are detected and rejected.
• Any path where install-time input leads to path traversal, privilege escalation, or host-filesystem corruption.
• Denial-of-service via crafted inputs that crash, hang, or exhaust resources during install or update.

• Vulnerabilities inside the individual services that xchain-node installs (report those against xchain-decoder, xchain-indexer, xchain-hub, etc.).
• The operator's own host hardening and Docker daemon configuration.
• Misconfiguration of the operator's network exposure (for example, binding a service to a public interface without a firewall).
• Attacks that require the operator's shell access or already-compromised Docker socket.
• Compromise of upstream npm dependencies (we mitigate via audit + review, but a backdoor in a dep is the dep author's incident, though we still want to hear about it).

If you are unsure, send the report anyway and we will tell you whether it falls in scope.

• Give us a reasonable window to fix before disclosing publicly. The 90-day ceiling is firm; earlier is fine once a fix has shipped and operators are protected.
• Test against regtest or testnet where possible (the xchain-regtest-miner plus a local stack make this easy). Mainnet proofs-of-concept are accepted but should be the minimum needed.
• Do not run automated scanners against shared XChain infrastructure in a way that would impact availability for other operators.
• Do not access data, or attempt to access data, beyond what is needed to demonstrate the issue.

• Confirm receipt within the SLA above.
• Keep you informed as triage and remediation proceed.
• Credit you in the advisory and CHANGELOG.md entry, on request.
• Coordinate a CVE assignment when the severity warrants it.
• Publish a post-fix advisory describing the issue, the fix, and the affected version range.

We ship security fixes against the latest release on master. Older releases are unsupported. The current version is recorded in CHANGELOG.md and the badge in README.md.

Last reviewed: 2026-06-16.