CVE-2026-41574: Github.com/nhost/nhost Nhost Vulnerable To Account Takeover Vulnerability

CRITICAL
Advisory Identifier: GHSA-6g38-8j4p-j3pr
CVSS 9.8
CWE-287
Published
Advisory Summary

CVE-2026-41574 is a CRITICAL (CVSS 9.8) nhost vulnerable to account takeover vulnerability (CWE-287: Improper Authentication) affecting Github.com/nhost/nhost libraries in the Go ecosystem. The issue involves nhost vulnerable to account takeover via oauth email verification bypass. Remediation is available by upgrading affected packages to version 0.0.0-20260417112436-ec8dab3f2cf4.

CVE-2026-41574 at a Glance

CVE Identifier CVE-2026-41574
GHSA Identifier GHSA-6g38-8j4p-j3pr
Severity CRITICAL
CVSS v3.1 Base Score 9.8
CWE Classification CWE-287: Improper Authentication
Affected Product Github.com/nhost/nhost
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 9.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability High (A:H)

How to Fix CVE-2026-41574

To remediate this vulnerability, upgrade all affected Github.com/nhost/nhost dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/nhost/nhost fixed: 0.0.0-20260417112436-ec8dab3f2cf4
Upgrade github.com/nhost/nhost to 0.0.0-20260417112436-ec8dab3f2cf4
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/nhost/nhost

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-41574, inspect your project dependencies for Github.com/nhost/nhost:

inspect dependencies for github.com/nhost/nhost

Analyze the terminal output to locate any version of Github.com/nhost/nhost in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.0.0-20260417112436-ec8dab3f2cf4), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-287: Improper Authentication, where when an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. In Github.com/nhost/nhost, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary 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: ```go // 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: ```go 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: ```json { "id": "80351110224678912", "username": "Nelly", "email": "nelly@discord.com", "verified": true } ``` The Nhost struct is **missing this field**. Go's JSON decoder silently discards it: ```go 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: ```go 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:** ```go 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: ```go // 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:** ```go 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: ```go 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: ```go 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`. 1. Attacker opens **Discord → User Settings → Account**, changes email to `admin@target.io`, and dismisses the dialog, **without clicking the confirmation link**. 2. At this point Discord's API returns `"email": "admin@target.io", "verified": false` for the attacker's account. 3. Attacker visits the target application and clicks **Sign in with Discord**. 4. 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" != ""`. 5. Nhost finds the victim's account by email, sees no Discord provider row linked to it, and calls `InsertUserProvider` to link the attacker's Discord ID. 6. Nhost issues a full session for the victim's account and returns it to the attacker. 7. **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| |**Facebook**|`email` via Graph API|Facebook only includes email in the response when it is confirmed| |**Twitter**|`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.

CVE-2026-41574 Affected Github.com/nhost/nhost Versions

1 component(s)
Fixed Versions:
0.0.0-20260417112436-ec8dab3f2cf4
Product / Package Ecosystem Affected Versions Fixed Version
github.com/nhost/nhost
Go
< 0.0.0-20260417112436-ec8dab3f2cf4
0.0.0-20260417112436-ec8dab3f2cf4

References

Frequently Asked Questions

What is CVE-2026-41574?
CVE-2026-41574 is a security vulnerability in Github.com/nhost/nhost involving Nhost Vulnerable to Account Takeover via OAuth Email Verification Bypass under CWE-287: Improper Authentication.
Which Github.com/nhost/nhost versions are affected?
Affected versions include releases prior to 0.0.0-20260417112436-ec8dab3f2cf4 across affected packages: github.com/nhost/nhost.
What version fixes CVE-2026-41574?
Upgrading to 0.0.0-20260417112436-ec8dab3f2cf4 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/nhost/nhost affected?
Yes, github.com/nhost/nhost is affected in releases prior to 0.0.0-20260417112436-ec8dab3f2cf4. Upgrade your dependency to 0.0.0-20260417112436-ec8dab3f2cf4 or later.
What is the CVSS score of CVE-2026-41574?
CVE-2026-41574 has a CVSS v3.1 base score of 9.8 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
What CWE is associated with CVE-2026-41574?
CVE-2026-41574 is classified under CWE-287: Improper Authentication (When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.).
How can I check Go dependencies for CVE-2026-41574?
Run the dependency tree command: 'inspect dependencies for github.com/nhost/nhost'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-6g38-8j4p-j3pr",
  "modified" : "2026-05-14T20:30:38Z",
  "published" : "2026-04-18T01:00:06Z",
  "aliases" : [ "CVE-2026-41574" ],
  "summary" : "Nhost Vulnerable to Account Takeover via OAuth Email Verification Bypass",
  "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's 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't own to Nhost, have the OAuth identity merged into the victim's 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's provider identity to the victim's 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's 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's 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's 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'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.\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's 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's 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 → User Settings → Account**, changes email to `admin@target.io`, and dismisses the dialog, **without clicking the confirmation link**.\n    \n2. At this point Discord's API returns `\"email\": \"admin@target.io\", \"verified\": false` for the attacker's 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's account by email, sees no Discord provider row linked to it, and calls `InsertUserProvider` to link the attacker's Discord ID.\n    \n6. Nhost issues a full session for the victim's 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's 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's 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.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
  }, {
    "type" : "CVSS_V4",
    "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/nhost/nhost"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.0.0-20260417112436-ec8dab3f2cf4"
      } ]
    } ]
  } ],
  "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"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-287" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-18T01:00:06Z",
    "nvd_published_at" : "2026-05-08T15:16:40Z"
  }
}