Security fixes are released for the latest minor version of zn-gate (npm and PyPI). Upgrade to it to receive them.

Prereleases (-alpha, -beta, -rc) are not supported once the final release is out.

Releases ship weekly; out-of-cycle releases only for high or critical vulnerabilities or a broken install.

We take the security of zn, the MCP Gateway, and our client SDKs seriously. If you have discovered a security vulnerability, please report it to us privately. Do not open a public issue or pull request.

• Preferred: GitHub private vulnerability reporting. Open the Security tab of this repository and click Report a vulnerability (direct link). The report stays private between you and the maintainers, and we can work on the fix and the advisory with you there.
• Alternative: email security@usezn.com, for example if you do not have a GitHub account or the issue affects the usezn.com platform rather than this repository.

Please include detailed reproduction steps, proof-of-concept payloads or scripts, and affected versions, components or commits. Testing against local Docker containers or isolated test accounts is strongly encouraged.

The project has a single maintainer today (see MAINTAINERS.md). These are targets, for both channels:

We keep you updated at least every 14 days until the issue is resolved, and tell you if a target will be missed and why.

These reports are not accepted as vulnerabilities:

• Denial of Service (DoS/DDoS) attacks
• Social engineering or phishing targeting zn personnel
• Third-party services hosting our assets (for example AWS, Cloudflare)
• Automated scanner spam without actionable proof-of-concept
• Missing hardening headers or best practices without a demonstrable security impact
• Findings that require physical access or a compromised end-user device
• Unverified reports (no reproduced steps and no observed result)

1. Private triage. We confirm the issue, assess its severity and affected versions, and open a draft GitHub Security Advisory (or use the one you opened through private vulnerability reporting). You are invited to it.
2. CVE. For an issue in a released package, we request a CVE through GitHub from the advisory.
3. Fix. For a reported issue, the fix is developed and reviewed privately (for example in the advisory's temporary private fork), with tests that reproduce the issue. For an issue we find ourselves, the fix may go through public pull requests: a critical or high severity fix ships in a patch release as soon as it is ready, with only the fixes it needs, from a release/X.Y.Z branch; a medium or low severity fix ships in the next weekly release with its advisory (see the release schedule).
4. Release. The fixed version is published to npm and PyPI by the Release workflow, with signatures and provenance. A fix for a critical or high severity issue ships in a patch release as soon as it is ready; a fix for a medium or low severity issue ships in the next weekly release (release schedule).
5. Disclosure. We publish the advisory, the release notes and the changelog entry together: affected versions, impact, what to do, and credit to the reporter (unless you prefer to stay anonymous). Advisories describe the class of problem, not step-by-step exploitation.

We ask you to keep the details private until the advisory is published, and we aim to publish within 90 days of your report. If a fix needs longer, we agree a date with you; if the issue is being exploited, we may publish earlier with mitigations.

Example: GHSA-rf3f-ppm5-3xrx (zn run on Windows) was found in an internal review. The fixes were merged through pull requests, cherry-picked onto a release/1.5.1 branch made from main, published as 1.5.1 through the release workflow, and disclosed with the advisory and the release notes on the same day.

Starting with the first release after 1.5.0-beta.1, the npm and PyPI packages are built and published by the Release workflow with trusted publishing; no long-lived publish tokens are used. 1.5.0-beta.1 and earlier versions were published by hand and have no signatures, attestations or provenance. Each GitHub Release from the workflow includes SHA256SUMS and Sigstore bundles, every file has a GitHub build provenance attestation (SLSA Build Level 3 from 1.12.0 on: built and signed by the reusable build-release.yml workflow), and npm and PyPI show provenance for each version. Step-by-step checks: docs/verify-release.md.

We consider security research conducted in accordance with this policy to be authorized. If you make a good-faith effort to avoid privacy violations, data destruction, and service interruption, we commit to:

• Not pursuing legal action against you.
• Working with you transparently to understand and validate the issue.
• Publicly acknowledging your contribution (unless you prefer anonymity).

We gratefully acknowledge independent security researchers who have helped protect the zn ecosystem through coordinated, responsible disclosure:

• GHSA-q7p5-7x6r-fm4r — zn-gate for Python 1.2.3 to 1.13.0: the LangChain callback handler did not stop blocked tool calls or hide secrets in tool output (fixed in 1.13.1)
• GHSA-qwh8-5vj5-mvj8 — zn-gate for Node.js 1.2.3 to 1.12.0: shield, check_tool_result and optional cloud analysis did not redact some provider token formats (fixed in 1.13.0)
• GHSA-rccq-h3xc-j9qj — zn-gate agent hooks for Node.js 1.5.0 to 1.11.0: a protected file reached indirectly, or a command too long or slow to check, could be read or run without being checked (fixed in 1.12.0)
• GHSA-9v62-q43j-crjm — zn-gate agent hooks for Node.js 1.5.0-beta.1 to 1.8.0: a crafted .env, .npmrc or .znrules file could make the secret scrubber time out and let tool output through unscrubbed (fixed in 1.8.1)
• GHSA-f927-55cp-x265 — zn-gate agent hooks for Node.js 1.5.0-beta.1 to 1.8.0: a crafted Codex CLI patch could write to protected files without being checked (fixed in 1.8.1)
• GHSA-2fg6-2frm-mr92 — zn-gate agent hooks for Node.js 1.5.0-beta.1 to 1.7.0: a slow path check on a crafted command word could let a protected read run unchecked (fixed in 1.7.1)
• GHSA-q5w2-m7j6-v464 — zn-gate scan for Node.js 1.4.0 to 1.7.0 could print secret values in its output and CI logs (fixed in 1.7.1)
• GHSA-wvv2-f3m6-6wrq — zn-gate for Node.js: an agent could run zn admin commands through a versioned package call (npx -y zn-gate@<version> ...), skipping the hook that denies them (fixed in 1.6.0)
• GHSA-rf3f-ppm5-3xrx — zn-gate for Node.js on Windows: zn run could hand secrets to a program chosen through the environment (fixed in 1.5.1)
• GHSA-r4h2-qcf2-8227 — zn-gate 1.4.0 and earlier sent tool output and tool-call arguments to api.usezn.com without redaction when ZN_API_KEY was set (fixed in 1.4.1)
• SEC-2026-01 — Control-plane authorization gap in zn management API (Remediated in commit 6ebce2f)
• SEC-2026-02 — Insufficient session and token revocation on password reset (Remediated in the usezn.com platform, which is not part of this repository)
• SEC-2026-03 — Incomplete session revocation on password change (Remediated in the usezn.com platform, which is not part of this repository)
• SEC-2026-04 — Session termination flow hardening: logout redirects and error handling (Remediated in the usezn.com platform, which is not part of this repository)