A low-code platform's authentication layer failed on the one path nobody budgeted a test for. Budibase's OIDC/SSO integration shipped with a fallback branch that resolves identity by matching a claimed email against pending invitations, and that branch skipped the local binding check the primary path enforced. The result: a user who should have arrived as a nameless invitee can, under the right conditions, inherit builder and admin.global roles, and with them every application, production data source, and automation in the tenant. Severity scoring landed at CVSS 9.2. Fixed in 3.45.0. Affected range: 3.41.0 through 3.44.x.
The vulnerability class is not new. What is new is how cleanly it demonstrates a pattern I have now watched recur across four separate identity products in eighteen months: trust-through-defaults. The federated layer trusts the assertion. The local layer trusts the federated layer. Nobody signs a contract at the boundary where the two meet, and that boundary is where an invitation gets claimed.
I have audited consensus scripts, liquidity pools, and NFT floor mechanics for a living, and the discipline that carries over is the same one that matters here: the failure mode is almost never in the primary path. It is in the branch the developer wrote at 2 a.m. because the happy path returned null. Budibase's primary OIDC path matched the subject claim correctly, checked email_verified correctly, and bound roles correctly. The fallback path, written to rescue invitations that arrive before the IdP subject is linked, searched by email alone. It did not check delivery channel. It did not check the invite code against the originating session. It found an invitation and it honored it.
The exploitable surface depends on one variable the public analysis has kept conspicuously vague. If the target tenant accepts only a pre-configured trusted IdP, the attacker must first compromise an account inside that IdP, or find an IdP that will assert an unverified email address on command. That is a real precondition, and it is heavier than the CVSS vector suggests. If the target tenant permits self-registration against arbitrary IdPs, the precondition evaporates and the score of 9.2 reads as generous rather than alarmist.
Here is the part most coverage has missed. The CVSS 4.0 vector includes AT:P, Attack Requirements Present. Commentators have read that as a technical hurdle. It is not. In any enterprise that uses invitations at all, a pending invitation is the normal state of the world — onboarding cohorts, contractor provisioning, batch department rollouts. The AT parameter does not raise the bar. It might actually understate the exposure, because it treats a permanent operational condition as an episodic one.
Now the public proof of concept from SOCRadar. Experts have noted, correctly, that this shifts the exploit from theoretical to scripted. I want to be more precise about what that means and why it matters for anyone holding Budibase in their stack. Before the PoC, the exploit required an attacker who could reason about OIDC flows and craft a token with the right claims. After the PoC, it requires an attacker who can read a blog post and run a script. The relevant recruitment pool just expanded from a few thousand specialists to an untold number of opportunists. That is the entire value of a public PoC, and it is why vendors should plan disclosure timing as a security control, not a PR calendar item.
The remediation in 3.45.0 adds invitation-code verification to the fallback path. That is a point fix, not a paradigm correction. Whether it actually closes the door depends on three properties the release notes do not address: is the invitation code high-entropy, is it non-enumerable, and is it bound to the originating session or delivery channel? If the answer to any of those is no, the fallback path still resolves identity by something an attacker can acquire. I would read the advisory carefully before declaring the class closed.
The larger problem is architectural. Budibase's security review appears to have proceeded feature by feature rather than flow by flow. The primary path got audited. The fallback path got built. The
The federated identity industry has a structural debt problem, and it is not Budibase's alone. The same default-trust failure has surfaced in Keycloak, in Better Auth, and in Frontegg within recent cycles. If the pattern recurs across four products, it is a design pattern, not a series of coincidences. The pattern is this: federated systems are built to trust the assertion because trusting the assertion is the whole point of federation. Then the local system is asked to bind that trust to a specific invitation, a specific tenant, a specific role — and that binding requires a second validation step the architecture was never designed to enforce. So developers add it where they remember to, which is where the happy path runs.
The commercial exposure is sharper because of what SSO actually represents. SSO is not a technical feature that enterprise customers buy. SSO is the compliance checkbox that justifies the enterprise contract. It is the thing that gets a platform through a security questionnaire from a financial services procurement team. When the feature customers pay for is the feature that breaks, you are not selling a product with a vulnerability — you are selling a broken promise at a premium.
The low-code market amplifies the blast radius in a way that deserves more attention than it has gotten. On a normal SaaS platform, an authentication bypass means one tenant's data is exposed. On a low-code platform, authentication bypass means every application, every connected production database, and every automation workflow the tenant has built. The platform's entire value proposition — let non-engineers connect production systems without an engineering team in the middle — is precisely what makes the blast radius catastrophic. The same design choice that makes low-code valuable makes low-code dangerous when the authentication layer fails.
There is a second-order consequence that most enterprise customers will not register until it bites them. Budibase's self-hosted version carries the same defect. Self-hosted instances are the long tail of every open-source security event: the ones running 3.41.x that nobody patched, whose operators read release notes once a quarter, and behind which sits production data. The open-source distribution model is one of the most efficient bug-fixing systems humanity has invented and simultaneously one of the most efficient bug-persisting systems, because the fix travels only as fast as the operator's attention.
Budibase has correctly responded by shipping a patch. That is the minimum. The maximum would be treating this as the tell it is, and commissioning a flow-by-flow review of every federated entry point in the product. Invitation acceptance is one. There will be others: SCIM provisioning, SAML assertion handling, API key mints, service account elevation. Each one is a joint where the assertion meets the permission, and each one deserves a test that was almost certainly never written.
Watch three things this quarter. First, whether Budibase publishes a customer advisory with indicators of compromise and a detection guide for self-hosted operators. Second, whether CISA lists this in KEV — the article correctly notes it is not there yet, which means no confirmed exploitation in the wild, but that status can flip in a day, and a KEV listing would force a patch cycle across US federal contractors and cascade globally through supplier risk reviews. Third, whether the next federated identity disclosure follows the same shape. I think it will. The pattern is too structurally sound to be a fluke.
Structure is not a cage; it is a launchpad. It is also, when you leave the joins untested, a door left unlocked in the back of the building.
What if the next authentication bypass is not in the product you audited, but in the fallback branch of a product you never heard of?