GHSA-3jpj-v3xr-5h6g — zrok
MEDIUMGHSA-3jpj-v3xr-5h6g is a medium-severity (CVSS 5.3) CWE-284 vulnerability in github.com/openziti/zrok. A fix is available for github.com/openziti/zrok — see the affected versions and patch details below.
zrok: Broken ownership check in DELETE /api/v2/unaccess allows non-admin to delete global frontend records
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-3jpj-v3xr-5h6g.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-3jpj-v3xr-5h6g by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 379,842 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
github.com/openziti/zrok🐹github.com/openziti/zrok/v2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary The unaccess handler (controller/unaccess.go) contains a logical error in its ownership guard: when a frontend record has environment_id = NULL (the marker for admin-created global frontends), the condition short-circuits to false and allows the deletion to proceed without any ownership verification. A non-admin user who knows a global frontend token can call DELETE /api/v2/unaccess with any of their own environment IDs and permanently delete the global frontend, taking down all public shares routed through it.
Attack Vector: Network — the endpoint is a standard HTTP API call.
Attack Complexity: High — successful exploitation requires prior knowledge of a global frontend token. These tokens are not returned to non-admin users by any standard API endpoint; obtaining one requires an out-of-band step (e.g., leaked server logs, admin documentation for a self-hosted instance, or social engineering).
Privileges Required: Low — a valid user account with at least one registered environment is required; no admin privileges needed.
User Interaction: None.
Scope: Unchanged — the impact stays within the same server instance.
Confidentiality Impact: None — no data is disclosed.
Integrity Impact: None — no data is improperly modified; the record is deleted (not corrupted).
Availability Impact: High — deleting a global frontend disrupts every public share routed through it on the instance, constituting a platform-wide availability impact.
Affected Component controller/unaccess.go — unaccessHandler.Handle (line 56)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/openziti/zrok | all versions | No fix |
| 🐹Go | github.com/openziti/zrok/v2 | all versions | 2.0.1go get github.com/openziti/zrok/v2@v2.0.1 |
Affected Products
zroknetfoundryDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openziti/zrok, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
No patched version of github.com/openziti/zrok has shipped for GHSA-3jpj-v3xr-5h6g yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-3jpj-v3xr-5h6g in your dependencies?
Find it across Go, including transitive dependencies.