Listen to this Post
Intro
The vulnerability is located in `internal/web/session.go` and internal/web/oidc.go, which set `HttpOnly` and `SameSite=Lax` on every cookie but never apply the `Secure` flag. The `Secure` flag ensures that a cookie is transmitted only over HTTPS, preventing it from being sent over unencrypted HTTP connections. Because the flag is missing, the session cookie is included in plaintext HTTP requests as well. An attacker who can observe a single plaintext HTTP request to the origin — for instance, by being on the same LAN, tricking the operator into a mistyped HTTP URL, exploiting a reverse proxy misconfiguration, or bypassing HTTP→HTTPS enforcement — can capture the session cookie. Once captured, the attacker can impersonate the operator for the entire 24‑hour TTL of the session. The OIDC state cookie, which lacks the `Secure` flag as well, has a shorter 10‑minute window but still enables CSRF attacks on the OIDC callback during that period. The issue affects all released versions up to v0.3.1. The suggested fix is to introduce an explicit `cookie_secure` configuration option, defaulting to `true` when `tls_cert` and `tls_key` are set, otherwise false. Operators behind a TLS‑terminating reverse proxy must set `cookie_secure: true` manually. The fix also adds matching `HttpOnly` and `SameSite=Lax` to logout and OIDC state‑clear cookies so that browsers replace the original cookies reliably.
DailyCVE Form
Platform: `nebula-mgmt`
Version: `all ≤ v0.3.1`
Vulnerability : `Missing Secure flag`
Severity: `medium`
date: `2026-06-08`
Prediction: `Patch 2026-06-15`
What Undercode Say
Check for missing Secure flag in login response curl -i -X POST -d 'username=admin&password=...' http://127.0.0.1:8080/ui/login | grep -i 'Set-Cookie' Monitor plaintext HTTP traffic for session cookie tcpdump -i eth0 -A -s 0 'tcp port 8080' | grep 'nebula_session' Validate that OIDC state cookie also lacks Secure curl -i -X GET 'http://127.0.0.1:8080/ui/login?oidc=true' | grep -i 'Set-Cookie'
Exploit
- Position the attacker on a network path between the operator and the nebula-mgmt server (same LAN, compromised router, or unencrypted Wi‑Fi).
- Induce a plaintext HTTP request from the operator, e.g., by sending a link to `http://target:8080/ui/login` or waiting for a mistyped URL.
- Capture the outgoing HTTP request using a sniffer or a malicious proxy.
- Extract the `nebula_session` cookie from the `Set-Cookie` header.
- Reuse the stolen cookie in a browser or tool to impersonate the operator for the next 24 hours.
Protection
– Upgrade to nebula-mgmt v0.3.2 or later.
– In the configuration, set `cookie_secure: true` explicitly, especially when running behind a TLS‑terminating reverse proxy.
– Enforce HTTPS everywhere — use HSTS to prevent accidental HTTP requests.
– For existing deployments, expect a one‑time logout for all users after flipping cookie_secure; old cookies without the `Secure` attribute will not be overwritten by the new delete‑cookie.
Impact
- Session hijacking: Full operator access for 24 hours after a single captured HTTP request.
- Operator impersonation: The attacker can perform any administrative action (manage CAs, mint API keys, change settings, disable operators).
- CSRF on OIDC callback: Within the 10‑minute OIDC state window, an attacker can forge a callback and potentially link their own identity to the operator’s session.
- Widespread exposure: Many Nebula mesh deployments use the management interface behind reverse proxies or on internal LANs, making them susceptible to plaintext requests.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
