Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/preview/llms.txt
Full corpus: https://docs.registrystack.org/preview/llms-full.txt

# Report a vulnerability

> How to report a suspected Registry Stack vulnerability privately and what is in scope.

Report a suspected Registry Stack vulnerability privately. Never open a public issue or pull
request for a suspected credential disclosure, auth bypass, audit redaction failure, source
connector data leakage, or signing-key handling bug.

## When to use this

Use the private disclosure channel for anything in scope on this page.
If you are unsure whether a behavior is exploitable, report it privately.
Use a public product issue only for a known, non-exploitable gap that does not
include sensitive reproduction details.

## Before you start

Gather what the report needs before you open the channel:

- The affected commit or release tag.
- The config shape involved (redact secret values before you paste anything).
- Reproduction steps.
- The impact you observed or expect.

Do not include live credentials, bearer tokens, API keys, private keys, or raw registry records in
the report.

## Steps

1. Report privately through
   [GitHub Security Advisories](https://github.com/registrystack/registry-stack/security/advisories/new).
2. If GitHub Security Advisories is unavailable, contact the maintainer through an existing
   private project channel instead of opening a public issue or pull request.
3. Include the affected commit, config shape, reproduction steps, and impact from the checklist
   above.

Registry Stack aims to acknowledge private reports within 5 business days.

## What is in scope

Authentication bypass, credential disclosure, audit redaction failure, audit integrity failure,
signing-key handling bugs, source connector data leakage, and privacy regressions that expose raw
subject identifiers.

Known pilot limitations, such as no revocation service, no `/.well-known/jwt-vc-issuer` endpoint,
and no built-in data-subject erasure workflow, are product gaps, not vulnerabilities, unless they
create an exploitable security or privacy issue beyond the documented limitation.

## Next

- [Security overview](../)
- [Review the security support window](../support-window/)
- [Verify release trust](../openssf-evidence/)