CVE-2026-73302

Executive Summary

CVE-2026-73302 is an improper-authentication vulnerability (CWE-287) affecting the OIDC single sign-on (SSO) account-linking flow in Budibase, an open-source low-code platform. All Budibase deployments prior to version 3.39.30 that use a configured OIDC identity provider (IdP) are affected; an attacker who can authenticate with a provider identity asserting a victim's email address as unverified can have that fresh identity merged into the victim's Budibase account, inheriting the victim's roles and permissions. The issue is fixed in Budibase 3.39.30, although the patch is currently claimed by a single source (OSV) and has not been independently confirmed.

Technical Analysis

The vulnerability resides in the OIDC/passport middleware chain of the Budibase backend and is described at the code level in the NVD entry. Two backend components are implicated:

• packages/backend-core/src/middleware/passport/sso/oidc.ts: This module resolves the email claim from the identity provider's token without enforcing getEmailVerified or requiring the standard OpenID Connect email_verified claim. In a correctly implemented OIDC flow, email_verified indicates whether the IdP has positively confirmed the end-user's control of the asserted email address. Because this check is absent, an email address contained in a token — regardless of ownership or verification state — is treated as a legitimate identity attribute by Budibase.

• packages/backend-core/src/middleware/passport/sso/sso.ts: This module performs account linking and uses users.getGlobalUserByEmail as a fallback linking key. When a new provider identity presents an email address that matches an existing Budibase global user, the platform merges the new identity into that existing user record instead of rejecting the unverified assertion or creating an isolated account.

Taken together, the two flaws create a cross-trust-boundary account-linking primitive: the application trusts an unverified email assertion from the IdP and uses it as the sole key to bind a new identity to an existing account. Because the attacker controls the IdP identity but not the victim's Budibase credentials, this is not a conventional credential compromise — it is an authentication logic flaw in which the subject of the email assertion is never actually authenticated. This aligns with CWE-287 (Improper Authentication): Budibase fails to properly authenticate the claimant before granting account-linking privileges.

The attack surface is the public-facing Budibase login/SSO entry point on instances where OIDC is configured. The vulnerable logic lives in the backend-core Passport middleware, which executes during the OIDC callback and token-resolution phase, i.e., after the user has redirected back from the IdP. No CVSS vector or score has been published for this CVE. The EPSS score is 0.00313 (24.1st percentile of exploited CVEs), indicating a low current probability of exploitation in the wild. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no public PoC, Nuclei template, or exploit code has been identified.

Exploitation Scenarios

No public PoC is available, so the attack chain below is inferred from the vulnerability class and the specific behavior described in the NVD entry. The chain requires a Budibase instance with OIDC SSO enabled and an IdP that will issue tokens containing an email address that the attacker does not control without setting email_verified to true.

1. Reconnaissance / target identification: An attacker identifies an internet-facing Budibase instance that offers SSO/OIDC sign-in. This can be done through fingerprinting (e.g., the "Budibase" title of the login page, response headers, or exposed authentication endpoints). The attacker also identifies a target victim — typically a user with elevated roles such as admin, creator, or builder — whose email address is registered in the Budibase instance and is also accepted as a claim by the configured IdP.

2. Triggering the flaw: At the identity provider, the attacker registers or provisions a new identity that asserts the victim's email address in the email claim without a verified status (email_verified absent, or asserted as false). This is possible with IdPs that do not enforce email verification, allow secondary/unverified email aliases, or permit profile modification after registration.

3. Exploitation of the authentication flaw: The attacker initiates the OIDC login flow. On callback, the vulnerable logic in oidc.ts resolves the email claim without checking getEmailVerified/email_verified. The account-linking logic in sso.ts then calls users.getGlobalUserByEmail as a fallback key and matches the unverified email to the victim's existing account. The attacker's fresh provider identity is merged into the victim's Budibase user record.

