Reporting a vulnerability

How to report

Report through GitHub's private vulnerability reporting on the open-source TEE repository: open Security → Report a vulnerability on nodexpert-labs/staked-quic-connection-provider.

This channel covers both halves of the system:

• TEE side: the Nitro Enclave signer, host-proxy, client SDKs, TPU client, and the deploy Terraform (all in the open-source repo).
• Marketplace platform: the API, JWT issuer, probe, settlement worker, and the web frontend. The marketplace repository does not yet publish its own security policy, so use the same private channel for platform findings until it does.

What to include

• Reproduction steps, as concrete as you can make them.
• An impact assessment if you can: what an attacker gains, and which control is bypassed.
• The affected component and version or release tag, where known.

What to expect

• Acknowledgement within 72 hours.
• Status updates at least weekly until the report is resolved.
• We ask for a reasonable window to ship a fix and roll the revocation list before any public disclosure. There is no fixed disclosure deadline, the window is coordinated per report.

The project does not currently publish formal safe-harbour language. Reports made in good faith through the private channel above are welcome, but no legal safe harbour is promised at this time.

What counts as a vulnerability

The system is a signing oracle for Solana validator identity keys. Treat any of the following as a security vulnerability:

• Any way to make the enclave sign something other than a TLS 1.3 CertificateVerify payload.
• Any way to extract key material.
• Any bypass of the lease-JWT, rate-limit, or revocation controls.
• Any way to forge or substitute a release artifact.

Highest-priority surfaces

• enclave/src/signer.rs in the TEE repo: the payload validation that restricts what the enclave will ever sign.
• deploy/terraform/kms.tf in the TEE repo: the KMS key policy that gates decryption of the validator identity key on Nitro attestation PCRs.

Reports against these two files are triaged first. On the marketplace side, the JWT issuer (KMS-backed ES256 signing) and the settlement worker's on-chain payment verification are the most sensitive paths. See the security overview and the threat model for how these controls fit together.

Out of scope and documented behavior

• Dev-only escape hatches that are compiled out of release builds (STAKED_QUIC_DEV_BYPASS_MANIFEST_SIG, the dev-plaintext build feature) are documented behavior, not vulnerabilities, unless you find a way to reach them in a release build. That last case is very much in scope.
• The K5 release-signing key is a placeholder until the production key ceremony. Findings that only apply to the placeholder setup are still welcome but will be triaged accordingly.
• Issues in validator-owned AWS accounts, the Solana protocol itself, third-party wallets, or other third-party services are outside the project's control.
• The accepted v1 side-channel residual (Nitro isolation plus constant-time Ed25519) is documented in the threat model.
• Volumetric denial of service against production endpoints.

Verifying release artifacts

Release integrity findings are in scope. Two mechanisms exist today:

• TEE releases (EIF and host-proxy) ship as GitHub Releases assets of the open-source repo. The assets themselves carry no signatures: their SHA-384 digests are embedded in a K5-signed eif-attestation-<version>.json side-car, published with a detached base64 Ed25519 signature under K5 computed over the exact side-car bytes. The revocation list (revocation.json) is detached-signed the same way. Remember the placeholder-K5 caveat above.
• Marketplace platform services (marketplace-api, marketplace-probe, marketplace-settlement) ship as Docker images built in CI from the tagged commit and deployed under that immutable tag. They are not distributed as downloadable binaries and no SLSA provenance is published for them today (documented gap; the artifacts validators actually run are the signed TEE-side ones above).

If a published artifact fails signature or provenance verification, treat that as a high-priority finding and report it through the private channel.

Bug bounty status

A paid, platform-wide bug bounty program is a pre-GA requirement and is planned, but it is not live yet. No monetary rewards are currently offered for reports. This page will be updated with scope and reward details when the program launches.