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.
5977 vulnerabilities reference this CWE, most recent first.
GHSA-G328-HF66-X5P7
Vulnerability from github – Published: 2023-07-17 18:31 – Updated: 2024-04-04 06:10Mattermost fails to invalidate previously generated password reset tokens when a new reset token was created.
{
"affected": [],
"aliases": [
"CVE-2023-3591"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-17T16:15:10Z",
"severity": "HIGH"
},
"details": "Mattermost fails to invalidate previously generated password reset tokens when a new reset token was created.\n\n",
"id": "GHSA-g328-hf66-x5p7",
"modified": "2024-04-04T06:10:57Z",
"published": "2023-07-17T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3591"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G336-GVX8-VRRH
Vulnerability from github – Published: 2025-09-02 15:31 – Updated: 2025-09-02 15:31A weakness has been identified in alaneuler batteryKid up to 2.1 on macOS. The affected element is an unknown function of the file PrivilegeHelper/PrivilegeHelper.swift of the component NSXPCListener. This manipulation causes missing authentication. It is possible to launch the attack on the local host. The exploit has been made available to the public and could be exploited.
{
"affected": [],
"aliases": [
"CVE-2025-9815"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-02T05:15:39Z",
"severity": "HIGH"
},
"details": "A weakness has been identified in alaneuler batteryKid up to 2.1 on macOS. The affected element is an unknown function of the file PrivilegeHelper/PrivilegeHelper.swift of the component NSXPCListener. This manipulation causes missing authentication. It is possible to launch the attack on the local host. The exploit has been made available to the public and could be exploited.",
"id": "GHSA-g336-gvx8-vrrh",
"modified": "2025-09-02T15:31:08Z",
"published": "2025-09-02T15:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9815"
},
{
"type": "WEB",
"url": "https://github.com/SwayZGl1tZyyy/n-days/blob/main/batteryKid/README.md"
},
{
"type": "WEB",
"url": "https://github.com/SwayZGl1tZyyy/n-days/blob/main/batteryKid/README.md#proof-of-concepts"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.322142"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.322142"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.641358"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P/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-G33G-QHJR-V6FQ
Vulnerability from github – Published: 2022-07-22 00:00 – Updated: 2022-07-28 00:00Broken Access Control vulnerability in YIKES Inc. Custom Product Tabs for WooCommerce plugin <= 1.7.7 at WordPress leading to &yikes-the-content-toggle option update.
{
"affected": [],
"aliases": [
"CVE-2022-28666"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-21T17:15:00Z",
"severity": "MODERATE"
},
"details": "Broken Access Control vulnerability in YIKES Inc. Custom Product Tabs for WooCommerce plugin \u003c= 1.7.7 at WordPress leading to \u0026yikes-the-content-toggle option update.",
"id": "GHSA-g33g-qhjr-v6fq",
"modified": "2022-07-28T00:00:39Z",
"published": "2022-07-22T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28666"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/yikes-inc-easy-custom-woocommerce-product-tabs/wordpress-custom-product-tabs-for-woocommerce-plugin-1-7-7-broken-access-control-vulnerability-leading-to-yikes-the-content-toggle-option-update"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/yikes-inc-easy-custom-woocommerce-product-tabs/wordpress-custom-product-tabs-for-woocommerce-plugin-1-7-7-broken-access-control-vulnerability-leading-to-yikes-the-content-toggle-option-update?_s_id=cve"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/yikes-inc-easy-custom-woocommerce-product-tabs"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-G33R-3VQ8-Q6F4
Vulnerability from github – Published: 2026-06-02 09:36 – Updated: 2026-06-02 12:31The Really Simple Security WordPress plugin before 9.5.10.1 does not enforce the second-factor challenge in two of its two-factor authentication REST endpoints, allowing an attacker who knows a user's password to obtain a WordPress authentication session for that user without completing the email OTP challenge.
{
"affected": [],
"aliases": [
"CVE-2026-8293"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-02T07:16:13Z",
"severity": "HIGH"
},
"details": "The Really Simple Security WordPress plugin before 9.5.10.1 does not enforce the second-factor challenge in two of its two-factor authentication REST endpoints, allowing an attacker who knows a user\u0027s password to obtain a WordPress authentication session for that user without completing the email OTP challenge.",
"id": "GHSA-g33r-3vq8-q6f4",
"modified": "2026-06-02T12:31:25Z",
"published": "2026-06-02T09:36:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8293"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/1de69ef9-6226-4292-8e36-b331a37f043e"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-G365-5X48-7J84
Vulnerability from github – Published: 2022-05-25 00:00 – Updated: 2022-06-07 00:00In LuxSoft LuxCal Web Calendar before 5.2.0, an unauthenticated attacker can manipulate a POST request. This allows the attacker's session to be authenticated as any registered LuxCal user, including the site administrator.
{
"affected": [],
"aliases": [
"CVE-2021-45914"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-24T15:15:00Z",
"severity": "CRITICAL"
},
"details": "In LuxSoft LuxCal Web Calendar before 5.2.0, an unauthenticated attacker can manipulate a POST request. This allows the attacker\u0027s session to be authenticated as any registered LuxCal user, including the site administrator.",
"id": "GHSA-g365-5x48-7j84",
"modified": "2022-06-07T00:00:37Z",
"published": "2022-05-25T00:00:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45914"
},
{
"type": "WEB",
"url": "https://github.com/h1pmnh"
},
{
"type": "WEB",
"url": "https://h1pmnh.github.io/post/cve-luxcal-2021"
},
{
"type": "WEB",
"url": "https://twitter.com/h1pmnh"
},
{
"type": "WEB",
"url": "https://www.luxsoft.eu/index.php?pge=dload"
}
],
"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-G37Q-45H8-P5WM
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30IBM Maximo Asset Management 7.6.0 and 7.6.1 could allow an attacker to bypass authentication and issue commands using a specially crafted HTTP command. IBM X-Force ID: 181995.
{
"affected": [],
"aliases": [
"CVE-2020-4493"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-05T14:15:00Z",
"severity": "CRITICAL"
},
"details": "IBM Maximo Asset Management 7.6.0 and 7.6.1 could allow an attacker to bypass authentication and issue commands using a specially crafted HTTP command. IBM X-Force ID: 181995.",
"id": "GHSA-g37q-45h8-p5wm",
"modified": "2022-05-24T17:30:06Z",
"published": "2022-05-24T17:30:06Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4493"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/181995"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6340281"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-G37V-5M8F-34C3
Vulnerability from github – Published: 2025-09-12 15:31 – Updated: 2025-09-12 15:31The Evertz SDVN 3080ipx-10G is a High Bandwidth Ethernet Switching Fabric for Video Application. This device exposes a web management interface on port 80. This web management interface can be used by administrators to control product features, setup network switching, and register license among other features. The application has been developed in PHP with the webEASY SDK, also named ‘ewb’ by Evertz.
This web interface has two endpoints that are vulnerable to arbitrary command injection (CVE-2025-4009, CVE-2025-10364) and the authentication mechanism has a flaw leading to authentication bypass (CVE-2025-10365).
Remote unauthenticated attackers can gain arbitrary command execution with elevated privileges ( root ) on affected devices.
This level of access could lead to serious business impact such as the interruption of media streaming, modification of media being streamed, alteration of closed captions being generated, among others.
{
"affected": [],
"aliases": [
"CVE-2025-10365"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-12T14:15:40Z",
"severity": "CRITICAL"
},
"details": "The Evertz SDVN 3080ipx-10G is a High Bandwidth Ethernet Switching Fabric for Video Application. This device exposes a\u00a0web management interface on port 80. This web management interface can be used by administrators to control product\nfeatures, setup network switching, and register license among other features. The application has been developed in PHP with\u00a0the webEASY SDK, also named \u2018ewb\u2019 by Evertz.\n\nThis web interface has two endpoints that are vulnerable to arbitrary command injection (CVE-2025-4009,\u00a0CVE-2025-10364) and the authentication mechanism has a flaw leading to authentication bypass (CVE-2025-10365).\n\nRemote unauthenticated attackers can gain arbitrary command execution with elevated privileges ( root ) on affected devices.\n\nThis level of access could lead to serious business impact such as the interruption of media streaming, modification of media being streamed, alteration of closed captions being generated, among others.",
"id": "GHSA-g37v-5m8f-34c3",
"modified": "2025-09-12T15:31:17Z",
"published": "2025-09-12T15:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10365"
},
{
"type": "WEB",
"url": "https://www.onekey.com/resource/security-advisory-remote-code-execution-on-evertz-svdn-cve-2025-4009"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/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:N/AU:Y/R:X/V:C/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-G37X-8FQ5-RMRC
Vulnerability from github – Published: 2022-05-07 00:00 – Updated: 2022-05-18 00:00A crafted request bypasses S2S TCP Token authentication writing arbitrary events to an index in Splunk Enterprise Indexer 8.1 versions before 8.1.5 and 8.2 versions before 8.2.1. The vulnerability impacts Indexers configured to use TCPTokens. It does not impact Universal Forwarders.
{
"affected": [],
"aliases": [
"CVE-2021-31559"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-05-06T17:15:00Z",
"severity": "HIGH"
},
"details": "A crafted request bypasses S2S TCP Token authentication writing arbitrary events to an index in Splunk Enterprise Indexer 8.1 versions before 8.1.5 and 8.2 versions before 8.2.1. The vulnerability impacts Indexers configured to use TCPTokens. It does not impact Universal Forwarders.",
"id": "GHSA-g37x-8fq5-rmrc",
"modified": "2022-05-18T00:00:38Z",
"published": "2022-05-07T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31559"
},
{
"type": "WEB",
"url": "https://www.splunk.com/en_us/product-security/announcements/svd-2022-0503.html"
}
],
"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"
}
]
}
GHSA-G38M-R43W-P2Q7
Vulnerability from github – Published: 2026-07-07 20:55 – Updated: 2026-07-07 20:55Am I affected?
Users are affected if all of the following are true:
- Their application uses
better-authat a version< 1.6.11on the stable line, or any currentnextpre-release. emailAndPassword.enabled: trueis set in their application'sbetterAuth({ ... })configuration.- At least one OAuth or SSO provider is configured (any built-in social provider, or
genericOAuth(...), or any provider via@better-auth/sso). account.accountLinking.disableImplicitLinkingis not set totrue.account.accountLinking.enabledis not set tofalse.
Setting either disableImplicitLinking: true or enabled: false closes the hole at the cost of breaking the standard "add another login method" UX. emailAndPassword.requireEmailVerification: true does not mitigate, because the link-time emailVerified flip promotes the attacker's row to verified, after which the password login becomes usable.
Fix:
- Upgrade to
better-auth@1.6.11or later. - If developers cannot upgrade, see workarounds below.
Summary
The OAuth callback's auto-link gate in handleOAuthUserInfo admits an implicit account link whenever the provider asserts email_verified: true, without requiring the local user row's emailVerified to also be true. An attacker who pre-registers a victim's email through /sign-up/email (which writes a row with emailVerified: false) can have the victim's later OAuth identity bound to the attacker's user row, granting both a password login and the victim's OAuth identity on the same account. This is the pre-account-hijacking class — the same shape as Microsoft "nOAuth" (2023) and the Sign in with Apple JWT flaw (2020).
Details
The auto-link gate validates only the OAuth provider's userInfo.emailVerified claim. The local row's emailVerified field is never read. When no (accountId, providerId) match exists, the user lookup falls back to email, which surfaces any pre-registered row at that email.
A separate post-link step promotes the local emailVerified to true when the provider's claim is true and the local email matches the provider's email. This step is correct for legitimate first-time linking, but combined with the missing local-side check it becomes load-bearing for the takeover: after the link, the attacker's password row is treated as verified, defeating requireEmailVerification: true as a mitigation.
The fix adds the local-side ownership check to the gate: implicit linking now also rejects when dbUser.user.emailVerified is false. The same primitive lives in one-tap and inherits the same fix shape; the SSO domainVerified short-circuit follows separately as a hardening change.
Patches
Fixed in better-auth@1.6.11. Implicit linking now refuses to attach an OAuth identity to a local account whose emailVerified flag is false. The same gate change applies in the one-tap sign-in plugin, which previously had its own simpler linking path. The Google ID-token email_verified claim is also normalized through toBoolean so a string "false" is treated as falsy (some Google responses send the string, which the prior code treated as truthy).
The public surface for the new gate is account.accountLinking.requireLocalEmailVerified, defaulted to true. Applications whose users sign up through OAuth without ever verifying their email locally can opt out with account: { accountLinking: { requireLocalEmailVerified: false } } to retain the legacy permissive behavior. The option is marked @deprecated; the gate at each call site carries a FIXME pointing at the next-minor follow-up that drops the option and makes the check unconditional.
Test fixtures across the admin, oidc-provider, mcp, generic-oauth, last-login-method, and oauth-provider suites now pre-verify created users via a databaseHooks.user.create.before hook (or the disableTestUser opt-in on the oauth-provider RP fixture) so those suites continue to exercise their role and flow logic rather than tripping the new gate.
Workarounds
If developers cannot upgrade their applications immediately:
- Disable implicit linking: set
account.accountLinking.disableImplicitLinking: true. Forces all linking through the authenticated/link-socialendpoint where the user must already be signed in. - Disable linking entirely: set
account.accountLinking.enabled: false. Closes the hole but breaks the multi-login-method UX entirely.
emailAndPassword.requireEmailVerification: true alone does not mitigate, because the link-time emailVerified flip promotes the attacker's row to verified.
Impact
- Account takeover via pre-account hijacking: the attacker holds a working password login plus the victim's OAuth identity on the same account, granting persistent access.
requireEmailVerification: truebypass: the attacker's password login becomes usable post-link.- Cross-flow reach: every OAuth and SSO sign-in path that calls
handleOAuthUserInfois affected (built-in social providers, generic-oauth, oauth-proxy, SSO OIDC, SSO SAML, one-tap).
Credit
Reported by @avrmeduard.
Resources
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "better-auth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53516"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-345"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-07T20:55:13Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- Their application uses `better-auth` at a version `\u003c 1.6.11` on the stable line, or any current `next` pre-release.\n- `emailAndPassword.enabled: true` is set in their application\u0027s `betterAuth({ ... })` configuration.\n- At least one OAuth or SSO provider is configured (any built-in social provider, or `genericOAuth(...)`, or any provider via `@better-auth/sso`).\n- `account.accountLinking.disableImplicitLinking` is not set to `true`.\n- `account.accountLinking.enabled` is not set to `false`.\n\nSetting either `disableImplicitLinking: true` or `enabled: false` closes the hole at the cost of breaking the standard \"add another login method\" UX. `emailAndPassword.requireEmailVerification: true` does not mitigate, because the link-time `emailVerified` flip promotes the attacker\u0027s row to verified, after which the password login becomes usable.\n\nFix:\n\n1. Upgrade to `better-auth@1.6.11` or later.\n2. If developers cannot upgrade, see workarounds below.\n\n### Summary\n\nThe OAuth callback\u0027s auto-link gate in `handleOAuthUserInfo` admits an implicit account link whenever the provider asserts `email_verified: true`, without requiring the local user row\u0027s `emailVerified` to also be `true`. An attacker who pre-registers a victim\u0027s email through `/sign-up/email` (which writes a row with `emailVerified: false`) can have the victim\u0027s later OAuth identity bound to the attacker\u0027s user row, granting both a password login and the victim\u0027s OAuth identity on the same account. This is the pre-account-hijacking class \u2014 the same shape as Microsoft \"nOAuth\" (2023) and the Sign in with Apple JWT flaw (2020).\n\n### Details\n\nThe auto-link gate validates only the OAuth provider\u0027s `userInfo.emailVerified` claim. The local row\u0027s `emailVerified` field is never read. When no `(accountId, providerId)` match exists, the user lookup falls back to email, which surfaces any pre-registered row at that email.\n\nA separate post-link step promotes the local `emailVerified` to `true` when the provider\u0027s claim is `true` and the local email matches the provider\u0027s email. This step is correct for legitimate first-time linking, but combined with the missing local-side check it becomes load-bearing for the takeover: after the link, the attacker\u0027s password row is treated as verified, defeating `requireEmailVerification: true` as a mitigation.\n\nThe fix adds the local-side ownership check to the gate: implicit linking now also rejects when `dbUser.user.emailVerified` is `false`. The same primitive lives in `one-tap` and inherits the same fix shape; the SSO `domainVerified` short-circuit follows separately as a hardening change.\n\n### Patches\n\nFixed in `better-auth@1.6.11`. Implicit linking now refuses to attach an OAuth identity to a local account whose `emailVerified` flag is `false`. The same gate change applies in the `one-tap` sign-in plugin, which previously had its own simpler linking path. The Google ID-token `email_verified` claim is also normalized through `toBoolean` so a string `\"false\"` is treated as falsy (some Google responses send the string, which the prior code treated as truthy).\n\nThe public surface for the new gate is `account.accountLinking.requireLocalEmailVerified`, defaulted to `true`. Applications whose users sign up through OAuth without ever verifying their email locally can opt out with `account: { accountLinking: { requireLocalEmailVerified: false } }` to retain the legacy permissive behavior. The option is marked `@deprecated`; the gate at each call site carries a `FIXME` pointing at the next-minor follow-up that drops the option and makes the check unconditional.\n\nTest fixtures across the `admin`, `oidc-provider`, `mcp`, `generic-oauth`, `last-login-method`, and `oauth-provider` suites now pre-verify created users via a `databaseHooks.user.create.before` hook (or the `disableTestUser` opt-in on the oauth-provider RP fixture) so those suites continue to exercise their role and flow logic rather than tripping the new gate.\n\n### Workarounds\n\nIf developers cannot upgrade their applications immediately:\n\n- **Disable implicit linking**: set `account.accountLinking.disableImplicitLinking: true`. Forces all linking through the authenticated `/link-social` endpoint where the user must already be signed in.\n- **Disable linking entirely**: set `account.accountLinking.enabled: false`. Closes the hole but breaks the multi-login-method UX entirely.\n\n`emailAndPassword.requireEmailVerification: true` alone does not mitigate, because the link-time `emailVerified` flip promotes the attacker\u0027s row to verified.\n\n### Impact\n\n- **Account takeover via pre-account hijacking**: the attacker holds a working password login plus the victim\u0027s OAuth identity on the same account, granting persistent access.\n- **`requireEmailVerification: true` bypass**: the attacker\u0027s password login becomes usable post-link.\n- **Cross-flow reach**: every OAuth and SSO sign-in path that calls `handleOAuthUserInfo` is affected (built-in social providers, generic-oauth, oauth-proxy, SSO OIDC, SSO SAML, one-tap).\n\n### Credit\n\nReported by @avrmeduard.\n\n### Resources\n\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- [Sudhodanan \u0026 Paverd, Pre-hijacked accounts: an empirical study of security failures in user account creation on the web (USENIX Security 2022)](https://www.usenix.org/conference/usenixsecurity22/presentation/sudhodanan)",
"id": "GHSA-g38m-r43w-p2q7",
"modified": "2026-07-07T20:55:13Z",
"published": "2026-07-07T20:55:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-g38m-r43w-p2q7"
},
{
"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:R/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Better Auth has an account takeover issue via OAuth auto-link to unverified pre-registered email"
}
GHSA-G396-HMH7-47G4
Vulnerability from github – Published: 2022-05-24 16:48 – Updated: 2024-04-04 00:58An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device allows a user to install applications written in the Lua programming language. Also the interface allows any user to write his/her application in the Lua language. However, this functionality is not protected by authentication and this allows an attacker to run arbitrary Lua code on the device. The POST request is forwarded to LuaUPNP daemon on the device. This binary handles the received Lua code in the function "LU::JobHandler_LuaUPnP::RunLua(LU::JobHandler_LuaUPnP __hidden this, LU::UPnPActionWrapper )". The value in the "code" parameter is then passed to the function "LU::LuaInterface::RunCode(char const*)" which actually loads the Lua engine and runs the code.
{
"affected": [],
"aliases": [
"CVE-2017-9389"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-06-17T20:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered on Vera VeraEdge 1.7.19 and Veralite 1.7.481 devices. The device provides a web user interface that allows a user to manage the device. As a part of the functionality the device allows a user to install applications written in the Lua programming language. Also the interface allows any user to write his/her application in the Lua language. However, this functionality is not protected by authentication and this allows an attacker to run arbitrary Lua code on the device. The POST request is forwarded to LuaUPNP daemon on the device. This binary handles the received Lua code in the function \"LU::JobHandler_LuaUPnP::RunLua(LU::JobHandler_LuaUPnP *__hidden this, LU::UPnPActionWrapper *)\". The value in the \"code\" parameter is then passed to the function \"LU::LuaInterface::RunCode(char const*)\" which actually loads the Lua engine and runs the code.",
"id": "GHSA-g396-hmh7-47g4",
"modified": "2024-04-04T00:58:54Z",
"published": "2022-05-24T16:48:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9389"
},
{
"type": "WEB",
"url": "https://github.com/ethanhunnt/IoT_vulnerabilities/blob/master/Vera_sec_issues.pdf"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Jun/8"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/153242/Veralite-Veraedge-Router-XSS-Command-Injection-CSRF-Traversal.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/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.