4. Post-exploitation impact: The attacker is now authenticated as the victim. Because account linking inherits the existing user record, the attacker gains all roles and permissions assigned to the victim, including access to the victim's applications, data sources, automation, and administrative functions where applicable. The attacker can modify low-code applications, exfiltrate data, create backdoor users, or tamper with business logic. In deployments where an account takeover would otherwise require credentials or MFA, this flaw bypasses those controls entirely.

Impact Assessment

Business impact: The vulnerability enables cross-tenant identity confusion and account takeover. The primary impact is on confidentiality and integrity: an attacker inherits the victim's data visibility and write privileges within Budibase, including any internal tools, dashboards, workflows, and connected data sources. If the victim holds an administrative role, the impact escalates to full platform compromise, including user management and application deployment controls.

Affected systems: Self-hosted Budibase instances running versions prior to 3.39.30 with OIDC SSO configured. Instances not using SSO/OIDC are not exposed to this specific attack path. The vulnerability is independent of the IdP vendor and applies to any configured provider that permits unverified email assertions.

Blast radius: Every user account whose email address is registered in the Budibase instance and can be asserted by the configured IdP is a potential target. The attack requires only low technical skill at the IdP level (registering an account with a victim-like email claim) and no interaction with the victim. A single successful takeover of a privileged account can cascade into compromise of the platform's applications and associated data.

CVSS context: No CVSS score or vector has been published, so no severity subscores are available to quantify exploitability, scope, or availability impact. Risk assessors should treat the vulnerability as high severity based on the authentication bypass / account takeover mechanism and the inherit-roles consequence, while noting the mitigations that apply (OIDC-only exposure and IdP verification policies).

Detection Guidance

Detection of this vulnerability is challenging because the malicious activity is largely indistinguishable from a legitimate OIDC login at the network layer, especially when TLS is used. The most effective detection points are application-level authentication logs (OIDC token resolution, account-linking events, email verification state) and identity-provider audit logs (provisioning of unverified identities, email attribute changes). The rules below assume that Budibase authentication events are logged with fields corresponding to the identity attributes described in the advisory; they should be adapted to the actual logging schema of each deployment.

Sigma Rule

title: Budibase OIDC Account Linking with Unverified Email (CVE-2026-73302)
id: 5c6f4f7d-2b4c-4e1a-9d3a-8f2c1b6e9a01
status: experimental
description: Detects OIDC authentication events in Budibase where an email claim without a verified status is used to link a new provider identity to an existing user account.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-73302
author: Valtersit Threat Intelligence
date: 2026/02/11
logsource:
    product: budibase
    category: application
detection:
    selection_unverified:
        email_verified: false
    selection_linked:
        event_action: sso_account_linked
        linking_key: email
    condition: selection_unverified and selection_linked
falsepositives:
    - Identity providers that legitimately omit email_verified while enforcing verification out-of-band
level: high
tags:
    - attack.t1078
    - cve.2026-73302

YARA Rule

rule CVE_2026_73302_Budibase_OIDC_Unverified_Email
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Matches Budibase backend source code patterns vulnerable to CVE-2026-73302: account linking by email without email_verified enforcement"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-73302"
        date = "2026-02-11"
        cve = "CVE-2026-73302"
    strings:
        $a = "getGlobalUserByEmail" ascii
        $b = "oidc.ts" ascii
        $c = "email_verified" ascii
    condition:
        $a and $b and not $c
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2026-73302 Budibase OIDC callback with unverified email assertion"; flow:established,to_server; content:"POST"; http.method; content:"oidc"; http.uri; nocase; content:"email"; http.client_body; nocase; pcre:"/\"email\"\s*:\s*\"[^\"]+\"/i"; pcre:"/\"email_verified\"\s*:\s*(false|null)/i"; classtype:attempted-user; sid:202673302; rev:1;)

