A pending invitation is a normal state in enterprise software. New hire onboarding. Batch provisioning. A contractor waiting for approval on a Tuesday morning. Nobody counts these as live attack surface. That assumption is the vulnerability.
On-chain reasoning teaches one hard rule: the interesting signal is never in the main path. It is in the fallback. When Budibase shipped version 3.45.0 to close an OIDC/SSO authentication bypass rated 9.2, the patch told us more than the disclosure did. The fix landed on the fallback branch of sso.authenticate(). That means the primary path — matching an identity provider subject to a local account — was designed carefully. The edge case was not.
Here is the mechanics. Budibase federates identity through OIDC, mapping an external IdP subject to a local user record keyed on email. When the subject match fails, the code falls back to searching for a pending invitation by the email address in the IdP assertion. If an invitation exists for that address, the account gets claimed. The role attached to that invitation — builder, or in some configurations admin.global — attaches with it.
The missing check is the one that matters. email_verified is enforced when looking up existing accounts. It is not enforced on the invitation-claim path. So an attacker who can present an assertion for an unverified email matching a pending invite walks into the tenant. From there, the blast radius is not a single application. Builder-level access in a low-code platform means every app, every production data source connection, every automation flow. That is the structural difference between low-code and ordinary SaaS: one permission escalation exposes not just data, but the business logic that governs it.
I have audited authentication flows where the security review was performed feature-by-feature rather than flow-by-flow. It produces exactly this signature. Someone reviewed the login path. Someone reviewed the invite acceptance screen. Nobody reviewed the intersection, because the intersection is not a screen. It is a conditional branch. Security controls implemented per-function-point rather than end-to-end cannot detect the seam between two correctly written functions.
The CVSS 4.0 vector carries an AT:P — Attack Requirements Present. Read the vendor's framing and you might conclude this limits severity. Read the operational reality and you reach the opposite conclusion. In any enterprise tenant with active onboarding, a pending invitation is not a rare precondition. It is the default state. The attack requirement is not an obstacle; it is the normal operating condition of the customer base. If anything, the vector understates exposure.
The most important gap in the disclosure is one the report never resolves: whether the target environment trusts only an administrator-configured IdP, or accepts any self-registered provider. If the latter, the barrier is effectively zero and 9.2 is conservative. If the former, an attacker must first compromise an account inside a trusted IdP, or exploit that provider's willingness to assert unverified addresses. That distinction changes the threat model entirely, and its absence from the writeup is the single largest analytical blind spot.
The fix itself deserves scrutiny. Version 3.45.0 adds invitation code validation to the fallback path. Correct direction. But three questions go unanswered: does the invitation code carry sufficient entropy, can it be enumerated, and is it bound to the session that initiated the claim? A validation step built on a predictable token is not a fix. It is a speed bump with documentation.
What makes this case worth more than one incident is the pattern. The researcher places Budibase alongside Keycloak, Better Auth, and Frontegg under a single label — trust-through-defaults. Four independent identity products, one shared failure mode: the federation layer implicitly trusts the IdP's assertion and never re-validates the local binding at the moment privileges are granted. That is not a Budibase bug. That is an industry-grade architecture debt in how federated identity gets implemented, and it is almost certainly still latent in products nobody has probed yet.
I trust the code, not the community. That principle cuts both ways here. The technical narrative is internally consistent and engineering-credible — specific function names, specific fallback logic, specific version boundaries from 3.41.0 through 3.44.x. The provenance is not. The report arrives from a Web3-flavored source covering an enterprise low-code platform. The CVE identifiers are inconsistent in digit count — six digits in one reference, five in another. No NVD entry, no GitHub Security Advisory, no vendor bulletin anchors the core facts. CISA KEV does not list it.
I separate these conclusions deliberately. The architecture insight holds regardless of whether the identifier survives verification. The claim of live exploitation does not. Anyone making remediation decisions off this disclosure should verify against NVD and the vendor's own advisory before touching a deployment calendar.
Yield is often the interest paid on risk you did not price. Vendors sell SSO as the compliance checkbox, the enterprise upsell, the thing that closes deals with banks and hospitals. The customers paying the premium are precisely the ones whose tolerance for a bypassed access control is zero. The revenue lever and the risk lever are the same lever.
Silence is the most expensive asset in a bubble, and the quietest debt in this market is the assumption that federation equals verification. It never did. The next disclosure in this family is already written. The only open question is whether it surfaces through a coordinated advisory or through a pending invitation nobody thought to audit.