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.
5964 vulnerabilities reference this CWE, most recent first.
GHSA-6FRJ-JHQ2-GCFC
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in the Cisco Umbrella API could allow an authenticated, remote attacker to view and modify data across their organization and other organizations. The vulnerability is due to insufficient authentication configurations for the API interface of Cisco Umbrella. An attacker could exploit this vulnerability to view and potentially modify data for their organization or other organizations. A successful exploit could allow the attacker to read or modify data across multiple organizations.
{
"affected": [],
"aliases": [
"CVE-2018-0435"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-05T14:29:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in the Cisco Umbrella API could allow an authenticated, remote attacker to view and modify data across their organization and other organizations. The vulnerability is due to insufficient authentication configurations for the API interface of Cisco Umbrella. An attacker could exploit this vulnerability to view and potentially modify data for their organization or other organizations. A successful exploit could allow the attacker to read or modify data across multiple organizations.",
"id": "GHSA-6frj-jhq2-gcfc",
"modified": "2022-05-13T01:35:10Z",
"published": "2022-05-13T01:35:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0435"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180905-umbrella-api"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/105283"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6FV5-XV88-5C73
Vulnerability from github – Published: 2022-05-13 01:31 – Updated: 2022-05-13 01:31The HTTP Connector component of TIBCO Software Inc.'s TIBCO ActiveMatrix BusinessWorks contains a vulnerability that theoretically allows unauthenticated HTTP requests to be processed by the BusinessWorks engine even when authentication is required. This possibility is restricted to circumstances where HTTP "Basic Authentication" policy is used in conjunction with an XML Authentication resource. The BusinessWorks engine might instead use credentials from a prior HTTP request for authorization purposes. Affected releases are TIBCO Software Inc. TIBCO ActiveMatrix BusinessWorks: versions up to and including 6.4.2.
{
"affected": [],
"aliases": [
"CVE-2019-8990"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-09T18:29:00Z",
"severity": "HIGH"
},
"details": "The HTTP Connector component of TIBCO Software Inc.\u0027s TIBCO ActiveMatrix BusinessWorks contains a vulnerability that theoretically allows unauthenticated HTTP requests to be processed by the BusinessWorks engine even when authentication is required. This possibility is restricted to circumstances where HTTP \"Basic Authentication\" policy is used in conjunction with an XML Authentication resource. The BusinessWorks engine might instead use credentials from a prior HTTP request for authorization purposes. Affected releases are TIBCO Software Inc. TIBCO ActiveMatrix BusinessWorks: versions up to and including 6.4.2.",
"id": "GHSA-6fv5-xv88-5c73",
"modified": "2022-05-13T01:31:10Z",
"published": "2022-05-13T01:31:10Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8990"
},
{
"type": "WEB",
"url": "https://www.tibco.com/support/advisories/2019/04/tibco-security-advisory-april-9-2019-tibco-activematrix-businessworks"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/107840"
},
{
"type": "WEB",
"url": "http://www.tibco.com/services/support/advisories"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6FWW-F84W-V8JG
Vulnerability from github – Published: 2022-05-17 02:42 – Updated: 2022-05-17 02:42In the Secure File System in all Android releases from CAF using the Linux kernel, a capture-replay vulnerability could potentially exist.
{
"affected": [],
"aliases": [
"CVE-2014-9952"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-06T14:29:00Z",
"severity": "HIGH"
},
"details": "In the Secure File System in all Android releases from CAF using the Linux kernel, a capture-replay vulnerability could potentially exist.",
"id": "GHSA-6fww-f84w-v8jg",
"modified": "2022-05-17T02:42:15Z",
"published": "2022-05-17T02:42:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2014-9952"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-05-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98253"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6G38-8J4P-J3PR
Vulnerability from github – Published: 2026-04-18 01:00 – Updated: 2026-05-14 20:30Summary
Nhost automatically links an incoming OAuth identity to an existing Nhost account when the email addresses match. This is only safe when the email has been verified by the OAuth provider. Nhost's controller trusts a profile.EmailVerified boolean that is set by each provider adapter.
The vulnerability is that several provider adapters do not correctly populate this field they either silently drop a verified field the provider API actually returns (Discord), or they fall back to accepting unconfirmed emails and marking them as verified (Bitbucket). Two Microsoft providers (AzureAD, EntraID) derive the email from non-ownership-proving fields like the user principal name, then mark it verified.
The result is that an attacker can present an email they don't own to Nhost, have the OAuth identity merged into the victim's account, and receive a full authenticated session.
Root Cause
In services/auth/go/controller/sign_in_id_token.go, providerFlowSignIn() links a new provider identity to an existing account by email match with no verification guard:
// sign_in_id_token.go:267-296
func (ctrl *Controller) providerFlowSignIn(
ctx context.Context,
user sql.AuthUser,
providerFound bool,
provider string,
providerUserID string,
logger *slog.Logger,
) (*api.Session, *APIError) {
if !providerFound {
// Links attacker's provider identity to the victim's account.
// profile.EmailVerified is NEVER checked here.
ctrl.wf.InsertUserProvider(ctx, user.ID, provider, providerUserID, logger)
}
// Issues a full session to the attacker.
session, _ := ctrl.wf.NewSession(ctx, user, nil, logger)
return session, nil
}
The controller places full trust in whatever profile.EmailVerified the adapter returned. The vulnerabilities below show how that trust is violated.
Correct Implementation (For Reference)
GitHub: providers/github.go
GitHub fetches /user/emails and reads the verified boolean per entry. selectEmail() picks only verified emails. The result is correctly mapped:
selected := selectEmail(emails) // only selects verified: true entries
return oidc.Profile{
Email: selected.Email,
EmailVerified: selected.Verified, // real boolean from GitHub API
...
}
Vulnerable Providers
1. Discord: providers/discord.go
The Discord GET /users/@me API returns a verified boolean field. Per Discord's official documentation and example User Object:
{
"id": "80351110224678912",
"username": "Nelly",
"email": "nelly@discord.com",
"verified": true
}
The Nhost struct is missing this field. Go's JSON decoder silently discards it:
type discordUserProfile struct {
ID string `json:"id"`
Username string `json:"username"`
Discriminator string `json:"discriminator"`
Email string `json:"email"`
Locale string `json:"locale"`
Avatar string `json:"avatar"`
// MISSING: Verified bool `json:"verified"`
}
The adapter then sets:
EmailVerified: userProfile.Email != "", // always true when email is present
Why this is exploitable: Discord allows users to create account without verifying the email address and change their email address without immediately verifying it. After changing email, the account has "verified": false in the API response until the user clicks a confirmation link. An attacker can change their Discord email to the victim's address, leave it unverified, and the Nhost adapter will still present EmailVerified: true, because it never reads the verified field at all.
Fix:
type discordUserProfile struct {
ID string `json:"id"`
Username string `json:"username"`
Discriminator string `json:"discriminator"`
Email string `json:"email"`
Verified bool `json:"verified"` // add this
Locale string `json:"locale"`
Avatar string `json:"avatar"`
}
return oidc.Profile{
Email: userProfile.Email,
EmailVerified: userProfile.Verified, // use it
...
}
2. Bitbucket: providers/bitbucket.go
The Bitbucket adapter correctly queries /user/emails for confirmed entries, but introduces a fallback that defeats its own check:
// bitbucket.go:103-132
for _, e := range emailResp.Values {
if e.IsConfirmed {
primaryEmail = e.Email
break
} else if fallbackEmail == "" {
fallbackEmail = e.Email // stores unconfirmed email
}
}
if primaryEmail == "" {
if fallbackEmail == "" {
return oidc.Profile{}, ErrNoConfirmedBitbucketEmail
}
primaryEmail = fallbackEmail // uses unconfirmed email
}
return oidc.Profile{
Email: primaryEmail,
EmailVerified: primaryEmail != "", // marks it true anyway
...
}
Bitbucket's /user/emails endpoint returns all emails, including unconfirmed ones with "is_confirmed": false. An attacker can add the victim's email to their Bitbucket account without confirming it, triggering the fallback path.
Fix:
if primaryEmail == "" {
// Remove the fallback entirely no confirmed email means no sign-in
return oidc.Profile{}, ErrNoConfirmedBitbucketEmail
}
3. AzureAD: providers/azuread.go
AzureAD derives the email through a chain of fallbacks from the userinfo response:
email := userProfile.Email
if email == "" {
email = userProfile.Prefer // "preferred_username" not an email ownership proof
}
if email == "" {
email = userProfile.UPN // User Principal Name not an email ownership proof
}
return oidc.Profile{
Email: email,
EmailVerified: email != "", // marked verified regardless of source
...
}
preferred_username and UPN are internal Azure AD identity attributes. A UPN like attacker@tenant.onmicrosoft.com or a custom UPN set to ceo@target-company.com does not prove that the user controls that external email address. Yet Nhost will treat it as a verified email claim and merge identities if an existing account matches.
Fix: Do not fall back to preferred_username or UPN for account-linking email. Only use a field that Azure AD explicitly certifies as a verified external email (or use the OIDC id_token with the email_verified claim from Azure's v2 endpoint).
4. EntraID: providers/entraid.go
Same pattern as AzureAD. The EntraID adapter reads from graph.microsoft.com/oidc/userinfo but the struct has no email_verified field:
type entraidUser struct {
Sub string `json:"sub"`
GivenName string `json:"givenname"`
FamilyName string `json:"familyname"`
Email string `json:"email"`
// MISSING: EmailVerified bool `json:"email_verified"`
}
return oidc.Profile{
Email: userProfile.Email,
EmailVerified: userProfile.Email != "", // unconditional
...
}
Microsoft's OIDC userinfo endpoint does include an email_verified claim per the OpenID Connect specification. Nhost ignores it.
Fix: Add EmailVerified bool \json:"email_verified"`` to the struct and map it correctly.
Attack Scenario (Discord)
Setup: An Nhost application uses Discord OAuth. A victim has an account with admin@target.io.
-
Attacker opens Discord → User Settings → Account, changes email to
admin@target.io, and dismisses the dialog, without clicking the confirmation link. -
At this point Discord's API returns
"email": "admin@target.io", "verified": falsefor the attacker's account. -
Attacker visits the target application and clicks Sign in with Discord.
-
Nhost fetches the Discord profile. The missing
Verifiedfield in the struct causes the JSON decoder to drop it. The adapter setsEmailVerified: truebecause"admin@target.io" != "". -
Nhost finds the victim's account by email, sees no Discord provider row linked to it, and calls
InsertUserProviderto link the attacker's Discord ID. -
Nhost issues a full session for the victim's account and returns it to the attacker.
-
The attacker is now authenticated as the victim.
The attack is silent, the victim receives no notification and the session appears entirely legitimate.
Defense-in-Depth Gap (Informational)
Several other providers also use EmailVerified: email != "", the same logical pattern as the vulnerable ones above. However, these are not currently exploitable because the platforms themselves enforce email verification before returning an address in the API response:
| Provider | API Field Used | Why Not Exploitable Today |
|---|---|---|
| Twitch | email string only |
Twitch requires email verification at sign-up; the API never returns an unverified email |
| GitLab | email string only |
GET /api/v4/user only returns the confirmed primary email |
email via Graph API |
Facebook only includes email in the response when it is confirmed | |
email via verify_credentials |
Twitter requires a working email address on the account | |
| Spotify | email string only |
Spotify enforces verification before account activation |
| Windows Live | preferred account email |
Microsoft's Live API only surfaces confirmed addresses |
| WorkOS | email from SSO profile |
Controlled by the enterprise IdP |
These providers happen to be safe due to external platform behavior, not due to any validation in Nhost's code. The email != "" shortcut is fragile:
-
If any of these platforms change how their API works, Nhost silently becomes exploitable for that provider.
-
Any developer adding a new provider in the future will likely copy the same pattern, believing it is the established convention, creating vulnerabilities in new integrations.
For this reason, the controller-level guard in Layer 1 of the fix below is important even beyond the four currently vulnerable providers: it makes the system safe by design regardless of what any individual adapter returns.
Impact
-
Full account takeover of any existing Nhost user.
-
Requires no interaction from the victim.
-
Attacker can change the account email, disable other login methods, and permanently lock out the legitimate owner.
-
Severity escalates to Critical in applications with admin or privileged accounts.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/nhost/nhost"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260417112436-ec8dab3f2cf4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41574"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-18T01:00:06Z",
"nvd_published_at": "2026-05-08T15:16:40Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nNhost automatically links an incoming OAuth identity to an existing Nhost account when the email addresses match. This is only safe when the email has been **verified by the OAuth provider**. Nhost\u0027s controller trusts a `profile.EmailVerified` boolean that is set by each provider adapter.\n\nThe vulnerability is that several provider adapters **do not correctly populate this field** they either silently drop a `verified` field the provider API actually returns (Discord), or they fall back to accepting unconfirmed emails and marking them as verified (Bitbucket). Two Microsoft providers (AzureAD, EntraID) derive the email from non-ownership-proving fields like the user principal name, then mark it verified.\n\nThe result is that an attacker can present an email they don\u0027t own to Nhost, have the OAuth identity merged into the victim\u0027s account, and receive a full authenticated session.\n\n## Root Cause\n\nIn `services/auth/go/controller/sign_in_id_token.go`, `providerFlowSignIn()` links a new provider identity to an existing account by email match with no verification guard:\n\n```go\n// sign_in_id_token.go:267-296\nfunc (ctrl *Controller) providerFlowSignIn(\n ctx context.Context,\n user sql.AuthUser,\n providerFound bool,\n provider string,\n providerUserID string,\n logger *slog.Logger,\n) (*api.Session, *APIError) {\n if !providerFound {\n // Links attacker\u0027s provider identity to the victim\u0027s account.\n // profile.EmailVerified is NEVER checked here.\n ctrl.wf.InsertUserProvider(ctx, user.ID, provider, providerUserID, logger)\n }\n // Issues a full session to the attacker.\n session, _ := ctrl.wf.NewSession(ctx, user, nil, logger)\n return session, nil\n}\n```\n\nThe controller places full trust in whatever `profile.EmailVerified` the adapter returned. The vulnerabilities below show how that trust is violated.\n\n## Correct Implementation (For Reference)\n\n### GitHub: `providers/github.go`\n\nGitHub fetches `/user/emails` and reads the `verified` boolean per entry. `selectEmail()` picks only verified emails. The result is correctly mapped:\n\n```go\nselected := selectEmail(emails) // only selects verified: true entries\n\nreturn oidc.Profile{\n Email: selected.Email,\n EmailVerified: selected.Verified, // real boolean from GitHub API\n ...\n}\n```\n\n## Vulnerable Providers\n\n### 1. Discord: `providers/discord.go`\n\n**The Discord `GET /users/@me` API returns a `verified` boolean field.** Per Discord\u0027s official documentation and example User Object:\n\n```json\n{\n \"id\": \"80351110224678912\",\n \"username\": \"Nelly\",\n \"email\": \"nelly@discord.com\",\n \"verified\": true\n}\n```\n\nThe Nhost struct is **missing this field**. Go\u0027s JSON decoder silently discards it:\n\n```go\ntype discordUserProfile struct {\n ID string `json:\"id\"`\n Username string `json:\"username\"`\n Discriminator string `json:\"discriminator\"`\n Email string `json:\"email\"`\n Locale string `json:\"locale\"`\n Avatar string `json:\"avatar\"`\n // MISSING: Verified bool `json:\"verified\"`\n}\n```\n\nThe adapter then sets:\n\n```go\nEmailVerified: userProfile.Email != \"\", // always true when email is present\n```\n\n**Why this is exploitable:** Discord allows users to create account without verifying the email address and change their email address without immediately verifying it. After changing email, the account has `\"verified\": false` in the API response until the user clicks a confirmation link. An attacker can change their Discord email to the victim\u0027s address, leave it unverified, and the Nhost adapter will still present `EmailVerified: true`, because it never reads the `verified` field at all.\n\n**Fix:**\n\n```go\ntype discordUserProfile struct {\n ID string `json:\"id\"`\n Username string `json:\"username\"`\n Discriminator string `json:\"discriminator\"`\n Email string `json:\"email\"`\n Verified bool `json:\"verified\"` // add this\n Locale string `json:\"locale\"`\n Avatar string `json:\"avatar\"`\n}\n\nreturn oidc.Profile{\n Email: userProfile.Email,\n EmailVerified: userProfile.Verified, // use it\n ...\n}\n```\n\n### 2. Bitbucket: `providers/bitbucket.go`\n\nThe Bitbucket adapter correctly queries `/user/emails` for confirmed entries, but introduces a fallback that defeats its own check:\n\n```go\n// bitbucket.go:103-132\nfor _, e := range emailResp.Values {\n if e.IsConfirmed {\n primaryEmail = e.Email\n break\n } else if fallbackEmail == \"\" {\n fallbackEmail = e.Email // stores unconfirmed email\n }\n}\n\nif primaryEmail == \"\" {\n if fallbackEmail == \"\" {\n return oidc.Profile{}, ErrNoConfirmedBitbucketEmail\n }\n primaryEmail = fallbackEmail // uses unconfirmed email\n}\n\nreturn oidc.Profile{\n Email: primaryEmail,\n EmailVerified: primaryEmail != \"\", // marks it true anyway\n ...\n}\n```\n\nBitbucket\u0027s `/user/emails` endpoint returns all emails, including unconfirmed ones with `\"is_confirmed\": false`. An attacker can add the victim\u0027s email to their Bitbucket account without confirming it, triggering the fallback path.\n\n**Fix:**\n\n```go\nif primaryEmail == \"\" {\n // Remove the fallback entirely no confirmed email means no sign-in\n return oidc.Profile{}, ErrNoConfirmedBitbucketEmail\n}\n```\n\n### 3. AzureAD: `providers/azuread.go`\n\nAzureAD derives the email through a chain of fallbacks from the userinfo response:\n\n```go\nemail := userProfile.Email\nif email == \"\" {\n email = userProfile.Prefer // \"preferred_username\" not an email ownership proof\n}\nif email == \"\" {\n email = userProfile.UPN // User Principal Name not an email ownership proof\n}\n\nreturn oidc.Profile{\n Email: email,\n EmailVerified: email != \"\", // marked verified regardless of source\n ...\n}\n```\n\n`preferred_username` and UPN are internal Azure AD identity attributes. A UPN like `attacker@tenant.onmicrosoft.com` or a custom UPN set to `ceo@target-company.com` does not prove that the user controls that external email address. Yet Nhost will treat it as a verified email claim and merge identities if an existing account matches.\n\n**Fix:** Do not fall back to `preferred_username` or UPN for account-linking email. Only use a field that Azure AD explicitly certifies as a verified external email (or use the OIDC `id_token` with the `email_verified` claim from Azure\u0027s v2 endpoint).\n\n### 4. EntraID: `providers/entraid.go`\n\nSame pattern as AzureAD. The EntraID adapter reads from `graph.microsoft.com/oidc/userinfo` but the struct has no `email_verified` field:\n\n```go\ntype entraidUser struct {\n Sub string `json:\"sub\"`\n GivenName string `json:\"givenname\"`\n FamilyName string `json:\"familyname\"`\n Email string `json:\"email\"`\n // MISSING: EmailVerified bool `json:\"email_verified\"`\n}\n\nreturn oidc.Profile{\n Email: userProfile.Email,\n EmailVerified: userProfile.Email != \"\", // unconditional\n ...\n}\n```\n\nMicrosoft\u0027s OIDC userinfo endpoint does include an `email_verified` claim per the OpenID Connect specification. Nhost ignores it.\n\n**Fix:** Add `EmailVerified bool \\`json:\"email_verified\"`` to the struct and map it correctly.\n\n## Attack Scenario (Discord)\n\n**Setup:** An Nhost application uses Discord OAuth. A victim has an account with `admin@target.io`.\n\n1. Attacker opens **Discord \u2192 User Settings \u2192 Account**, changes email to `admin@target.io`, and dismisses the dialog, **without clicking the confirmation link**.\n \n2. At this point Discord\u0027s API returns `\"email\": \"admin@target.io\", \"verified\": false` for the attacker\u0027s account.\n \n3. Attacker visits the target application and clicks **Sign in with Discord**.\n \n4. Nhost fetches the Discord profile. The missing `Verified` field in the struct causes the JSON decoder to drop it. The adapter sets `EmailVerified: true` because `\"admin@target.io\" != \"\"`.\n \n5. Nhost finds the victim\u0027s account by email, sees no Discord provider row linked to it, and calls `InsertUserProvider` to link the attacker\u0027s Discord ID.\n \n6. Nhost issues a full session for the victim\u0027s account and returns it to the attacker.\n \n7. **The attacker is now authenticated as the victim.**\n \n\nThe attack is silent, the victim receives no notification and the session appears entirely legitimate.\n\n## Defense-in-Depth Gap (Informational)\n\nSeveral other providers also use `EmailVerified: email != \"\"`, the same logical pattern as the vulnerable ones above. However, these are **not currently exploitable** because the platforms themselves enforce email verification before returning an address in the API response:\n\n|Provider|API Field Used|Why Not Exploitable Today|\n|---|---|---|\n|**Twitch**|`email` string only|Twitch requires email verification at sign-up; the API never returns an unverified email|\n|**GitLab**|`email` string only|`GET /api/v4/user` only returns the confirmed primary email|\n|**Facebook**|`email` via Graph API|Facebook only includes email in the response when it is confirmed|\n|**Twitter**|`email` via `verify_credentials`|Twitter requires a working email address on the account|\n|**Spotify**|`email` string only|Spotify enforces verification before account activation|\n|**Windows Live**|`preferred` `account` email|Microsoft\u0027s Live API only surfaces confirmed addresses|\n|**WorkOS**|`email` from SSO profile|Controlled by the enterprise IdP|\n\nThese providers happen to be safe due to **external platform behavior, not due to any validation in Nhost\u0027s code.** The `email != \"\"` shortcut is fragile:\n\n- If any of these platforms change how their API works, Nhost silently becomes exploitable for that provider.\n \n- Any developer adding a new provider in the future will likely copy the same pattern, believing it is the established convention, creating vulnerabilities in new integrations.\n \n\nFor this reason, the controller-level guard in Layer 1 of the fix below is important even beyond the four currently vulnerable providers: it makes the system safe by design regardless of what any individual adapter returns.\n\n## Impact\n\n- Full account takeover of any existing Nhost user.\n \n- Requires no interaction from the victim.\n \n- Attacker can change the account email, disable other login methods, and permanently lock out the legitimate owner.\n \n- Severity escalates to Critical in applications with admin or privileged accounts.",
"id": "GHSA-6g38-8j4p-j3pr",
"modified": "2026-05-14T20:30:38Z",
"published": "2026-04-18T01:00:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nhost/nhost/security/advisories/GHSA-6g38-8j4p-j3pr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41574"
},
{
"type": "WEB",
"url": "https://github.com/nhost/nhost/pull/4162"
},
{
"type": "WEB",
"url": "https://github.com/nhost/nhost/commit/ec8dab3f2cf46e1131ddaf893d56c37aa00380b2"
},
{
"type": "PACKAGE",
"url": "https://github.com/nhost/nhost"
},
{
"type": "WEB",
"url": "https://github.com/nhost/nhost/releases/tag/auth%400.49.1"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Nhost Vulnerable to Account Takeover via OAuth Email Verification Bypass"
}
GHSA-6G49-7HRC-9J92
Vulnerability from github – Published: 2024-09-04 18:30 – Updated: 2024-09-04 18:30ZZCMS 2023 contains a vulnerability in the captcha reuse logic located in /inc/function.php. The checkyzm function does not properly refresh the captcha value after a failed validation attempt. As a result, an attacker can exploit this flaw by repeatedly submitting the same incorrect captcha response, allowing them to capture the correct captcha value through error messages.
{
"affected": [],
"aliases": [
"CVE-2024-44821"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-04T16:15:07Z",
"severity": "MODERATE"
},
"details": "ZZCMS 2023 contains a vulnerability in the captcha reuse logic located in /inc/function.php. The checkyzm function does not properly refresh the captcha value after a failed validation attempt. As a result, an attacker can exploit this flaw by repeatedly submitting the same incorrect captcha response, allowing them to capture the correct captcha value through error messages.",
"id": "GHSA-6g49-7hrc-9j92",
"modified": "2024-09-04T18:30:57Z",
"published": "2024-09-04T18:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-44821"
},
{
"type": "WEB",
"url": "https://github.com/gkdgkd123/codeAudit/blob/main/CVE-2024-44821%20ZZCMS2023%20%E9%AA%8C%E8%AF%81%E7%A0%81%E5%A4%8D%E7%94%A8%E9%80%BB%E8%BE%91%E6%BC%8F%E6%B4%9E.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6G5M-C89W-7PWF
Vulnerability from github – Published: 2026-03-19 12:30 – Updated: 2026-03-19 12:30Improper Authentication vulnerability in Secomea GateManager (webserver modules) allows Authentication Bypass.This issue affects GateManager: 11.4;0.
{
"affected": [],
"aliases": [
"CVE-2025-14716"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-19T11:16:14Z",
"severity": "MODERATE"
},
"details": "Improper Authentication vulnerability in Secomea GateManager (webserver modules) allows Authentication Bypass.This issue affects GateManager: 11.4;0.",
"id": "GHSA-6g5m-c89w-7pwf",
"modified": "2026-03-19T12:30:32Z",
"published": "2026-03-19T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14716"
},
{
"type": "WEB",
"url": "https://www.secomea.com/support/cybersecurity-advisory"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6G5W-JMG4-8QXF
Vulnerability from github – Published: 2022-03-05 00:00 – Updated: 2022-03-17 00:03Under certain ldap conditions, Cacti authentication can be bypassed with certain credential types.
{
"affected": [],
"aliases": [
"CVE-2022-0730"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-03T23:15:00Z",
"severity": "CRITICAL"
},
"details": "Under certain ldap conditions, Cacti authentication can be bypassed with certain credential types.",
"id": "GHSA-6g5w-jmg4-8qxf",
"modified": "2022-03-17T00:03:37Z",
"published": "2022-03-05T00:00:47Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0730"
},
{
"type": "WEB",
"url": "https://github.com/Cacti/cacti/issues/4562"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/03/msg00038.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2022/12/msg00039.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/RVOALVZSCBFNOAAZVHTJFSFB7UDSNYQ2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZH67CCORDEYFG7NL7G6UH47PAV2PU7BA"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/ZJERS4NYIGJUXEGT6ATUQA4CBYBRDLRA"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/RVOALVZSCBFNOAAZVHTJFSFB7UDSNYQ2"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZH67CCORDEYFG7NL7G6UH47PAV2PU7BA"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZJERS4NYIGJUXEGT6ATUQA4CBYBRDLRA"
},
{
"type": "WEB",
"url": "https://www.debian.org/security/2022/dsa-5298"
}
],
"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-6G65-WV5P-GC7R
Vulnerability from github – Published: 2022-05-24 17:32 – Updated: 2022-05-24 17:32In SonarQube 8.4.2.36762, an external attacker can achieve authentication bypass through SonarScanner. With an empty value for the -D sonar.login option, anonymous authentication is forced. This allows creating and overwriting public and private projects via the /api/ce/submit endpoint.
{
"affected": [],
"aliases": [
"CVE-2020-28002"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-11-02T21:15:00Z",
"severity": "MODERATE"
},
"details": "In SonarQube 8.4.2.36762, an external attacker can achieve authentication bypass through SonarScanner. With an empty value for the -D sonar.login option, anonymous authentication is forced. This allows creating and overwriting public and private projects via the /api/ce/submit endpoint.",
"id": "GHSA-6g65-wv5p-gc7r",
"modified": "2022-05-24T17:32:59Z",
"published": "2022-05-24T17:32:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-28002"
},
{
"type": "WEB",
"url": "https://csl.com.co/sonarqube-auditando-al-auditor-parte-ii"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-6GC8-5V43-5G2X
Vulnerability from github – Published: 2022-05-17 02:40 – Updated: 2025-10-22 00:31SKYSEA Client View Ver.11.221.03 and earlier allows remote code execution via a flaw in processing authentication on the TCP connection with the management console program.
{
"affected": [],
"aliases": [
"CVE-2016-7836"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-09T16:29:00Z",
"severity": "CRITICAL"
},
"details": "SKYSEA Client View Ver.11.221.03 and earlier allows remote code execution via a flaw in processing authentication on the TCP connection with the management console program.",
"id": "GHSA-6gc8-5v43-5g2x",
"modified": "2025-10-22T00:31:23Z",
"published": "2022-05-17T02:40:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-7836"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN84995847/index.html"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2016-7836"
},
{
"type": "WEB",
"url": "https://www.skygroup.jp/security-info/170308.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/95062"
},
{
"type": "WEB",
"url": "http://www.skyseaclientview.net/news/161221"
}
],
"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-6GFF-F85J-33MR
Vulnerability from github – Published: 2026-05-27 09:31 – Updated: 2026-05-27 09:31The Login with NEAR plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 0.3.3. The ajaxLoginWithNear() function — registered as a wp_ajax_nopriv action and therefore reachable by unauthenticated users — accepts an attacker-supplied account POST parameter and issues a valid WordPress authentication cookie based solely on a substring check for .near, with no nonce verification, cryptographic signature validation, challenge-response exchange, or any proof that the requester controls the corresponding NEAR wallet. This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, whose email address matches the deterministic <account>@near.org pattern derived from the supplied account value. If no matching user exists, the handler automatically creates and authenticates a new WordPress account for the attacker-controlled identifier, providing a further avenue for unauthorized account creation.
{
"affected": [],
"aliases": [
"CVE-2026-8994"
],
"database_specific": {
"cwe_ids": [
"CWE-287"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-27T07:16:18Z",
"severity": "HIGH"
},
"details": "The Login with NEAR plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 0.3.3. The `ajaxLoginWithNear()` function \u2014 registered as a `wp_ajax_nopriv` action and therefore reachable by unauthenticated users \u2014 accepts an attacker-supplied `account` POST parameter and issues a valid WordPress authentication cookie based solely on a substring check for `.near`, with no nonce verification, cryptographic signature validation, challenge-response exchange, or any proof that the requester controls the corresponding NEAR wallet. This makes it possible for unauthenticated attackers to log in as any existing WordPress user, including administrators, whose email address matches the deterministic `\u003caccount\u003e@near.org` pattern derived from the supplied `account` value. If no matching user exists, the handler automatically creates and authenticates a new WordPress account for the attacker-controlled identifier, providing a further avenue for unauthorized account creation.",
"id": "GHSA-6gff-f85j-33mr",
"modified": "2026-05-27T09:31:14Z",
"published": "2026-05-27T09:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8994"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/near-login/trunk/Controllers/UserLoginController.php#L16"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/near-login/trunk/Controllers/UserLoginController.php#L29"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/near-login/trunk/Controllers/UserLoginController.php#L46"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/near-login/trunk/Controllers/UserLoginController.php#L76"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f1eacb72-df11-4a3b-9064-f8f776f3522b?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/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.