Note: this rule assumes decrypted HTTP/JSON inspection at a reverse proxy or TLS-terminating sensor. Network-level detection without TLS interception is not viable for this OIDC flow; the rule is provided for environments where such visibility exists.

Elastic Detection

any where event.dataset == "budibase.auth"
    and event.action == "sso_account_linked"
    and idp_assertion.email_verified == false

Splunk SPL Query

index=budauth sourcetype="budibase:auth"
| rename sso.oidc.email_verified AS email_verified, sso.linked_account AS linked_account, idp.name AS idp
| where email_verified="false" OR isnull(email_verified)
| stats values(src_ip) AS src_ips, values(idp) AS idps, count AS attempts
      BY user, linked_account, _time
| sort - _time

Wazuh OSSEC Rule

<group name="budibase,authentication,cve-2026-73302,">
  <rule id="100732" level="12">
    <decoded>budibase-auth</decoded>
    <field name="email_verified">false</field>
    <field name="event_action">sso_account_linked</field>
    <description>Budibase OIDC account linking with unverified email assertion (CVE-2026-73302)</description>
    <group>authentication,account_takeover,cve_2026_73302</group>
  </rule>
</group>

Note: this Wazuh rule assumes a custom decoder (budibase-auth) that normalizes Budibase authentication log lines into the fields above.

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. The fix in version 3.39.30 is reported by a single source (OSV) and has not been independently confirmed against a vendor advisory or changelog. Verify the fix in your installation by checking the resolved version and confirming that the OIDC flow now requires getEmailVerified/email_verified before account linking.

1. Immediate mitigations:

   • Upgrade Budibase to version 3.39.30 or later as soon as possible.
   • If immediate upgrade is not possible, temporarily disable OIDC/SSO account linking or disable OIDC authentication entirely on exposed instances.
   • Enforce email-verification at the identity provider level so that unverified email assertions cannot be issued. Configure the IdP to reject or never emit accounts with unverified email claims.
   • Review and audit existing linked identities for anomalies (e.g., multiple provider identities bound to a single user record).

2. Patch / upgrade steps:

   • Confirm the currently deployed Budibase version (3.x.x).
   • Back up the Budibase database and application configuration.
   • Upgrade following the official Budibase release process for your deployment method (Docker, Kubernetes, or binary).
   • After upgrade, verify the affected files are updated: confirm the OIDC resolution in packages/backend-core/src/middleware/passport/sso/oidc.ts now enforces email verification and that packages/backend-core/src/middleware/passport/sso/sso.ts no longer blindly uses users.getGlobalUserByEmail as a fallback linking key for unverified assertions.
   • Re-run a test OIDC login with an unverified email claim to confirm the account-linking attempt is rejected.

3. Long-term hardening:

   • Treat email as a non-authoritative identity attribute. Prefer the OIDC sub (subject) claim, which is IdP-specific and immutable, as the primary account-linking key; email should only be used for display or notification purposes unless verified.
   • Enable multi-factor authentication on Budibase accounts, especially for admin and builder roles, to limit the impact of any future identity-merge flaw.
   • Monitor authentication logs continuously for anomalous SSO sign-ins, new provider identities linked to existing accounts, and unexpected privilege changes.
   • Track this CVE in your vulnerability management program and re-evaluate if the patch is independently confirmed by the vendor or if exploitation activity is reported (EPSS is currently low, but the CVE is not in CISA KEV as of this writing).

References

• NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-73302
• OSV Advisory (patch source): https://osv.dev/vulnerability/CVE-2026-73302
• Budibase Project Repository: https://github.com/Budibase/budibase
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (no entry for CVE-2026-73302 at the time of writing)
• FIRST EPSS: https://www.first.org/epss/ (CVE-2026-73302 has an EPSS score of 0.00313)

No vendor advisory URL, researcher blog, or independent patch confirmation was provided in the source data. No known threat-actor campaigns or exploit-in-the-wild evidence have been identified for this CVE.