CVE-2026-42239  ·  Security  ·  Authentication  ·  HIGH 8.1

A Hidden Flaw in a Popular App-Builder Could Hand Hackers the Keys to Your Account

No active exploitation confirmed  ·  Patch available: version 3.35.10

If someone can inject a single malicious script into a Budibase application — even a fleeting one — they can walk away with your login credentials and own your account indefinitely, without ever knowing your password.

Who Is at Risk — and Why It Matters

Budibase is an open-source, low-code platform used by developers, startups, and enterprise teams to build internal tools — dashboards, admin panels, approval workflows — quickly and without heavy coding. It has tens of thousands of self-hosted installations and is popular in organizations where non-developers need to spin up business applications fast. If your team uses Budibase to manage anything sensitive — customer records, HR data, finance approvals — your accounts are the target here.

The vulnerability affects every version of Budibase prior to 3.35.10. That's a wide window. Organizations running self-hosted instances who haven't kept up with updates are particularly exposed, because there's no cloud-side fix coming for them automatically.

What's Actually Happening — In Plain English

When you log into Budibase, the server hands your browser a small digital badge called a session token. Think of it like a wristband at a concert venue — show it at the door and you're in, no questions asked. Normally, the server instructs your browser to guard this wristband carefully: keep it hidden from any code running on the page, and only send it over encrypted connections. These are standard, well-understood safety rules that have existed for years.

Budibase wasn't following those rules. The wristband — a cookie named budibase:auth — was being handed out with none of the usual protections. Any JavaScript running on the page could simply reach in and read it. That might sound like a narrow problem, but it has an enormous practical consequence: the moment an attacker finds any way to sneak a small script into a Budibase page — a crafty link, an unsanitized form field, a rogue widget — they can silently copy your login token and transmit it to themselves. From that point on, they are you. They can log in from anywhere in the world, read your data, modify records, and create new accounts — all without triggering a password-change alert, because they never touched your password.

The problem is compounded by two additional oversights: the cookie was also being sent over unencrypted connections (plain HTTP rather than HTTPS), meaning anyone watching traffic on the same network — a coffee shop, a corporate Wi-Fi — could intercept the token without needing any scripting attack at all. And because no same-site restriction was set, certain cross-site request tricks could also abuse the cookie in unexpected ways. Three missing lines of configuration. Three different roads to the same destination: account takeover.

The Technical Anchor

For researchers: this is a particularly clean escalation path. An attacker exploiting any reflected or stored XSS in a Budibase application — regardless of how low-severity that XSS might appear in isolation — can immediately escalate to full persistent account takeover by extracting the JWT and replaying it. No CSRF tokens to bypass, no additional gadgets needed. The misconfiguration effectively turns every low-severity XSS finding in any Budibase deployment into a critical-severity finding.

Discovery, Exploitation Status, and Known Victims

As of publication, there is no confirmed active exploitation of CVE-2026-42239 in the wild. The issue was reported through responsible disclosure and patched by the Budibase team in version 3.35.10. The Budibase maintainers deserve credit for moving to a patch — this is exactly how the disclosure process is supposed to work.

That said, security teams should treat "no confirmed exploitation" as a countdown clock, not a clearance. The vulnerability class is well understood, the path from discovery to exploit is short, and Budibase's self-hosted deployment model means many organizations won't update for weeks or months. Proof-of-concept code for this class of flaw is trivial to construct once the misconfiguration is public. The window between "published" and "weaponized" is shrinking industry-wide.

No specific threat actor campaigns or victim organizations have been named at this time.

What To Do Right Now

Whether you're an IT administrator, a developer, or a business owner who uses Budibase, here are three concrete steps in order of priority:

1. Update Budibase to version 3.35.10 or later — today. This is the only complete fix. If you're self-hosting via Docker, pull the latest image: budibase/budibase:3.35.10. If you're on Budibase Cloud, the patch has been applied server-side. Verify your version at Settings → About inside your Budibase instance before doing anything else.
2. Force HTTPS across your entire Budibase deployment. Even before patching, ensure your instance is only reachable over TLS (HTTPS). If you're running Budibase behind a reverse proxy like Nginx or Caddy, confirm that HTTP traffic is being redirected to HTTPS — not just allowed through. This blocks the plaintext interception vector immediately. If users can reach your instance over plain http://, fix that at the proxy layer now.
3. Audit your Budibase apps for existing cross-site scripting risks. After patching, conduct a quick review of any user-generated content fields, URL parameters that get displayed back to users, and any third-party widgets or embedded content in your Budibase apps. Tools like OWASP ZAP (free) can help with automated scanning. Remember: the cookie fix removes the worst amplifier, but underlying XSS in your app logic is still worth finding and removing independently.

CVE-2026-42239 | CVSS 8.1 HIGH | Patched in Budibase 3.35.10 | No active exploitation confirmed at time of publication.