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.
5978 vulnerabilities reference this CWE, most recent first.
GHSA-PW52-MHPV-C8HC
Vulnerability from github – Published: 2024-06-25 21:31 – Updated: 2024-08-21 15:30In WhatsUp Gold versions released before 2023.1.3, there is a missing authentication vulnerability in WUGDataAccess.Credentials. This vulnerability allows unauthenticated attackers to disclose Windows Credentials stored in the product Credential Library.
{
"affected": [],
"aliases": [
"CVE-2024-5012"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-25T21:16:00Z",
"severity": "HIGH"
},
"details": "In WhatsUp Gold versions released before 2023.1.3, there is a\u00a0missing authentication vulnerability in WUGDataAccess.Credentials. This\u00a0vulnerability allows\u00a0unauthenticated attackers to disclose Windows Credentials stored in the product Credential Library.",
"id": "GHSA-pw52-mhpv-c8hc",
"modified": "2024-08-21T15:30:49Z",
"published": "2024-06-25T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5012"
},
{
"type": "WEB",
"url": "https://community.progress.com/s/article/WhatsUp-Gold-Security-Bulletin-June-2024"
},
{
"type": "WEB",
"url": "https://www.progress.com/network-monitoring"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PW5W-RMC5-F87R
Vulnerability from github – Published: 2025-03-10 09:31 – Updated: 2025-10-07 15:30Improper Authentication vulnerability in GE Vernova EnerVista UR Setup allows Authentication Bypass. The software's startup authentication can be disabled by altering a Windows registry setting that any user can modify.
{
"affected": [],
"aliases": [
"CVE-2025-27254"
],
"database_specific": {
"cwe_ids": [
"CWE-282",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-10T09:15:11Z",
"severity": "HIGH"
},
"details": "Improper Authentication vulnerability in GE Vernova EnerVista UR Setup allows Authentication Bypass.\u00a0\nThe software\u0027s startup authentication can be disabled by altering a Windows registry setting that any user can modify.",
"id": "GHSA-pw5w-rmc5-f87r",
"modified": "2025-10-07T15:30:24Z",
"published": "2025-03-10T09:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27254"
},
{
"type": "WEB",
"url": "https://www.gevernova.com/grid-solutions/app/DownloadFile.aspx?prod=urfamily\u0026type=21\u0026file=76"
},
{
"type": "WEB",
"url": "https://www.nozominetworks.com/labs/vulnerability-advisories-cve-2025-27254"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PW83-8WQR-6W84
Vulnerability from github – Published: 2023-07-12 00:30 – Updated: 2024-04-04 06:00An unauthenticated user could log into iSTAR Ultra, iSTAR Ultra LT, iSTAR Ultra G2, and iSTAR Edge G2 with administrator rights.
{
"affected": [],
"aliases": [
"CVE-2023-3127"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-11T22:15:09Z",
"severity": "CRITICAL"
},
"details": "An unauthenticated user could log into iSTAR Ultra, iSTAR Ultra LT, iSTAR Ultra G2, and iSTAR Edge G2 with administrator rights.",
"id": "GHSA-pw83-8wqr-6w84",
"modified": "2024-04-04T06:00:49Z",
"published": "2023-07-12T00:30:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3127"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-192-02"
},
{
"type": "WEB",
"url": "https://www.johnsoncontrols.com/cyber-solutions/security-advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:C/C:L/I:H/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-PW98-XW8G-FX7H
Vulnerability from github – Published: 2022-05-17 00:45 – Updated: 2022-05-17 00:45admin.php in CCleague Pro 1.2 allows remote attackers to bypass authentication by setting the type cookie value to admin.
{
"affected": [],
"aliases": [
"CVE-2008-5125"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2008-11-18T00:30:00Z",
"severity": "MODERATE"
},
"details": "admin.php in CCleague Pro 1.2 allows remote attackers to bypass authentication by setting the type cookie value to admin.",
"id": "GHSA-pw98-xw8g-fx7h",
"modified": "2022-05-17T00:45:27Z",
"published": "2022-05-17T00:45:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2008-5125"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/43281"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/5888"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/30796"
},
{
"type": "WEB",
"url": "http://securityreason.com/securityalert/4604"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/29871"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-PW9M-5JXM-XR6H
Vulnerability from github – Published: 2026-07-07 20:11 – Updated: 2026-07-07 20:11Am I affected?
Users are affected if all of the following are true:
- Their application uses
better-authand has enabled at least one of:oidcProvider()(imported frombetter-auth/plugins/oidc-provider), ormcp()(imported frombetter-auth/plugins/mcp). - Their application has at least one confidential OAuth client registered (any client with
type: "web" | "native" | "user-agent-based"in theoauthApplicationtable, or anytrustedClientsentry withouttype: "public"). Public clients with PKCE are not affected. - Their application uses
better-authat a version below the patched release.
If an application only uses @better-auth/oauth-provider (the canonical replacement for oidc-provider) and the mcp plugin is not enabled, it is not affected.
Fix:
- Upgrade to
better-auth@1.6.11or later. - Migrate from the deprecated
oidcProvider()to@better-auth/oauth-providerwhen feasible. The new package enforces client authentication on both grants by default. - If developers cannot upgrade their applications, see workarounds below.
Summary
The legacy oidcProvider and mcp plugins each expose an OAuth 2.0 token endpoint whose refresh_token grant authenticates the request entirely on possession of the bound refreshToken row and a matching client_id. Neither plugin verifies the registered confidential client's client_secret on the refresh path. An attacker who obtains any valid refresh_token (via database read, log capture, browser-side XSS, or CORS-amplified script in the mcp case) and the public client_id can mint fresh access tokens and rotated refresh tokens until the chain is revoked.
Details
RFC 6749 §6 and OAuth 2.1 §4.3 require confidential clients to authenticate to the token endpoint on every grant, including refresh. The same plugins' authorization_code grant correctly enforces client_secret (the oidc-provider via verifyStoredClientSecret, the mcp plugin via raw equality), which proves the omission on the refresh path is a regression rather than a design choice.
Token rotation issues a new refresh_token with each call, so a single leaked refresh-token grants indefinite access until the row is revoked or its refreshTokenExpiresAt (default 7 days) passes; rotation refreshes that window each call.
Two adjacent issues on the mcp surface ship in the same patch. The mcp authorization_code grant uses raw === for client-secret comparison and ignores the storeClientSecret: "encrypted" | "hashed" configuration; the fix routes both grants through verifyStoredClientSecret. The mcp /mcp/token endpoint sets Access-Control-Allow-Origin: * unconditionally, which amplifies the refresh bypass in browser contexts; the fix narrows the CORS allowlist.
The newer @better-auth/oauth-provider package routes both grants through validateClientCredentials and is not affected.
Patches
Fixed in better-auth@1.6.11. The legacy oidcProvider and mcp token endpoints now require client_secret on the refresh_token grant for confidential clients, using the same constant-time comparison the authorization_code grant already used. Public clients are unaffected (they have no secret to enforce, and PKCE substitutes on the auth-code grant).
The Authorization: Basic parser is fixed to follow RFC 6749 §2.3.1: the credential is split on the first colon and each half is percent-decoded. Client IDs and secrets that contain reserved characters now authenticate correctly. The /mcp/token endpoint's CORS configuration is narrowed in the same change (the wildcard Access-Control-Allow-Origin: * header is removed), matching the standalone @better-auth/oauth-provider package.
The deprecated oidc-provider plugin remains deprecated. The recommended migration path is @better-auth/oauth-provider.
Workarounds
None of these close the bug fully without a code patch.
- Migrate to
@better-auth/oauth-providerif your deployment can adopt the new plugin. It enforcesclient_secreton both grants. - Force all clients to public + PKCE: set every client's
type: "public"and require PKCE. The bug is unreachable when there is noclient_secretto verify. - Network-layer ingress restriction: limit
/api/auth/oauth2/tokenand/api/auth/mcp/tokento known client IPs at the load balancer. Practical for server-to-server flows, not for end-user-device clients. - Out-of-band refresh-token rotation: on any suspicion of leak, run
db.deleteMany({ model: "oauthAccessToken", where: [{ field: "clientId", value: <id> }] })to invalidate all refresh tokens for the affected client. - For the mcp endpoint specifically: drop the wildcard CORS at an upstream proxy and replace with a tight allowlist.
Impact
- Indefinite confidential-client impersonation: an attacker holding any valid
refresh_tokenand the publicclient_idcan mint access tokens and rotated refresh tokens indefinitely, until the row is revoked. Rotation refreshes the expiration window each call. - Resource access at the user's authorized scope: every minted access token carries the original user's authorization scope, so the attacker reads or writes whatever the resource server grants for that scope.
Credit
Reported by @subhanUmer.
Resources
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "better-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53512"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306",
"CWE-345",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T20:11:50Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `better-auth` and has enabled at least one of: `oidcProvider()` (imported from `better-auth/plugins/oidc-provider`), or `mcp()` (imported from `better-auth/plugins/mcp`).\n- Their application has at least one confidential OAuth client registered (any client with `type: \"web\" | \"native\" | \"user-agent-based\"` in the `oauthApplication` table, or any `trustedClients` entry without `type: \"public\"`). Public clients with PKCE are not affected.\n- Their application uses `better-auth` at a version below the patched release.\n\nIf an application only uses `@better-auth/oauth-provider` (the canonical replacement for `oidc-provider`) and the `mcp` plugin is not enabled, it is not affected.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. Migrate from the deprecated `oidcProvider()` to `@better-auth/oauth-provider` when feasible. The new package enforces client authentication on both grants by default.\n3. If developers cannot upgrade their applications, see workarounds below.\n\n### Summary\n\nThe legacy `oidcProvider` and `mcp` plugins each expose an OAuth 2.0 token endpoint whose `refresh_token` grant authenticates the request entirely on possession of the bound `refreshToken` row and a matching `client_id`. Neither plugin verifies the registered confidential client\u0027s `client_secret` on the refresh path. An attacker who obtains any valid `refresh_token` (via database read, log capture, browser-side XSS, or CORS-amplified script in the mcp case) and the public `client_id` can mint fresh access tokens and rotated refresh tokens until the chain is revoked.\n\n### Details\n\nRFC 6749 \u00a76 and OAuth 2.1 \u00a74.3 require confidential clients to authenticate to the token endpoint on every grant, including refresh. The same plugins\u0027 `authorization_code` grant correctly enforces `client_secret` (the oidc-provider via `verifyStoredClientSecret`, the mcp plugin via raw equality), which proves the omission on the refresh path is a regression rather than a design choice.\n\nToken rotation issues a new `refresh_token` with each call, so a single leaked refresh-token grants indefinite access until the row is revoked or its `refreshTokenExpiresAt` (default 7 days) passes; rotation refreshes that window each call.\n\nTwo adjacent issues on the mcp surface ship in the same patch. The mcp `authorization_code` grant uses raw `===` for client-secret comparison and ignores the `storeClientSecret: \"encrypted\" | \"hashed\"` configuration; the fix routes both grants through `verifyStoredClientSecret`. The mcp `/mcp/token` endpoint sets `Access-Control-Allow-Origin: *` unconditionally, which amplifies the refresh bypass in browser contexts; the fix narrows the CORS allowlist.\n\nThe newer `@better-auth/oauth-provider` package routes both grants through `validateClientCredentials` and is not affected.\n\n### Patches\n\nFixed in `better-auth@1.6.11`. The legacy `oidcProvider` and `mcp` token endpoints now require `client_secret` on the `refresh_token` grant for confidential clients, using the same constant-time comparison the `authorization_code` grant already used. Public clients are unaffected (they have no secret to enforce, and PKCE substitutes on the auth-code grant).\n\nThe `Authorization: Basic` parser is fixed to follow RFC 6749 \u00a72.3.1: the credential is split on the first colon and each half is percent-decoded. Client IDs and secrets that contain reserved characters now authenticate correctly. The `/mcp/token` endpoint\u0027s CORS configuration is narrowed in the same change (the wildcard `Access-Control-Allow-Origin: *` header is removed), matching the standalone `@better-auth/oauth-provider` package.\n\nThe deprecated `oidc-provider` plugin remains deprecated. The recommended migration path is `@better-auth/oauth-provider`.\n\n### Workarounds\n\nNone of these close the bug fully without a code patch.\n\n- **Migrate to `@better-auth/oauth-provider`** if your deployment can adopt the new plugin. It enforces `client_secret` on both grants.\n- **Force all clients to public + PKCE**: set every client\u0027s `type: \"public\"` and require PKCE. The bug is unreachable when there is no `client_secret` to verify.\n- **Network-layer ingress restriction**: limit `/api/auth/oauth2/token` and `/api/auth/mcp/token` to known client IPs at the load balancer. Practical for server-to-server flows, not for end-user-device clients.\n- **Out-of-band refresh-token rotation**: on any suspicion of leak, run `db.deleteMany({ model: \"oauthAccessToken\", where: [{ field: \"clientId\", value: \u003cid\u003e }] })` to invalidate all refresh tokens for the affected client.\n- **For the mcp endpoint specifically**: drop the wildcard CORS at an upstream proxy and replace with a tight allowlist.\n\n### Impact\n\n- **Indefinite confidential-client impersonation**: an attacker holding any valid `refresh_token` and the public `client_id` can mint access tokens and rotated refresh tokens indefinitely, until the row is revoked. Rotation refreshes the expiration window each call.\n- **Resource access at the user\u0027s authorized scope**: every minted access token carries the original user\u0027s authorization scope, so the attacker reads or writes whatever the resource server grants for that scope.\n\n### Credit\n\nReported by @subhanUmer.\n\n### Resources\n\n- [CWE-306: Missing Authentication for Critical Function](https://cwe.mitre.org/data/definitions/306.html)\n- [CWE-287: Improper Authentication](https://cwe.mitre.org/data/definitions/287.html)\n- [CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n- [CWE-863: Incorrect Authorization](https://cwe.mitre.org/data/definitions/863.html)\n- [RFC 6749 \u00a76: Refreshing an Access Token](https://datatracker.ietf.org/doc/html/rfc6749#section-6)\n- [OAuth 2.1 \u00a74.3: Refresh Token](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1#section-4.3)",
"id": "GHSA-pw9m-5jxm-xr6h",
"modified": "2026-07-07T20:11:50Z",
"published": "2026-07-07T20:11:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-pw9m-5jxm-xr6h"
},
{
"type": "PACKAGE",
"url": "https://github.com/better-auth/better-auth"
},
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
}
],
"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": "Better Auth: OAuth refresh-token replay via missing client authentication on oidc-provider and mcp plugins"
}
GHSA-PWF4-M8PJ-J567
Vulnerability from github – Published: 2025-03-17 18:31 – Updated: 2025-03-17 18:31A vulnerability was found in Keytop 路内停车收费系统 2.7.1. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /saas/commonApi/park/getParks of the component API. The manipulation leads to improper authentication. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-2388"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-17T18:15:22Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Keytop \u8def\u5185\u505c\u8f66\u6536\u8d39\u7cfb\u7edf 2.7.1. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /saas/commonApi/park/getParks of the component API. The manipulation leads to improper authentication. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-pwf4-m8pj-j567",
"modified": "2025-03-17T18:31:53Z",
"published": "2025-03-17T18:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-2388"
},
{
"type": "WEB",
"url": "https://github.com/K-mxredo/MXdocument/wiki"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.299887"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.299887"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.516710"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-PWGF-2VFP-FH6C
Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2022-08-10 00:004MOSAn GCB Doctor’s login page has improper validation of Cookie, which allows an unauthenticated remote attacker to bypass authentication by code injection in cookie, and arbitrarily manipulate the system or interrupt services by upload and execution of arbitrary files.
{
"affected": [],
"aliases": [
"CVE-2021-42338"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-19T09:15:00Z",
"severity": "CRITICAL"
},
"details": "4MOSAn GCB Doctor\u2019s login page has improper validation of Cookie, which allows an unauthenticated remote attacker to bypass authentication by code injection in cookie, and arbitrarily manipulate the system or interrupt services by upload and execution of arbitrary files.",
"id": "GHSA-pwgf-2vfp-fh6c",
"modified": "2022-08-10T00:00:23Z",
"published": "2022-05-24T22:28:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-42338"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-5313-45bde-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PWH8-58VV-VW48
Vulnerability from github – Published: 2023-09-15 13:36 – Updated: 2024-09-10 17:15If a Jetty OpenIdAuthenticator uses the optional nested LoginService, and that LoginService decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated.
So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the LoginService.
Impact
This impacts usages of the jetty-openid which have configured a nested LoginService and where that LoginService will is capable of rejecting previously authenticated users.
Original Report
working on a custom OpenIdAuthenticator, I discovered the following:
https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505
In the case where the LoginService does return that the authentication has been revoked (from the validate() call on line 463), the OpenIdAuthenticator removes the authentication from the session; however the current request still proceeds as if authenticated, since it falls through to "return authentication" on line 505.
This is fixed by moving the line 505 (and associated debug log) inside the else block that ends on line 502, instead of outside it. Then the revocation case will run through to line 517 and will trigger a new OpenId authentication which I think is correct.
I think this revocation can only occur if you do attach a separate LoginService to the OpenIdLoginService, but in that case the revoked authentication will still let the next request through (and possibly more than one if they are very close to simultaneous).
Technically I think this is a security vulnerability, if a very minor one, so I'm sending this off-list.
Patched Versions
Fixed in Jetty Versions: * 9.4.52 - fixed in PR https://github.com/eclipse/jetty.project/pull/9660 * 10.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 * 11.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528 * 12.0.0 - not impacted (already has fix)
Workaround
Upgrade your version of Jetty.
References
- https://github.com/eclipse/jetty.project/pull/9528
- https://github.com/eclipse/jetty.project/pull/9660
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 9.4.51"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-openid"
},
"ranges": [
{
"events": [
{
"introduced": "9.4.21"
},
{
"fixed": "9.4.52.v20230823"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.0.15"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-openid"
},
"ranges": [
{
"events": [
{
"introduced": "10.0.0"
},
{
"fixed": "10.0.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.15"
},
"package": {
"ecosystem": "Maven",
"name": "org.eclipse.jetty:jetty-openid"
},
"ranges": [
{
"events": [
{
"introduced": "11.0.0"
},
{
"fixed": "11.0.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-41900"
],
"database_specific": {
"cwe_ids": [
"CWE-1390",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-15T13:36:10Z",
"nvd_published_at": "2023-09-15T21:15:11Z",
"severity": "LOW"
},
"details": "If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. \n\nSo a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`.\n\n### Impact\nThis impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users.\n\n### Original Report\n\u003e working on a custom OpenIdAuthenticator, I discovered the following:\n\u003e \n\u003e https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505\n\u003e \n\u003e In the case where the LoginService does return that the authentication has been revoked (from the validate() call on line 463), the OpenIdAuthenticator removes the authentication from the session; however the current request still proceeds as if authenticated, since it falls through to \"return authentication\" on line 505.\n\u003e \n\u003e This is fixed by moving the line 505 (and associated debug log) inside the else block that ends on line 502, instead of outside it. Then the revocation case will run through to line 517 and will trigger a new OpenId authentication which I think is correct.\n\u003e \n\u003e I think this revocation can only occur if you do attach a separate LoginService to the OpenIdLoginService, but in that case the revoked authentication will still let the next request through (and possibly more than one if they are very close to simultaneous).\n\u003e \n\u003e Technically I think this is a security vulnerability, if a very minor one, so I\u0027m sending this off-list.\n\n### Patched Versions\n\nFixed in Jetty Versions:\n* 9.4.52 - fixed in PR https://github.com/eclipse/jetty.project/pull/9660\n* 10.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528\n* 11.0.16 - fixed in PR https://github.com/eclipse/jetty.project/pull/9528\n* 12.0.0 - not impacted (already has fix)\n\n### Workaround\nUpgrade your version of Jetty.\n\n### References\n* https://github.com/eclipse/jetty.project/pull/9528\n* https://github.com/eclipse/jetty.project/pull/9660",
"id": "GHSA-pwh8-58vv-vw48",
"modified": "2024-09-10T17:15:25Z",
"published": "2023-09-15T13:36:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/security/advisories/GHSA-pwh8-58vv-vw48"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41900"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/pull/9528"
},
{
"type": "WEB",
"url": "https://github.com/eclipse/jetty.project/pull/9660"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse/jetty.project"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20231110-0004"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2023/dsa-5507"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jetty\u0027s OpenId Revoked authentication allows one request"
}
GHSA-PWVM-4X89-4V8H
Vulnerability from github – Published: 2022-05-01 17:58 – Updated: 2025-04-03 15:30Session fixation vulnerability in eXV2 CMS 2.0.4.3 and earlier allows remote attackers to hijack web sessions by setting the PHPSESSID cookie.
{
"affected": [],
"aliases": [
"CVE-2007-1966"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2007-04-11T10:19:00Z",
"severity": "MODERATE"
},
"details": "Session fixation vulnerability in eXV2 CMS 2.0.4.3 and earlier allows remote attackers to hijack web sessions by setting the PHPSESSID cookie.",
"id": "GHSA-pwvm-4x89-4v8h",
"modified": "2025-04-03T15:30:40Z",
"published": "2022-05-01T17:58:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2007-1966"
},
{
"type": "WEB",
"url": "http://marc.info/?l=bugtraq\u0026m=117570977117962\u0026w=2"
},
{
"type": "WEB",
"url": "http://www.majorsecurity.de/index_2.php?major_rls=major_rls38"
}
],
"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"
}
]
}
GHSA-PWW2-WM88-CP3P
Vulnerability from github – Published: 2022-05-24 17:15 – Updated: 2024-03-21 03:33In IQrouter through 3.3.1, there is a root user without a password, which allows attackers to gain full remote access via SSH.
{
"affected": [],
"aliases": [
"CVE-2020-11965"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-21T13:15:00Z",
"severity": "HIGH"
},
"details": "In IQrouter through 3.3.1, there is a root user without a password, which allows attackers to gain full remote access via SSH.",
"id": "GHSA-pww2-wm88-cp3p",
"modified": "2024-03-21T03:33:54Z",
"published": "2022-05-24T17:15:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-11965"
},
{
"type": "WEB",
"url": "https://evenroute.com"
},
{
"type": "WEB",
"url": "https://evenroute.zendesk.com/hc/en-us/articles/216107838-How-do-I-configure-an-IQrouter-"
},
{
"type": "WEB",
"url": "https://openwrt.org/docs/guide-quick-start/walkthrough_login"
},
{
"type": "WEB",
"url": "https://pastebin.com/grSCSBSu"
}
],
"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"
}
]
}
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.