Threats Tagged 'cve-2026-49446'
View all threats tagged with 'cve-2026-49446'. Filter and sort to focus on specific types of threats.
Stop chasing alerts. Route them.
Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.
Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)
API access activates after upgrading in Console -> Billing.
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.
Filter Threats
Narrow down the results by type, severity, or affected countries
Threats Tagged 'cve-2026-49446'
Click on any threat for detailed analysis and mitigation recommendations
Cosmos server: Cosmos-Server has an authentication bypass via forward-auth header smuggling on Constellation tunnel (CVE-2026-49446)CVE-2026-49446 0 ### Summary The Constellation-tunnel bypass branch in `tokenMiddleware` at `src/proxy/routerGen.go:53-66` returns to the upstream handler before the request's `x-cosmos-user`, `x-cosmos-role`, `x-cosmos-user-role`, and `x-cosmos-mfa` headers are stripped at lines 68-72, and before the `AdminOnlyWithRedirect` gate at lines 109-117 runs. Any holder of a valid Constellation device API key sends `x-cosmos-user: admin` to a proxied backend; the documented forward-auth integration treats the caller as admin with no JWT cookie, password, or MFA. ### Preconditions - Cosmos is deployed with Constellation enabled and at least one device enrolled. - Attacker holds a valid `x-cstln-auth` API key for an enrolled device. - Attacker reaches Cosmos over the Constellation Nebula tunnel. - Target proxy route has `AuthEnabled=true`; upstream trusts the `x-cosmos-user` forward-auth header. ### Details ```go // src/proxy/routerGen.go:46-122 - bypass returns before headers are reset func tokenMiddleware(route utils.ProxyRouteConfig) func(next http.Handler) http.Handler { return func(next http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { enabled := route.AuthEnabled adminOnly := route.AdminOnly // bypass auth if from Constellation tunnel if ((enabled && r.Header.Get("x-cosmos-user") != "") || !enabled) { // attacker-set header opens the branch remoteAddr, _ := utils.SplitIP(r.RemoteAddr) isConstIP := constellation.IsConstellationIP(remoteAddr) isConstTokenValid := constellation.CheckConstellationToken(r) == nil if isConstIP && isConstTokenValid { utils.Debug("Bypassing auth for Constellation tunnel") r.Header.Del("x-cstln-auth") next.ServeHTTP(w, r) // forwards x-cosmos-user as set by attacker return } } r.Header.Del("x-cosmos-user") // only runs on the fall-through path r.Header.Del("x-cosmos-role") r.Header.Del("x-cosmos-user-role") r.Header.Del("x-cosmos-mfa") r.Header.Del("x-cstln-auth") // ... JWT path runs here ... if enabled && adminOnly { if errT := AdminOnlyWithRedirect(w, r, route); errT != nil { // also skipped by bypass return } } next.ServeHTTP(w, r) }) } } ``` The branch was written for tunneled-cluster traffic where an upstream Cosmos instance has already authenticated the user and signed the `x-cosmos-user` header itself. The branch condition reads the header before the strip block runs at lines 68-72, so any client can open the branch by sending the header. The Constellation IP and API-key checks then gate progression, but a Constellation device holder satisfies both: the API key was issued by the admin when the device was enrolled, and the tunnel terminates with the device's Constellation IP as the TCP source. Once the branch is taken, the original `x-cosmos-user` value flows to the backend untouched, and `AdminOnlyWithRedirect` is never invoked. Backends configured per Cosmos's documented forward-auth integration (the standard pattern for "Cosmos in front of an app that reads identity from a header") treat the attacker's chosen string as the authenticated identity. The Constellation network is sold as a way for an operator to invite family and friends without exposing ports. Those invited members hold device API keys but are not Cosmos administrators - the trust boundary this bug crosses is exactly the "invited member -> admin role on a proxied app" line. ### Proof of concept Environment used to reproduce: - Version: `master` branch, audited 2026-05-13 (module `github.com/azukaar/cosmos-server`) - Deployment: `docker run azukaar/cosmos-server:latest` (or the `docker-compose.yml` from the project README) - Setup steps: 1. Complete initial setup via `/cosmos-ui/`; promote the operator account to admin. 2. Enable Constellation: Settings > Constellation > Create lighthouse. 3. Enrol a device under a non-admin user: Constellation > Devices > Create. Save the device profile and the displayed API key. 4. Configure one proxy route with `Host=admin-app.example`, `Mode=PROXY`, `Target=http://internal-app:port`, `AuthEnabled=true`, `AdminOnly=true`. Upstream must trust the `x-cosmos-user` header (the documented Cosmos forward-auth integration, e.g. an internal admin panel that reads identity from that header). 5. Attacker connects to the Nebula tunnel with the issued device profile, so the request's TCP source is the device's Constellation IP. ```bash # 1. Variables - fill in from the steps above DEVICE_APIKEY="<APIKey shown when admin created the device>" PROXY_ROUTE="https://admin-app.example" # 2. Single request that bypasses Cosmos auth and Join the discussion | GCVE Database | 07/28/2026, 20:44:33 UTC Added: 07/28/2026, 23:52:00 UTC |
Showing 1 to 1 of 1 result