zrok CVE-2026-40303
HIGH
GHSA-cpf9-ph2j-ccr9
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
A single unauthenticated network request reaches the parser pre-auth (AV:N/AC:L/PR:N/UI:N); impact is availability-only OOM confined to the process, so C:N/I:N/A:H and S:U.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary endpoints.GetSessionCookie parses an attacker-supplied cookie chunk count and calls make([]string, count) with no upper bound before any token validation occurs. The function is reached on every request to an OAuth-protected proxy share, allowing an unauthenticated remote attacker to trigger gigabyte-scale heap allocations per request, leading to process-level OOM termination or repeated goroutine panics. Both publicProxy and dynamicProxy are affected.
- Attack Vector: Network - exploitable via a single HTTP request with a crafted Cookie header.
- Attack Complexity: Low - no preconditions or chaining required; the attacker only needs to know the cookie name (publicly derivable from any OAuth redirect).
- Privileges Required: None - reached before JWT validation or any authentication check.
- User Interaction: None.
- Scope: Unchanged - impact is confined to the affected proxy process.
- Confidentiality Impact: None.
- Integrity Impact: None.
Availability Impact: High - sustained or concurrent requests cause OOM process termination, taking down the proxy for all users of all shares it serves.
Affected Components
- endpoints/oauthCookies.go - GetSessionCookie (line 81)
- endpoints/publicProxy/authOAuth.go - handleOAuth (line 50) - call site, pre-auth
- endpoints/dynamicProxy/cookies.go - getSessionCookie (line 29) - call site
AnalysisAI
Unauthenticated denial of service in zrok's OAuth-protected proxy shares (openziti/zrok <= 1.1.11 and v2 < 2.0.1) lets a remote attacker crash the proxy process with a single crafted Cookie header. The GetSessionCookie routine reads an attacker-controlled cookie-stripe count and performs make([]string, count) with no upper bound before any authentication, driving gigabyte-scale heap allocations that cause OOM termination or goroutine panics across every share the proxy serves. There is no public exploit identified at time of analysis, and EPSS is low (0.06%), but exploitation is trivially automatable per CISA SSVC.
Technical ContextAI
zrok is an open-source, self-hostable network-sharing/reverse-tunneling platform built on the OpenZiti zero-trust overlay (Go packages pkg:go/github.com_openziti_zrok and .../zrok_v2). The flaw is a classic CWE-400 Uncontrolled Resource Consumption: the OAuth session cookie is 'striped' across multiple cookie chunks, and endpoints/oauthCookies.go GetSessionCookie (line 81) trusts the attacker-supplied chunk count to pre-size a slice via make([]string, count) with no ceiling. Because the Go runtime eagerly allocates the backing array, a large declared count forces an immediate large heap allocation. The vulnerable function is invoked from both the publicProxy (endpoints/publicProxy/authOAuth.go handleOAuth, line 50) and dynamicProxy (endpoints/dynamicProxy/cookies.go getSessionCookie, line 29) code paths, and critically it runs before JWT/token validation, so no valid session is needed to reach it.
RemediationAI
Vendor-released patch: 2.0.1 - upgrade the v2 module (github.com/openziti/zrok/v2) to 2.0.1, which adds a configurable upper limit on OAuth session cookie stripes with a hard cap of 32 and a default of 10 (issue #1217). For the v1 line (<= 1.1.11) no fixed version is listed in the advisory, so migrating to the patched v2.0.1 release is the reliable remediation; verify with the vendor before relying on any v1 backport. Advisory: https://github.com/openziti/zrok/security/advisories/GHSA-cpf9-ph2j-ccr9. As compensating controls until patched, place the proxy behind a reverse proxy or WAF that rejects requests with abnormally long or malformed OAuth session cookie headers (cap total Cookie header size and the number of striped cookie chunks), and apply per-process memory limits with automatic restart (e.g. systemd MemoryMax with Restart=on-failure or a container memory limit) so an OOM crash self-heals rather than staying down - the trade-off is that legitimate very-large sessions could be truncated and the process may still briefly drop requests on restart. Rate-limiting requests to the OAuth proxy endpoint reduces sustained-flood impact but does not stop a single large-allocation request.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today