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.
5982 vulnerabilities reference this CWE, most recent first.
GHSA-PVX4-5RVM-68W9
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44EMC Isilon InsightIQ 4.1.0, 4.0.1, 4.0.0, 3.2.2, 3.2.1, 3.2.0, 3.1.1, 3.1.0, 3.0.1, 3.0.0 is affected by an authentication bypass vulnerability that could potentially be exploited by attackers to compromise the affected system.
{
"affected": [],
"aliases": [
"CVE-2017-2765"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-08T17:59:00Z",
"severity": "CRITICAL"
},
"details": "EMC Isilon InsightIQ 4.1.0, 4.0.1, 4.0.0, 3.2.2, 3.2.1, 3.2.0, 3.1.1, 3.1.0, 3.0.1, 3.0.0 is affected by an authentication bypass vulnerability that could potentially be exploited by attackers to compromise the affected system.",
"id": "GHSA-pvx4-5rvm-68w9",
"modified": "2022-05-13T01:44:58Z",
"published": "2022-05-13T01:44:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2765"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/540100/30/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95945"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PVXF-9MM4-92XF
Vulnerability from github – Published: 2024-04-25 15:30 – Updated: 2024-04-25 15:30An issue has been discovered in GitLab CE/EE affecting all versions starting from 7.8 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. Under certain conditions, an attacker with their Bitbucket account credentials may be able to take over a GitLab account linked to another user's Bitbucket account, if Bitbucket is used as an OAuth 2.0 provider on GitLab.
{
"affected": [],
"aliases": [
"CVE-2024-4024"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-302"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-25T14:15:09Z",
"severity": "HIGH"
},
"details": "An issue has been discovered in GitLab CE/EE affecting all versions starting from 7.8 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. Under certain conditions, an attacker with their Bitbucket account credentials may be able to take over a GitLab account linked to another user\u0027s Bitbucket account, if Bitbucket is used as an OAuth 2.0 provider on GitLab.",
"id": "GHSA-pvxf-9mm4-92xf",
"modified": "2024-04-25T15:30:37Z",
"published": "2024-04-25T15:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4024"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/452426"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-PVXX-RV48-QW5M
Vulnerability from github – Published: 2023-03-15 00:30 – Updated: 2023-03-21 18:30Netgear RAX30 (AX2400), prior to version 1.0.6.74, was affected by an authentication bypass vulnerability, allowing an unauthenticated attacker to gain administrative access to the device's web management interface by resetting the admin password.
{
"affected": [],
"aliases": [
"CVE-2023-1327"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-03-14T22:15:00Z",
"severity": "CRITICAL"
},
"details": "Netgear RAX30 (AX2400), prior to version 1.0.6.74, was affected by an authentication bypass vulnerability, allowing an unauthenticated attacker to gain administrative access to the device\u0027s web management interface by resetting the admin password.",
"id": "GHSA-pvxx-rv48-qw5m",
"modified": "2023-03-21T18:30:19Z",
"published": "2023-03-15T00:30:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1327"
},
{
"type": "WEB",
"url": "https://drupal9.tenable.com/security/research/tra-2023-10"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-pvxx-rv48-qw5m"
}
],
"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-PW24-GRCH-F45V
Vulnerability from github – Published: 2022-05-14 01:50 – Updated: 2025-04-20 03:46SAP Hostcontrol does not require authentication for the SOAP SAPControl endpoint. This is SAP Security Note 2442993.
{
"affected": [],
"aliases": [
"CVE-2017-15297"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-16T16:29:00Z",
"severity": "HIGH"
},
"details": "SAP Hostcontrol does not require authentication for the SOAP SAPControl endpoint. This is SAP Security Note 2442993.",
"id": "GHSA-pw24-grch-f45v",
"modified": "2025-04-20T03:46:51Z",
"published": "2022-05-14T01:50:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-15297"
},
{
"type": "WEB",
"url": "https://blogs.sap.com/2017/07/11/sap-security-patch-day-july-2017"
},
{
"type": "WEB",
"url": "https://erpscan.io/advisories/erpscan-17-034-sap-hostcontrol-unprotected-web-method-dos"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99528"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
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"
}
]
}
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.