This project produces images that people run next to wallets holding funds. Reports are taken seriously and handled privately.

Do not open a public issue.

Use GitHub's private vulnerability reporting:

Report a vulnerability →

That creates a private advisory only you and the maintainers can see. It needs no email address, and it gives us a place to work on a fix and coordinate disclosure with you.

If that form is unavailable, contact a maintainer listed in .github/CODEOWNERS through their GitHub profile and ask for a private channel. Do not include details until one is established.

• What the issue is, and what an attacker gains
• Affected image tags or commit
• Reproduction steps, or a proof of concept
• Anything you already know about mitigations

This is a community project, not a company with an on-call rota. If you have not heard back within a week, please ping the advisory — it is far more likely to be an oversight than a decision.

The image and this repository's tooling:

• The Dockerfile and the binary verification chain
• entrypoint.sh, healthcheck.sh, the verus wrapper, and the libraries in rootfs/usr/local/lib/verus/
• The bootstrap and Zcash parameter download paths
• Credential generation, storage and permissions
• The Prometheus exporter
• Compose examples, Kubernetes manifests and the Helm chart, where a default exposes something it should not
• The release workflow, signing, and anything else that could let someone publish an image users would trust

Insecure defaults are in scope even without an exploit. If a shipped example exposes RPC, leaks a credential, or weakens verification, that is a valid report.

Vulnerabilities in the Verus daemon or protocol belong with VerusCoin/VerusCoin, not here. We containerise the upstream daemon and do not modify, patch or fork it. Consensus bugs, RPC vulnerabilities in verusd, cryptographic issues and P2P protocol flaws are all upstream.

If you are unsure which side of the line something falls on, report it here and we will help route it.

Also out of scope:

• Vulnerabilities in Debian packages with no fix available upstream (we rebuild weekly to pick fixes up as they land)
• Findings that require an attacker who already has root on the host
• Deliberate, documented trade-offs — for example BOOTSTRAP_INSECURE_TLS=true. It is opt-in and warns loudly at runtime. Note what it does not buy you: the checksum sidecar is fetched over the same unauthenticated connection as the archive, so anyone able to intercept that traffic can supply both. The SHA-256 check still catches corruption and truncation; it does not establish who served the file.
• Reports that a user who sets RPC_ALLOW_IP=0.0.0.0/0 can be attacked. The entrypoint warns prominently; that is working as intended.

Every release is built only by CI from a git tag, signed with cosign keyless signing, and ships an SPDX SBOM.

Verify the signature:

cosign verify ghcr.io/chainvue/verus-docker:v1.2.17-2-r1 \
  --certificate-identity-regexp 'https://github.com/chainvue/verus-docker/.github/workflows/release.yml@.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

A valid result proves the image was produced by this repository's release workflow, not by someone with registry credentials.

Inspect the SBOM:

cosign download attestation ghcr.io/chainvue/verus-docker:v1.2.17-2-r1 \
  | jq -r '.payload' | base64 -d | jq '.predicate'

The SBOM is also attached to each GitHub release.

VerusCoin publishes no SHA256SUMS, .asc or .sig release asset. The SHA-256 values embedded in the release notes reference nothing that ships in the release — verified against v1.2.17-2, where the advertised value matched neither the outer .tgz, the inner .tar.gz, nor any extracted file.

Each archive does contain a VerusID signature file. Checking that signature needs a Verus node to resolve the signing identity on chain — impossible inside a container build, but perfectly possible from a script with network access.

So verification happens where it can, at version-bump time:

scripts/verify-release.sh          # the version pinned in the Dockerfile

It downloads both architectures, confirms the signature file's hash matches the tarball, and asks a Verus node whether Verus Coin Foundation Releases@ really signed it. upstream-watch runs this on every bump and records the answer in the pull request; a rejected signature fails the job outright.

By default it asks the public gateway the Verus wallet uses. Set VERIFY_RPC_URL to your own node if you would rather not trust it — the answer should be identical, and a disagreement is itself worth knowing about.

The root of trust for the image build is still the pinned checksum, because the build has no network identity to consult. What changed is that the checksum is no longer merely eyeballed: it is now tied, at bump time, to a signature the chain confirms. An attacker who replaced the archive would have to also produce a valid Foundation signature.

This project never asks for, generates, transmits or stores private keys beyond the standard wallet.dat in a volume you own. No feature will be added that does.

If anything claiming to be part of this project asks for your seed phrase or private keys, it is not. Report it.