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.
1048 vulnerabilities reference this CWE, most recent first.
GHSA-8W95-2VQ2-PMF9
Vulnerability from github – Published: 2024-09-23 03:30 – Updated: 2026-04-01 18:31Authentication Bypass by Spoofing vulnerability in Peter Hardy-vanDoorn Maintenance Redirect allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Maintenance Redirect: from n/a through 2.0.1.
{
"affected": [],
"aliases": [
"CVE-2024-45453"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-23T01:15:11Z",
"severity": "LOW"
},
"details": "Authentication Bypass by Spoofing vulnerability in Peter Hardy-vanDoorn Maintenance Redirect allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Maintenance Redirect: from n/a through 2.0.1.",
"id": "GHSA-8w95-2vq2-pmf9",
"modified": "2026-04-01T18:31:55Z",
"published": "2024-09-23T03:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45453"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/jf3-maintenance-mode/vulnerability/wordpress-maintenance-redirect-plugin-2-0-1-ip-bypass-vulnerability?_s_id=cve"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/jf3-maintenance-mode/wordpress-maintenance-redirect-plugin-2-0-1-ip-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8WX9-J7J5-H9VP
Vulnerability from github – Published: 2026-08-12 21:31 – Updated: 2026-09-03 22:32Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-3mp7-4rh5-jrv9. This link is maintained to preserve external references.
Original Description
SiYuan versions <= v3.7.2 (patched in v3.7.4) contain an authentication bypass vulnerability in the kernel's CheckAuth function, which grants the administrator role (RoleAdministrator) to any request whose RemoteAddr is loopback (127.0.0.1) for a specific set of endpoints (including /api/system/exit, getNetwork, getWorkspaceInfo, /assets/, and /export/). These localhost bypasses sit outside the access auth code gate, so they apply even when an access auth code is configured. Because the fixed-port reverse proxy forwards requests to the kernel over loopback without injecting an authentication token and does not configure trusted proxies, a request forwarded through this proxy reaches the kernel with RemoteAddr = 127.0.0.1. If the fixed-port proxy is bound to a network interface, this could allow a remote unauthenticated attacker to obtain admin access on the affected endpoints; however, per the advisory this remote forwarding behavior was established only by code inspection and was not reproduced end-to-end.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.7.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T22:32:26Z",
"nvd_published_at": "2026-08-12T20:17:53Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-3mp7-4rh5-jrv9. This link is maintained to preserve external references.\n\n## Original Description\nSiYuan versions \u003c= v3.7.2 (patched in v3.7.4) contain an authentication bypass vulnerability in the kernel\u0027s CheckAuth function, which grants the administrator role (RoleAdministrator) to any request whose RemoteAddr is loopback (127.0.0.1) for a specific set of endpoints (including /api/system/exit, getNetwork, getWorkspaceInfo, /assets/*, and /export/*). These localhost bypasses sit outside the access auth code gate, so they apply even when an access auth code is configured. Because the fixed-port reverse proxy forwards requests to the kernel over loopback without injecting an authentication token and does not configure trusted proxies, a request forwarded through this proxy reaches the kernel with RemoteAddr = 127.0.0.1. If the fixed-port proxy is bound to a network interface, this could allow a remote unauthenticated attacker to obtain admin access on the affected endpoints; however, per the advisory this remote forwarding behavior was established only by code inspection and was not reproduced end-to-end.",
"id": "GHSA-8wx9-j7j5-h9vp",
"modified": "2026-09-03T22:32:26Z",
"published": "2026-08-12T21:31:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-3mp7-4rh5-jrv9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72809"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-authentication-bypass-via-localhost-trust"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:H/SC:N/SI:N/SA:N/E:X/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:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: Localhost-trust admin bypass on auth-code-gated endpoints, with potential remote reachability via the fixed-port prox",
"withdrawn": "2026-09-03T22:32:26Z"
}
GHSA-8XPV-H7VW-HC6H
Vulnerability from github – Published: 2022-05-24 19:21 – Updated: 2026-08-19 18:31Microsoft Edge (Chromium-based) Spoofing Vulnerability
{
"affected": [],
"aliases": [
"CVE-2021-42308"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-24T01:15:00Z",
"severity": "HIGH"
},
"details": "Microsoft Edge (Chromium-based) Spoofing Vulnerability",
"id": "GHSA-8xpv-h7vw-hc6h",
"modified": "2026-08-19T18:31:45Z",
"published": "2022-05-24T19:21:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42308"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-42308"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-42308"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8XXP-H8M6-WXX9
Vulnerability from github – Published: 2026-07-01 00:34 – Updated: 2026-07-01 18:31Incorrect security UI in TabStrip in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)
{
"affected": [],
"aliases": [
"CVE-2026-13984"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-451"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-30T23:17:11Z",
"severity": "MODERATE"
},
"details": "Incorrect security UI in TabStrip in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium)",
"id": "GHSA-8xxp-h8m6-wxx9",
"modified": "2026-07-01T18:31:33Z",
"published": "2026-07-01T00:34:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13984"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html"
},
{
"type": "WEB",
"url": "https://issues.chromium.org/issues/514010404"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-934Q-GQ37-GQ89
Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12Inappropriate implementation in Autofill in Google Chrome prior to 93.0.4577.63 allowed a remote attacker to spoof security UI via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-30619"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-03T20:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Autofill in Google Chrome prior to 93.0.4577.63 allowed a remote attacker to spoof security UI via a crafted HTML page.",
"id": "GHSA-934q-gq37-gq89",
"modified": "2022-05-24T19:12:58Z",
"published": "2022-05-24T19:12:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30619"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/08/stable-channel-update-for-desktop_31.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1235222"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5LVY4WIWTVVYKQMROJJS365TZBKEARCF"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJPUSAWIJMQFBQQQYXAICLI4EKFQOH6"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QW4R2K5HVJ4R6XDZYOJCCFPIN2XHNS3L"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-30619"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-93FH-97QR-4F47
Vulnerability from github – Published: 2024-05-17 09:31 – Updated: 2024-05-17 09:31Authentication Bypass by Spoofing vulnerability in Stefano Lissa & The Newsletter Team Newsletter allows Functionality Bypass.This issue affects Newsletter: from n/a through 8.2.0.
{
"affected": [],
"aliases": [
"CVE-2024-30522"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-17T09:15:29Z",
"severity": "MODERATE"
},
"details": "Authentication Bypass by Spoofing vulnerability in Stefano Lissa \u0026 The Newsletter Team Newsletter allows Functionality Bypass.This issue affects Newsletter: from n/a through 8.2.0.",
"id": "GHSA-93fh-97qr-4f47",
"modified": "2024-05-17T09:31:02Z",
"published": "2024-05-17T09:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30522"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/newsletter/wordpress-newsletter-plugin-8-2-0-ip-blacklist-bypass-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-93J5-G9F6-H7XV
Vulnerability from github – Published: 2023-05-25 09:30 – Updated: 2024-04-04 04:20Authentication Bypass by Spoofing vulnerability in CBOT Chatbot allows Authentication Bypass.This issue affects Chatbot: before Core: v4.0.3.4 Panel: v4.0.3.7.
{
"affected": [],
"aliases": [
"CVE-2023-2887"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-25T09:15:12Z",
"severity": "CRITICAL"
},
"details": "Authentication Bypass by Spoofing vulnerability in CBOT Chatbot allows Authentication Bypass.This issue affects Chatbot: before Core: v4.0.3.4 Panel: v4.0.3.7.\n\n",
"id": "GHSA-93j5-g9f6-h7xv",
"modified": "2024-04-04T04:20:19Z",
"published": "2023-05-25T09:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2887"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-23-0293"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-93QH-5269-9WCF
Vulnerability from github – Published: 2026-08-06 19:25 – Updated: 2026-08-06 19:25Impact
When OAuth login is enabled with a provider that does not guarantee verified email addresses, an unauthenticated attacker could sign in as an existing user — potentially including a super admin — without their password. Exploitation requires OAuth to be explicitly enabled with such a provider.
Patches
Fixed in 5.74.1 and 6.24.0.
Workarounds
Only enable OAuth with providers that guarantee verified email addresses, or disable OAuth login.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "statamic/cms"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.74.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Packagist",
"name": "statamic/cms"
},
"ranges": [
{
"events": [
{
"introduced": "6.0.0"
},
{
"fixed": "6.24.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-64665"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-06T19:25:05Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Impact\n\nWhen OAuth login is enabled with a provider that does not guarantee verified email addresses, an unauthenticated attacker could sign in as an existing user \u2014 potentially including a super admin \u2014 without their password. Exploitation requires OAuth to be explicitly enabled with such a provider.\n\n### Patches\n\nFixed in 5.74.1 and 6.24.0.\n\n### Workarounds\n\nOnly enable OAuth with providers that guarantee verified email addresses, or disable OAuth login.",
"id": "GHSA-93qh-5269-9wcf",
"modified": "2026-08-06T19:25:05Z",
"published": "2026-08-06T19:25:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/statamic/cms/security/advisories/GHSA-93qh-5269-9wcf"
},
{
"type": "WEB",
"url": "https://github.com/statamic/cms/pull/14887"
},
{
"type": "WEB",
"url": "https://github.com/statamic/cms/commit/e59dd342c83bc45de26573cfb0536a0bca98255a"
},
{
"type": "PACKAGE",
"url": "https://github.com/statamic/cms"
},
{
"type": "WEB",
"url": "https://github.com/statamic/cms/releases/tag/v5.74.1"
},
{
"type": "WEB",
"url": "https://github.com/statamic/cms/releases/tag/v6.24.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Statamic: Account takeover via OAuth email matching without email-verification check"
}
GHSA-9468-V6MJ-FPPW
Vulnerability from github – Published: 2026-09-02 23:41 – Updated: 2026-09-02 23:41Vulnerability Details
File: internal/client/handler.go (OnClientConnecting), internal/proxy/http.go (requestHeaders), internal/proxy/grpc.go (requestMetadata), internal/unigrpc/grpc.go (Consume)
Line: handler.go:389,548-552 (e.Headers -> SetEmulatedHeadersToContext), http.go:131-165 (requestHeaders), grpc.go:82-114 (requestMetadata), unigrpc/grpc.go:46 (Headers: req.Headers)
Root Cause
The http_headers / grpc_metadata proxy config options are documented as "List of incoming HTTP header names to forward to the proxy backend" / "List of incoming gRPC metadata keys to forward to the proxy backend" -- implying the value originates from the underlying transport connection (e.g. set by a trusted reverse proxy/API gateway in front of Centrifugo). Operators commonly use this to forward identity/trust headers to their own backend for access-control decisions.
However, the wire protocol used by every Centrifugo transport (protocol.ConnectRequest, field headers) includes a headers map populated entirely from the connecting client's own message (its JSON connect command, or for gRPC, its ConnectRequest protobuf field) -- not from real transport-level HTTP headers. Centrifugo copies this client-supplied map verbatim into ConnectEvent.Headers, then into an "emulated headers" context value used by every proxy type (connect, refresh, subscribe, publish, rpc, sub_refresh, map_publish, map_remove, shared_poll_refresh) for the entire connection lifetime. Any header name in the operator's allowlist is forwarded to the backend with the client's own chosen value, unless a header of the exact same name also happens to be present on the genuine underlying HTTP request. For the unidirectional gRPC transport specifically there is no HTTP request at all, so there is no possible override -- the client-controlled value always wins.
Attack Scenario
- Operator configures a connect proxy with
http_headers: ["x-trusted-user"](or any header name their backend uses for caller identity/trust). - Attacker connects directly to Centrifugo and sends a connect command containing
"headers": {"x-trusted-user": "<any value>"}. - Centrifugo forwards
X-Trusted-User: <attacker value>to the backend exactly as if a trusted intermediary had set it. - The backend, trusting this header per its own design, grants whatever access/identity it associates with that value.
Impact
Full spoofing of any header value the backend trusts for authentication/authorization, for every proxy call type, for the lifetime of the connection -- up to full account/identity impersonation depending on backend logic. No credentials, JWT, or API key required.
Vulnerable Code
// internal/proxy/http.go
func requestHeaders(ctx context.Context, allowedHeaders, allowedMetaKeys []string, staticHeaders map[string]string) http.Header {
headers := http.Header{}
for k, v := range staticHeaders { headers.Set(k, v) }
emulatedHeaders, _ := clientcontext.GetEmulatedHeadersFromContext(ctx) // 100% client-controlled
for k, v := range emulatedHeaders {
if slices.Contains(allowedHeaders, strings.ToLower(k)) {
headers.Set(k, v) // forwarded to backend as a real outgoing HTTP header
}
}
httpHeaders, hasHTTPHeaders := middleware.GetHeadersFromContext(ctx) // real headers, if present
for k, vv := range httpHeaders {
if slices.Contains(allowedHeaders, strings.ToLower(k)) {
headers[k] = vv // only overrides if SAME header name was ALSO on the real request
}
}
...
}
// internal/unigrpc/grpc.go -- never goes through HTTP middleware, no competing real-header check at all
connectRequest := &protocol.ConnectRequest{
Token: req.Token, Data: req.Data, Name: req.Name, Version: req.Version,
Headers: req.Headers, // the gRPC client's own protobuf field
}
Recommended Fix
Document explicitly that http_headers/grpc_metadata values can also be supplied by the connecting client itself via "headers emulation" and are not guaranteed to come from a trusted reverse proxy. Provide a separate allowlist (e.g. trusted_http_headers) populated only from genuine transport-level HTTP headers, never from client-supplied ConnectRequest.headers, for operators who need an unforgeable header. For uniGRPC, consider disabling http_headers forwarding entirely since there is no transport-level header concept to fall back on.
Verification
Dynamically confirmed against the official centrifugo/centrifugo:v6.8.3 Docker image on BOTH the bidirectional WebSocket transport and the unidirectional gRPC transport, using a minimal backend that logs every header it receives:
- WS: connecting with {"connect": {"headers": {"x-trusted-user": "admin-impersonation-via-headers-emulation"}}} resulted in the backend receiving X-Trusted-User: admin-impersonation-via-headers-emulation, despite no such header existing on the real WebSocket upgrade HTTP request.
- uniGRPC: calling the Consume RPC with ConnectRequest(headers={"x-trusted-user": "admin-impersonation-via-unigrpc"}) (zero real gRPC metadata set) resulted in the backend receiving X-Trusted-User: admin-impersonation-via-unigrpc.
- Control tests (no headers field / no metadata) confirmed the header is absent from the backend's request in the baseline case.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.8.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/centrifugal/centrifugo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-71485"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-02T23:41:37Z",
"nvd_published_at": "2026-08-20T21:17:08Z",
"severity": "CRITICAL"
},
"details": "## Vulnerability Details\n\n**File**: `internal/client/handler.go` (`OnClientConnecting`), `internal/proxy/http.go` (`requestHeaders`), `internal/proxy/grpc.go` (`requestMetadata`), `internal/unigrpc/grpc.go` (`Consume`)\n**Line**: handler.go:389,548-552 (`e.Headers` -\u003e `SetEmulatedHeadersToContext`), http.go:131-165 (`requestHeaders`), grpc.go:82-114 (`requestMetadata`), unigrpc/grpc.go:46 (`Headers: req.Headers`)\n\n### Root Cause\nThe `http_headers` / `grpc_metadata` proxy config options are documented as \"List of incoming HTTP header names to forward to the proxy backend\" / \"List of incoming gRPC metadata keys to forward to the proxy backend\" -- implying the value originates from the underlying transport connection (e.g. set by a trusted reverse proxy/API gateway in front of Centrifugo). Operators commonly use this to forward identity/trust headers to their own backend for access-control decisions.\n\nHowever, the wire protocol used by every Centrifugo transport (`protocol.ConnectRequest`, field `headers`) includes a `headers` map populated entirely from the connecting client\u0027s own message (its JSON `connect` command, or for gRPC, its `ConnectRequest` protobuf field) -- not from real transport-level HTTP headers. Centrifugo copies this client-supplied map verbatim into `ConnectEvent.Headers`, then into an \"emulated headers\" context value used by every proxy type (connect, refresh, subscribe, publish, rpc, sub_refresh, map_publish, map_remove, shared_poll_refresh) for the entire connection lifetime. Any header name in the operator\u0027s allowlist is forwarded to the backend with the client\u0027s own chosen value, unless a header of the exact same name also happens to be present on the genuine underlying HTTP request. For the unidirectional gRPC transport specifically there is no HTTP request at all, so there is no possible override -- the client-controlled value always wins.\n\n### Attack Scenario\n1. Operator configures a connect proxy with `http_headers: [\"x-trusted-user\"]` (or any header name their backend uses for caller identity/trust).\n2. Attacker connects directly to Centrifugo and sends a connect command containing `\"headers\": {\"x-trusted-user\": \"\u003cany value\u003e\"}`.\n3. Centrifugo forwards `X-Trusted-User: \u003cattacker value\u003e` to the backend exactly as if a trusted intermediary had set it.\n4. The backend, trusting this header per its own design, grants whatever access/identity it associates with that value.\n\n### Impact\nFull spoofing of any header value the backend trusts for authentication/authorization, for every proxy call type, for the lifetime of the connection -- up to full account/identity impersonation depending on backend logic. No credentials, JWT, or API key required.\n\n### Vulnerable Code\n```go\n// internal/proxy/http.go\nfunc requestHeaders(ctx context.Context, allowedHeaders, allowedMetaKeys []string, staticHeaders map[string]string) http.Header {\n headers := http.Header{}\n for k, v := range staticHeaders { headers.Set(k, v) }\n emulatedHeaders, _ := clientcontext.GetEmulatedHeadersFromContext(ctx) // 100% client-controlled\n for k, v := range emulatedHeaders {\n if slices.Contains(allowedHeaders, strings.ToLower(k)) {\n headers.Set(k, v) // forwarded to backend as a real outgoing HTTP header\n }\n }\n httpHeaders, hasHTTPHeaders := middleware.GetHeadersFromContext(ctx) // real headers, if present\n for k, vv := range httpHeaders {\n if slices.Contains(allowedHeaders, strings.ToLower(k)) {\n headers[k] = vv // only overrides if SAME header name was ALSO on the real request\n }\n }\n ...\n}\n```\n```go\n// internal/unigrpc/grpc.go -- never goes through HTTP middleware, no competing real-header check at all\nconnectRequest := \u0026protocol.ConnectRequest{\n Token: req.Token, Data: req.Data, Name: req.Name, Version: req.Version,\n Headers: req.Headers, // the gRPC client\u0027s own protobuf field\n}\n```\n\n### Recommended Fix\nDocument explicitly that `http_headers`/`grpc_metadata` values can also be supplied by the connecting client itself via \"headers emulation\" and are not guaranteed to come from a trusted reverse proxy. Provide a separate allowlist (e.g. `trusted_http_headers`) populated only from genuine transport-level HTTP headers, never from client-supplied `ConnectRequest.headers`, for operators who need an unforgeable header. For uniGRPC, consider disabling `http_headers` forwarding entirely since there is no transport-level header concept to fall back on.\n\n### Verification\nDynamically confirmed against the official `centrifugo/centrifugo:v6.8.3` Docker image on BOTH the bidirectional WebSocket transport and the unidirectional gRPC transport, using a minimal backend that logs every header it receives:\n- WS: connecting with `{\"connect\": {\"headers\": {\"x-trusted-user\": \"admin-impersonation-via-headers-emulation\"}}}` resulted in the backend receiving `X-Trusted-User: admin-impersonation-via-headers-emulation`, despite no such header existing on the real WebSocket upgrade HTTP request.\n- uniGRPC: calling the `Consume` RPC with `ConnectRequest(headers={\"x-trusted-user\": \"admin-impersonation-via-unigrpc\"})` (zero real gRPC metadata set) resulted in the backend receiving `X-Trusted-User: admin-impersonation-via-unigrpc`.\n- Control tests (no `headers` field / no metadata) confirmed the header is absent from the backend\u0027s request in the baseline case.",
"id": "GHSA-9468-v6mj-fppw",
"modified": "2026-09-02T23:41:37Z",
"published": "2026-09-02T23:41:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/security/advisories/GHSA-9468-v6mj-fppw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-71485"
},
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/pull/1182"
},
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/commit/84d38cea1dd2efa24375a148817a974c8727f4b0"
},
{
"type": "PACKAGE",
"url": "https://github.com/centrifugal/centrifugo"
},
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/releases/tag/v6.9.0"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V4"
}
],
"summary": "Centrifugo: Client-forgeable headers emulation lets any client spoof headers forwarded to proxy backends"
}
GHSA-94HH-4GMR-5MV9
Vulnerability from github – Published: 2025-09-29 15:30 – Updated: 2025-10-28 21:30A security vulnerability was identified in Obsidian Scheduler's REST API 5.0.0 thru 6.3.0. If an account is locked out due to not enrolling in MFA (e.g. after the 7-day enforcement window), the REST API still allows the use of Basic Authentication to authenticate and perform administrative actions. In particular, the default admin account was found to be locked out via the web interface but still usable through the REST API. This allowed creation of a new privileged user, bypassing MFA protections. This undermines the intended security posture of MFA enforcement.
{
"affected": [],
"aliases": [
"CVE-2025-56449"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-29T15:16:08Z",
"severity": "HIGH"
},
"details": "A security vulnerability was identified in Obsidian Scheduler\u0027s REST API 5.0.0 thru 6.3.0. If an account is locked out due to not enrolling in MFA (e.g. after the 7-day enforcement window), the REST API still allows the use of Basic Authentication to authenticate and perform administrative actions. In particular, the default admin account was found to be locked out via the web interface but still usable through the REST API. This allowed creation of a new privileged user, bypassing MFA protections. This undermines the intended security posture of MFA enforcement.",
"id": "GHSA-94hh-4gmr-5mv9",
"modified": "2025-10-28T21:30:29Z",
"published": "2025-09-29T15:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56449"
},
{
"type": "WEB",
"url": "https://blog.gregscharf.com/2025/07/11/upcoming-vulnerability-advisory"
},
{
"type": "WEB",
"url": "https://blog.gregscharf.com/2025/07/31/obsidian-scheduler-access-control-vulnerability"
},
{
"type": "WEB",
"url": "https://wiki.obsidianscheduler.com/docs/Release_Notes#Obsidian_6.3.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.