WIZARDGANG
Source

Security

Report suspected vulnerabilities privately, understand the coordinated disclosure process, and review disclosure-safe published advisories.

Do not open a public issue for sensitive security information. Private report contents are never exposed through the public assurance registry.

Private reporting

Report vulnerability

Use the repository's private vulnerability channel for suspected vulnerabilities, active security incidents, credentials, exploit details, or sensitive infrastructure information.

Open a private security reportPublished advisory JSON
References
Security page implementationSecurity policy sourceMachine-readable security.txtPublished repository advisoriesAdvisory datasetAdvisory schemaCanonical assurance serviceCanonical reporting APIPublication policy

What to report

Describe the affected route, component, or release; the observed behavior and impact; reproducible steps; and any safe supporting evidence. Keep reporter identity, exploit detail, and sensitive infrastructure context inside the private channel.

What happens next

The report is privately triaged. Maintainers may request clarification, reject a non-security report, coordinate remediation in a draft GitHub Security Advisory, and publish only disclosure-safe information after a fix is released.

Non-security concerns

Bugs, feature requests, accessibility issues, AI/MCP concerns, and other non-sensitive feedback belong in the repository's public issue forms.

Choose a public issue form →

Coordinated disclosure

Disclosure process

Private report → triage → GHSA → fix/release → eligible CVE → public advisory.

  1. Private report. Suspected vulnerabilities enter GitHub private vulnerability reporting. Reporter identity, private reproduction detail, attachments, credentials, and sensitive infrastructure information remain private.
  2. Triage. Maintainers validate scope and impact, request clarification when needed, and decide whether the report is a security vulnerability. Triage data is not public assurance data.
  3. GHSA coordination. A confirmed issue may be managed in a draft GitHub Security Advisory while remediation is coordinated. Draft advisory content remains private.
  4. Fix and release. The vulnerability is remediated and a fixed release is published before this registry creates a public advisory record.
  5. Eligible CVE. A CVE is requested or associated only when appropriate and is included here only after an actual public identifier is assigned.
  6. Public advisory. The sanitized GitHub Security Advisory is published, then its public GHSA identity, severity, summary, fixed release, optional CVE, evidence, and any valid incident linkage may enter the canonical public assurance dataset.

Incident linkage is optional and never automatic. An advisory may reference an INC-* record only when that actual incident already exists in the retained incident register. Publishing an advisory does not create an incident record.

Published disclosure

Published advisories

0 public advisory records in the canonical assurance dataset. Private reports and private GitHub draft advisories are deliberately excluded; reviewed public assurance records may use the Draft lifecycle state.

No published advisories are established

The public assurance registry currently contains no published security advisory records. This is not a claim that no vulnerabilities, private reports, defects, or security investigations have existed.