CWE-287
DiscouragedImproper Authentication
Abstraction: Class · Status: Draft
When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
5972 vulnerabilities reference this CWE, most recent first.
GHSA-G8CH-8R7R-4WWJ
Vulnerability from github – Published: 2022-12-20 00:30 – Updated: 2022-12-27 21:30The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.
{
"affected": [],
"aliases": [
"CVE-2022-46400"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-19T23:15:00Z",
"severity": "MODERATE"
},
"details": "The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.",
"id": "GHSA-g8ch-8r7r-4wwj",
"modified": "2022-12-27T21:30:21Z",
"published": "2022-12-20T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46400"
},
{
"type": "WEB",
"url": "https://microchip.com"
},
{
"type": "WEB",
"url": "https://www.computer.org/csdl/proceedings-article/sp/2023/933600a521/1He7Yja1AYM"
},
{
"type": "WEB",
"url": "https://www.computer.org/csdl/proceedings/sp/2023/1He7WWuJExG"
},
{
"type": "WEB",
"url": "https://www.microchip.com/en-us/products/wireless-connectivity/software-vulnerability-response/deviating-behaviors-in-bluetooth-le"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-G8H4-J547-7Q9P
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-10-27 19:00An exposed debug interface was reported in some Motorola-branded Binatone Hubble Cameras that could allow an attacker with physical access unauthorized access to the device.
{
"affected": [],
"aliases": [
"CVE-2021-3788"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-12T22:15:00Z",
"severity": "MODERATE"
},
"details": "An exposed debug interface was reported in some Motorola-branded Binatone Hubble Cameras that could allow an attacker with physical access unauthorized access to the device.",
"id": "GHSA-g8h4-j547-7q9p",
"modified": "2022-10-27T19:00:30Z",
"published": "2022-05-24T19:20:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3788"
},
{
"type": "WEB",
"url": "https://binatoneglobal.com/security-advisory"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G8J7-2RHP-X3W4
Vulnerability from github – Published: 2023-10-02 00:30 – Updated: 2023-10-02 00:30A vulnerability classified as problematic was found in Field Logic DataCube4 up to 20231001. This vulnerability affects unknown code of the file /api/ of the component Web API. The manipulation leads to improper authentication. The exploit has been disclosed to the public and may be used. VDB-241030 is the identifier assigned to this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2023-5329"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-02T00:15:10Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as problematic was found in Field Logic DataCube4 up to 20231001. This vulnerability affects unknown code of the file /api/ of the component Web API. The manipulation leads to improper authentication. The exploit has been disclosed to the public and may be used. VDB-241030 is the identifier assigned to this vulnerability.",
"id": "GHSA-g8j7-2rhp-x3w4",
"modified": "2023-10-02T00:30:14Z",
"published": "2023-10-02T00:30:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5329"
},
{
"type": "WEB",
"url": "https://github.com/CV3TR4CK/CV3Cyb3R/blob/main/2023/Field%20Logic/Field%20Logic%20DataCube4%20Web%20API%20Improper%20Authentication.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.241030"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.241030"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G8PG-33V4-9R96
Vulnerability from github – Published: 2024-05-30 13:26 – Updated: 2026-07-17 18:14An authentication bypass was identifed in thelia/thelia project for customer and admin. This vulnerability is present from version 2.0.0-beta1 and is fixed in 2.1.3 and 2.2.0-alpha1.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thelia/thelia"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-beta1"
},
{
"fixed": "2.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-30T13:26:47Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "An authentication bypass was identifed in thelia/thelia project for customer and admin. This vulnerability is present from version 2.0.0-beta1 and is fixed in 2.1.3 and 2.2.0-alpha1.",
"id": "GHSA-g8pg-33v4-9r96",
"modified": "2026-07-17T18:14:11Z",
"published": "2024-05-30T13:26:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/github/advisory-database/pull/8012"
},
{
"type": "WEB",
"url": "https://github.com/thelia/thelia/commit/028cfcf507cd8685772e156ec0c860034d407094"
},
{
"type": "WEB",
"url": "https://github.com/thelia/thelia/commit/71c1cee66d8f2e515e82478f792879fa63843644"
},
{
"type": "WEB",
"url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/thelia/thelia/2015-04-13-1.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/thelia/thelia"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20160502224630/http://thelia.net/version-2-1-3-with-security-fix"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Thelia authentication bypass vulnerability"
}
GHSA-G8Q3-Q7HJ-QV33
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37There is an improper authentication vulnerability in some verisons of Huawei CloudEngine product. A module does not verify the input file properly. Attackers can exploit this vulnerability by crafting malicious files to bypass current verification mechanism. This can compromise normal service.
{
"affected": [],
"aliases": [
"CVE-2020-9207"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-29T18:15:00Z",
"severity": "HIGH"
},
"details": "There is an improper authentication vulnerability in some verisons of Huawei CloudEngine product. A module does not verify the input file properly. Attackers can exploit this vulnerability by crafting malicious files to bypass current verification mechanism. This can compromise normal service.",
"id": "GHSA-g8q3-q7hj-qv33",
"modified": "2022-05-24T17:37:31Z",
"published": "2022-05-24T17:37:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9207"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20201216-01-vrp-en"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G8Q5-X5P6-C4GC
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-07-13 00:01Insufficient policy enforcement in Downloads in Google Chrome prior to 88.0.4324.96 allowed an attacker who convinced a user to download files to bypass navigation restrictions via a crafted HTML page.
{
"affected": [],
"aliases": [
"CVE-2021-21133"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-09T14:15:00Z",
"severity": "MODERATE"
},
"details": "Insufficient policy enforcement in Downloads in Google Chrome prior to 88.0.4324.96 allowed an attacker who convinced a user to download files to bypass navigation restrictions via a crafted HTML page.",
"id": "GHSA-g8q5-x5p6-c4gc",
"modified": "2022-07-13T00:01:06Z",
"published": "2022-05-24T17:41:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21133"
},
{
"type": "WEB",
"url": "https://chromereleases.googleblog.com/2021/01/stable-channel-update-for-desktop_19.html"
},
{
"type": "WEB",
"url": "https://crbug.com/1157743"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-21133"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G92R-9RXW-CMGX
Vulnerability from github – Published: 2023-01-16 00:30 – Updated: 2023-01-23 18:50Improper Authentication in GitHub repository thorsten/phpmyfaq prior to 3.1.10.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "thorsten/phpmyfaq"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.10"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-0311"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-20T22:01:50Z",
"nvd_published_at": "2023-01-15T22:15:00Z",
"severity": "CRITICAL"
},
"details": "Improper Authentication in GitHub repository thorsten/phpmyfaq prior to 3.1.10.",
"id": "GHSA-g92r-9rxw-cmgx",
"modified": "2023-01-23T18:50:12Z",
"published": "2023-01-16T00:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-0311"
},
{
"type": "WEB",
"url": "https://github.com/thorsten/phpmyfaq/commit/fe6e9f02ef1b26a03134b9becda12687ee5f3214"
},
{
"type": "PACKAGE",
"url": "https://github.com/thorsten/phpmyfaq"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/82b0b629-c56b-4651-af3f-17f749751857"
}
],
"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"
}
],
"summary": "phpMyFAQ Improper Authentication vulnerability"
}
GHSA-G936-7JQJ-MWV8
Vulnerability from github – Published: 2026-07-10 21:43 – Updated: 2026-07-10 21:43Description
A vulnerability was discovered in TSDProxy where it forwards its internal per-process authentication token to all proxied backend services. When identityHeaders is enabled (the default), tsdproxy injects x-tsdproxy-auth-token into every upstream HTTP request alongside user identity headers. This token is the same secret used by the management HTTP server to trust forwarded Tailscale identity claims. A backend that receives this token can replay it from localhost to the management port with an arbitrary x-tsdproxy-id value, bypassing Tailscale authentication entirely.
The token is forwarded unconditionally: ProviderUserMiddleware always calls WhoisNewContext regardless of whether the user is authenticated. In the ReverseProxy.Rewrite function, WhoisFromContext returns ok=true even for zero-value Whois{} (unauthenticated or Funnel requests). The HeaderAuthToken is set for every request when identityHeaders=true.
The attack requires the backend to reach 127.0.0.1:8080. This holds in: (1) non-Docker deployments where tsdproxy and a backend run on the same host, (2) Docker host-network-mode containers, (3) containers sharing tsdproxy's network namespace.
Affected files
internal/proxymanager/port.go:123-132internal/core/admin.go:160-182
// port.go: auth token forwarded regardless of user authentication state
if identityHeaders {
if user, ok := model.WhoisFromContext(r.In.Context()); ok {
// ok=true even for empty Whois{} stored by ProviderUserMiddleware
r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) // token sent to backend
}
}
// admin.go: management port trusts x-tsdproxy-id from localhost when token is valid
func ResolveWhois(r *http.Request) model.Whois {
if IsLocalhost(r.RemoteAddr) {
return model.Whois{
ID: r.Header.Get(consts.HeaderID), // attacker-controlled after stealing token
}
}
return model.Whois{}
}
Steps to reproduce
- Deploy tsdproxy on a host (non-Docker) with a backend at
http://localhost:3000. - Make a request through the Tailscale proxy. The backend receives
x-tsdproxy-auth-tokenin the request headers. - From the host, replay the token to the management API:
# Capture token from backend headers (e.g., via a header-reflection endpoint)
TOKEN=$(curl -s http://localhost:3000/debug/headers | python3 -c "import sys,json; d=json.load(sys.stdin); print(d['headers'].get('X-Tsdproxy-Auth-Token',''))")
# Replay from localhost to gain admin access
curl -H "x-tsdproxy-auth-token: $TOKEN" \
-H "x-tsdproxy-id: attacker" \
http://127.0.0.1:8080/api/v1/proxies
# Returns full proxy list with admin access
Fix
Remove HeaderAuthToken from the outgoing backend request, and guard identity-header injection on user.ID != "":
// port.go: only inject headers for actually authenticated users
if identityHeaders {
if user, ok := model.WhoisFromContext(r.In.Context()); ok && user.ID != "" {
r.Out.Header.Set(consts.HeaderID, user.ID)
// HeaderAuthToken should NOT be forwarded to backends
}
}
Impact
An attacker with code execution in any backend proxied by tsdproxy (on the same host) gains full management API control: restart or pause all proxied services (DoS), enumerate all proxy configurations and backend network topology, and trigger webhook deliveries (SSRF via configured webhook URLs).
Credits
Reported by Vishal Shukla (@shukla304 / @therawdev).
Sponsorship
This audit is from an AI-assisted research agent at sechub.dev. Running it on OSS projects is free for maintainers.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/almeidapaulopt/tsdproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.4-0.20260603142855-434819b4421e"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-10T21:43:13Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Description\n\nA vulnerability was discovered in TSDProxy where it forwards its internal per-process authentication token to all proxied backend services. When `identityHeaders` is enabled (the default), tsdproxy injects `x-tsdproxy-auth-token` into every upstream HTTP request alongside user identity headers. This token is the same secret used by the management HTTP server to trust forwarded Tailscale identity claims. A backend that receives this token can replay it from localhost to the management port with an arbitrary `x-tsdproxy-id` value, bypassing Tailscale authentication entirely.\n\nThe token is forwarded unconditionally: `ProviderUserMiddleware` always calls `WhoisNewContext` regardless of whether the user is authenticated. In the `ReverseProxy.Rewrite` function, `WhoisFromContext` returns `ok=true` even for zero-value `Whois{}` (unauthenticated or Funnel requests). The `HeaderAuthToken` is set for every request when `identityHeaders=true`.\n\nThe attack requires the backend to reach `127.0.0.1:8080`. This holds in: (1) non-Docker deployments where tsdproxy and a backend run on the same host, (2) Docker host-network-mode containers, (3) containers sharing tsdproxy\u0027s network namespace.\n\n## Affected files\n\n- `internal/proxymanager/port.go:123-132`\n- `internal/core/admin.go:160-182`\n\n```go\n// port.go: auth token forwarded regardless of user authentication state\nif identityHeaders {\n if user, ok := model.WhoisFromContext(r.In.Context()); ok {\n // ok=true even for empty Whois{} stored by ProviderUserMiddleware\n r.Out.Header.Set(consts.HeaderAuthToken, core.ProxyAuthToken()) // token sent to backend\n }\n}\n\n// admin.go: management port trusts x-tsdproxy-id from localhost when token is valid\nfunc ResolveWhois(r *http.Request) model.Whois {\n if IsLocalhost(r.RemoteAddr) {\n return model.Whois{\n ID: r.Header.Get(consts.HeaderID), // attacker-controlled after stealing token\n }\n }\n return model.Whois{}\n}\n```\n\n## Steps to reproduce\n\n1. Deploy tsdproxy on a host (non-Docker) with a backend at `http://localhost:3000`.\n2. Make a request through the Tailscale proxy. The backend receives `x-tsdproxy-auth-token` in the request headers.\n3. From the host, replay the token to the management API:\n\n```bash\n# Capture token from backend headers (e.g., via a header-reflection endpoint)\nTOKEN=$(curl -s http://localhost:3000/debug/headers | python3 -c \"import sys,json; d=json.load(sys.stdin); print(d[\u0027headers\u0027].get(\u0027X-Tsdproxy-Auth-Token\u0027,\u0027\u0027))\")\n\n# Replay from localhost to gain admin access\ncurl -H \"x-tsdproxy-auth-token: $TOKEN\" \\\n -H \"x-tsdproxy-id: attacker\" \\\n http://127.0.0.1:8080/api/v1/proxies\n# Returns full proxy list with admin access\n```\n\n## Fix\n\nRemove `HeaderAuthToken` from the outgoing backend request, and guard identity-header injection on `user.ID != \"\"`:\n\n```go\n// port.go: only inject headers for actually authenticated users\nif identityHeaders {\n if user, ok := model.WhoisFromContext(r.In.Context()); ok \u0026\u0026 user.ID != \"\" {\n r.Out.Header.Set(consts.HeaderID, user.ID)\n // HeaderAuthToken should NOT be forwarded to backends\n }\n}\n```\n\n## Impact\n\nAn attacker with code execution in any backend proxied by tsdproxy (on the same host) gains full management API control: restart or pause all proxied services (DoS), enumerate all proxy configurations and backend network topology, and trigger webhook deliveries (SSRF via configured webhook URLs).\n\n## Credits\n\nReported by Vishal Shukla (@shukla304 / @therawdev).\n\n## Sponsorship\n\nThis audit is from an AI-assisted research agent at [sechub.dev](https://sechub.dev). Running it on OSS projects is free for maintainers.",
"id": "GHSA-g936-7jqj-mwv8",
"modified": "2026-07-10T21:43:13Z",
"published": "2026-07-10T21:43:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/almeidapaulopt/tsdproxy/security/advisories/GHSA-g936-7jqj-mwv8"
},
{
"type": "PACKAGE",
"url": "https://github.com/almeidapaulopt/tsdproxy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation"
}
GHSA-G962-2J28-3CG9
Vulnerability from github – Published: 2026-03-05 20:52 – Updated: 2026-03-06 22:52Summary
When JWT authentication is configured using either:
authJwtPubKeyPath(local RSA public key), orauthJwtHmacSecret(HMAC secret),
the configured audience value (authJwtAud) is not enforced during token parsing.
As a result, validly signed JWT tokens with an incorrect aud claim are accepted for authentication.
This allows authentication using tokens intended for a different audience/service.
Details
Affected Code
File: jwt.go
Lines: 51–59, 144–157, 161–168
Current Behavior
Remote JWKS Mode (Correct):
return jwt.Parse(jwtToken, jwksVerifier.Keyfunc, jwt.WithAudience(cfg.AuthJwtAud))
Audience validation is enforced.
Local Public Key Mode (Vulnerable):
return jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })
No jwt.WithAudience() option is provided.
HMAC Mode (Vulnerable):
return jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })
No jwt.WithAudience() option is provided.
Why This Is Vulnerable: authJwtAud is ignored for authJwtPubKeyPath and authJwtHmacSecret modes, so wrong-audience tokens are accepted.
PoC
- Configure OliveTin
Use a minimal config with JWT local key authentication: ```yaml authJwtPubKeyPath: ./public.pem authJwtHeader: Authorization authJwtClaimUsername: sub authJwtAud: expected-audience
authRequireGuestsToLogin: true ```
- Generate a Wrong-Audience Token ```python python3 - <<EOF import jwt, datetime
with open("private.pem") as f: key = f.read()
token = jwt.encode( { "sub": "low", "aud": "wrong-audience", # intentionally wrong "exp": datetime.datetime.utcnow() + datetime.timedelta(minutes=30) }, key, algorithm="RS256" )
print(token)
EOF
``
This prints the$WRONG_AUD_TOKEN`.
-
Test Without Token (Baseline)
bash curl -i -X POST http://localhost:1337/api/WhoAmI \ -H 'Content-Type: application/json' \ -d '{}'Expected response:HTTP/1.1 401 Unauthorized -
Test With Wrong-Audience Token
bash curl -i -X POST http://localhost:1337/api/WhoAmI \ -H 'Content-Type: application/json' \ -H "Authorization: Bearer $WRONG_AUD_TOKEN" \ -d '{}'Expected response:HTTP/1.1 200 OK {"authenticatedUser":"low","provider":"jwt","usergroup":"","acls":[],"sid":""}Authentication succeeds even though theaudclaim is incorrect.
Impact
An attacker who possesses a valid JWT signed by the configured key (or HMAC secret) but intended for a different audience can authenticate successfully.
This enables:
- Cross-service token reuse
- Authentication using tokens issued for other systems
- Trust boundary violation in multi-service environments
This is particularly severe when:
- OliveTin is deployed behind a centralized SSO provider
- The same signing key is reused across services
- Audience restrictions are relied upon for service isolation
This does not bypass ACL authorization. It is strictly an authentication validation flaw.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/OliveTin/OliveTin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260304231339-e97d8ecbd8d6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30223"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T20:52:12Z",
"nvd_published_at": "2026-03-06T21:16:16Z",
"severity": "HIGH"
},
"details": "### Summary\n\nWhen JWT authentication is configured using either:\n\n- `authJwtPubKeyPath` (local RSA public key), or\n- `authJwtHmacSecret` (HMAC secret),\n\nthe configured audience value (`authJwtAud`) is not enforced during token parsing.\nAs a result, validly signed JWT tokens with an incorrect `aud` claim are accepted for authentication.\nThis allows authentication using tokens intended for a different audience/service.\n\n### Details\n\n**Affected Code**\n\nFile: `jwt.go`\nLines: 51\u201359, 144\u2013157, 161\u2013168\n\n**Current Behavior**\n\nRemote JWKS Mode (Correct):\n```go\nreturn jwt.Parse(jwtToken, jwksVerifier.Keyfunc, jwt.WithAudience(cfg.AuthJwtAud))\n```\nAudience validation is enforced.\n\nLocal Public Key Mode (Vulnerable):\n```go\nreturn jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })\n```\nNo `jwt.WithAudience()` option is provided.\n\nHMAC Mode (Vulnerable):\n```go\nreturn jwt.Parse(jwtString, func(token *jwt.Token) (interface{}, error) { ... })\n```\nNo `jwt.WithAudience()` option is provided.\n\n**Why This Is Vulnerable:** `authJwtAud` is ignored for `authJwtPubKeyPath` and `authJwtHmacSecret` modes, so wrong-audience tokens are accepted.\n\n### PoC\n\n1. **Configure OliveTin**\n\n Use a minimal config with JWT local key authentication:\n ```yaml\n authJwtPubKeyPath: ./public.pem\n authJwtHeader: Authorization\n authJwtClaimUsername: sub\n authJwtAud: expected-audience\n\n authRequireGuestsToLogin: true\n ```\n\n2. **Generate a Wrong-Audience Token**\n ```python\n python3 - \u003c\u003cEOF\n import jwt, datetime\n\n with open(\"private.pem\") as f:\n key = f.read()\n\n token = jwt.encode(\n {\n \"sub\": \"low\",\n \"aud\": \"wrong-audience\", # intentionally wrong\n \"exp\": datetime.datetime.utcnow() + datetime.timedelta(minutes=30)\n },\n key,\n algorithm=\"RS256\"\n )\n\n print(token)\n EOF\n ```\n This prints the `$WRONG_AUD_TOKEN`.\n\n3. **Test Without Token (Baseline)**\n ```bash\n curl -i -X POST http://localhost:1337/api/WhoAmI \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{}\u0027\n ```\n Expected response:\n ```\n HTTP/1.1 401 Unauthorized\n ```\n\n4. **Test With Wrong-Audience Token**\n ```bash\n curl -i -X POST http://localhost:1337/api/WhoAmI \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \"Authorization: Bearer $WRONG_AUD_TOKEN\" \\\n -d \u0027{}\u0027\n ```\n Expected response:\n ```\n HTTP/1.1 200 OK\n {\"authenticatedUser\":\"low\",\"provider\":\"jwt\",\"usergroup\":\"\",\"acls\":[],\"sid\":\"\"}\n ```\n Authentication succeeds even though the `aud` claim is incorrect.\n\n### Impact\n\nAn attacker who possesses a valid JWT signed by the configured key (or HMAC secret) but intended for a different audience can authenticate successfully.\n\nThis enables:\n\n- Cross-service token reuse\n- Authentication using tokens issued for other systems\n- Trust boundary violation in multi-service environments\n\nThis is particularly severe when:\n\n- OliveTin is deployed behind a centralized SSO provider\n- The same signing key is reused across services\n- Audience restrictions are relied upon for service isolation\n\nThis does **not** bypass ACL authorization.\nIt is strictly an authentication validation flaw.",
"id": "GHSA-g962-2j28-3cg9",
"modified": "2026-03-06T22:52:10Z",
"published": "2026-03-05T20:52:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/security/advisories/GHSA-g962-2j28-3cg9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30223"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/commit/e97d8ecbd8d6ba468c418ca496fcd18f78131233"
},
{
"type": "PACKAGE",
"url": "https://github.com/OliveTin/OliveTin"
},
{
"type": "WEB",
"url": "https://github.com/OliveTin/OliveTin/releases/tag/3000.11.1"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "OliveTin has JWT Audience Validation Bypass in Local Key and HMAC Modes"
}
GHSA-G98G-R7GF-2R25
Vulnerability from github – Published: 2025-05-16 17:48 – Updated: 2025-05-22 20:03Overview Session cookies of applications using the Auth0-PHP SDK configured with CookieStore have authentication tags that can be brute forced, which may result in unauthorized access.
Am I Affected? You are affected by this vulnerability if you meet the following pre-conditions: 1. Applications using the Auth0-PHP SDK, or the following SDKs that rely on the Auth0-PHP SDK: a. Auth0/symfony, b. Auth0/laravel-auth0, c. Auth0/wordpress, 2. Session storage configured with CookieStore.
Fix Upgrade Auth0/Auth0-PHP to v8.14.0. As an additional precautionary measure, we recommend rotating your cookie encryption keys. Note that once updated, any previous session cookies will be rejected.
Acknowledgement Okta would like to thank Félix Charette for discovering this vulnerability.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "auth0/auth0-php"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0-BETA1"
},
{
"fixed": "8.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-47275"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-16T17:48:55Z",
"nvd_published_at": "2025-05-15T22:15:18Z",
"severity": "CRITICAL"
},
"details": "**Overview**\nSession cookies of applications using the Auth0-PHP SDK configured with CookieStore have authentication tags that can be brute forced, which may result in unauthorized access.\n\n**Am I Affected?**\nYou are affected by this vulnerability if you meet the following pre-conditions:\n1. Applications using the Auth0-PHP SDK, or the following SDKs that rely on the Auth0-PHP SDK:\n a. Auth0/symfony,\n b. Auth0/laravel-auth0,\n c. Auth0/wordpress,\n2. Session storage configured with CookieStore.\n\n**Fix**\nUpgrade Auth0/Auth0-PHP to v8.14.0. As an additional precautionary measure, we recommend rotating your cookie encryption keys. Note that once updated, any previous session cookies will be rejected.\n\n**Acknowledgement**\nOkta would like to thank F\u00e9lix Charette for discovering this vulnerability.",
"id": "GHSA-g98g-r7gf-2r25",
"modified": "2025-05-22T20:03:15Z",
"published": "2025-05-16T17:48:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/auth0/auth0-PHP/security/advisories/GHSA-g98g-r7gf-2r25"
},
{
"type": "WEB",
"url": "https://github.com/auth0/laravel-auth0/security/advisories/GHSA-9fwj-9mjf-rhj3"
},
{
"type": "WEB",
"url": "https://github.com/auth0/symfony/security/advisories/GHSA-9wg9-93h9-j8ch"
},
{
"type": "WEB",
"url": "https://github.com/auth0/wordpress/security/advisories/GHSA-2f4r-34m4-3w8q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47275"
},
{
"type": "WEB",
"url": "https://github.com/auth0/auth0-PHP/commit/52a79480fdb246f59dbc089b81a784ae049bd389"
},
{
"type": "PACKAGE",
"url": "https://github.com/auth0/auth0-PHP"
},
{
"type": "WEB",
"url": "https://github.com/auth0/auth0-PHP/releases/tag/8.14.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"
}
],
"summary": "Brute Force Authentication Tags of CookieStore Sessions in Auth0-PHP SDK"
}
Mitigation
Strategy: Libraries or Frameworks
Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
CAPEC-114: Authentication Abuse
An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.
CAPEC-115: Authentication Bypass
An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.
CAPEC-151: Identity Spoofing
Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.
CAPEC-194: Fake the Source of Data
An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.
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-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-593: Session Hijacking
This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.
CAPEC-633: Token Impersonation
An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.
CAPEC-650: Upload a Web Shell to a Web Server
By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.
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.