Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Authenticated users with automation permissions can bypass Budibase's SSRF blacklist through DNS rebinding. The outbound fetch flow validates a hostname against the blacklist before the request is sent, but the actual socket connection later performs a separate DNS lookup through node-fetch. Since the validated IPs are never pinned to the connection, an attacker-controlled hostname can return a public IP during validation and a private/internal IP during the real connection. This results in a non-blind SSRF primitive against internal services reachable from the Budibase host, including loopback, RFC1918 ranges, and cloud metadata endpoints. Details The issue comes from the outbound fetch validation flow resolving DNS twice: During blacklist validation Again during the real socket connection The first lookup result is discarded after validation, so the second lookup is free to resolve to a different IP. This creates a classic TOCTOU DNS rebinding issue. Affected flow in:…
Recommended action: Upgrade to 3.39.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The buildMatcherRegex() / matches() functions in packages/backend-core/src/middleware/matchers.ts share the same structural root cause as the recently patched CVE-2026-31816: route patterns are compiled into unanchored regular expressions and tested against ctx.request.url, which includes the full query string. The CSRF middleware in the Budibase Worker uses this matching system to decide whether to skip CSRF token validation. An unauthenticated attacker can forge state-changing cross-origin requests against any Worker API endpoint by injecting a public route pattern into the query string, causing the CSRF middleware to skip token validation entirely. This allows actions such as sending admin invites, modifying global configuration, and managing users without a valid CSRF token. CVE-2026-31816 fixed the same unanchored-regex-on-full-URL bug in server/middleware/utils.ts but left backend-core/middleware/matchers.ts untouched. --- Details Root cause —…
Recommended action: Upgrade to 3.35.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The public API role unassignment endpoint (POST /api/public/v1/roles/unassign) updates user documents in CouchDB but does not invalidate the corresponding Redis user cache entries. Because the authentication middleware resolves user identity and permissions from this cache (TTL: 3600 seconds), a user whose admin, builder, or app-level roles have been revoked via the public API retains those privileges for up to 1 hour. Details The root cause is an inconsistency between the UserDB.save() and UserDB.bulkUpdate() code paths. Vulnerable path — packages/pro/src/sdk/publicApi/roles.ts:49-75: bulkUpdate delegates to bulkUpdateGlobalUsers() at packages/backend-core/src/users/users.ts:82-85: This writes directly to CouchDB with no cache invalidation. Correct path — packages/backend-core/src/users/db.ts:355 (used by admin UI): Cache configuration — packages/backend-core/src/cache/user.ts:11: Authentication middleware — packages/backend-core/src/middleware/authenticated.ts:153-160:…
Recommended action: Upgrade to 3.38.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 3.35.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1. Summary | Field | Value | |-------|-------| | Title | SSRF via REST Connector with Empty Default Blacklist Leading to Full Internal Data Exfiltration | | Product | Budibase | | Version | 3.30.6 (latest stable as of 2026-02-25) | | Component | REST Datasource Integration + Backend-Core Blacklist Module | | Severity | Critical | | Attack Vector | Network | | Privileges Required | Low (Builder role, or QUERY WRITE for execution of pre-existing queries) | | User Interaction | None | | Affected Deployments | All self-hosted instances without explicit BLACKLISTIPS configuration (believed to be the vast majority) | --- 2. Description A critical Server-Side Request Forgery (SSRF) vulnerability exists in Budibase's REST datasource connector. The platform's SSRF protection mechanism (IP blacklist) is rendered completely ineffective because the BLACKLISTIPS environment variable is not set by default in any of the official deployment configurations. When this variable is empty, the blacklist…
Recommended action: Upgrade to 3.33.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.