CVE-2026-27702: When the View Builder Handed Your Filters Straight to `eval()`

---

Budibase's cloud tenants let any logged-in user — free tier included — turn a "filtered view" into server-side JavaScript execution, because a stored map function built from user-controlled filter fields was concatenated into a string and fed to eval(). CVSS 9.9, and the fix needed three independent patches because no single layer was trustworthy.

The advisory in plain English

Budibase is a low-code internal-tools platform. One of its features lets you define a "view" over a table: pick a field, add some filters (key EQUALS value, key CONTAINS value, and so on), maybe a calculation. Self-hosted deployments compile those filters into a native CouchDB design-document view and let CouchDB run them — sandboxed, fine. Cloud is different. On Budibase Cloud the same view is executed against an in-memory PouchDB, and the map function is run by the Node.js app-service process itself.

The advisory (GHSA-rvhr-26g4-p2r8) describes the impact bluntly: the app-service pod carries INTERNAL_API_KEY, JWT_SECRET, CouchDB admin credentials, and AWS keys in its environment. Arbitrary JS in that process reads all of them. The reporters confirmed they could pull CouchDB admin creds out of process.env, connect directly, and enumerate every tenant database. That is about as bad as a multi-tenant SaaS bug gets, and the entry ticket is a free account.

The flawed function

The sink is tiny. Here is the pre-fix runView, the function that executes a view on the cloud path — packages/server/src/db/inMemoryView.ts @ bfe68d6b, L29:

let fn = (doc: Document, emit: any) => emit(doc._id)
// BUDI-7060 -> indirect eval call appears to cause issues in cloud
eval("fn = " + view?.map?.replace("function (doc)", "function (doc, emit)"))

view.map is a string. It's a JavaScript function body, stored in the view document, and here it is concatenated onto "fn = " and run through eval. The comment is the tell: someone hit a problem with indirect eval ("BUDI-7060") and "fixed" it by switching to a direct eval — preserving the exact behavior that makes direct eval dangerous, namely that it runs in the enclosing scope with full access to the module's imports and process.

The call site confirms this only fires on cloud — packages/server/src/sdk/workspace/rows/search/internal/internal.ts @ bfe68d6b:

if (env.SELF_HOSTED) {
  response = await db.query(`database/${viewName}`, { ... })   // native CouchDB
} else {
  const data = await fetchRaw(tableId!)
  response = await inMemoryViews.runView(viewInfo, ...)         // eval path
}

So far this looks survivable: surely a user can't just set view.map to arbitrary JS? They can't set it directly — but they don't need to.

Why the check was insufficient

The stored map string isn't typed by the user. It's generated by the view builder from the filters the user submits. The temptation is to call that "trusted." It wasn't, because the builder built JavaScript by string interpolation, with the user's filter key and value dropped straight into the source.

From the pre-fix builder — packages/server/src/api/controllers/view/viewBuilder.ts @ bfe68d6b, L96, L104, L107, L184:

`doc["${filter.key}"].${TOKEN_MAP[filter.condition]}("${filter.value}")`
// ...
typeof filter.value == "string" ? `"${filter.value}"` : filter.value
// ...
`doc["${filter.key}"] ${TOKEN_MAP[filter.condition]} ${value}`
// ...
const tableExpression = `doc.tableId === "${tableId}"`

Every one of those backtick templates embeds an attacker-controlled string inside a JavaScript string literal with hand-rolled " quoting. The escaping is: none. A filter.value containing a double-quote closes the literal early; a filter.key containing "] escapes the property access. Whatever follows is parsed as code. The view-save controller runs the submitted body straight through this builder — packages/server/src/api/controllers/view/views.ts @ bfe68d6b:

const view = viewTemplate(viewToSave, groupByField?.type === FieldType.ARRAY)
await saveView(originalName, viewName, view)

So the chain is: user submits a filter → builder interpolates the filter's key/value into the map source with no escaping → the malformed-but-syntactically-valid map is persisted → on the next cloud view query, runView evals it. Stored code injection (CWE-94) feeding an eval sink (CWE-95). The "trusted generator" was a confused deputy: it faithfully assembled the attacker's characters into a function and signed off on it.

The regression test the maintainers added makes the breakout explicit — packages/server/src/api/controllers/view/tests/viewBuilder.spec.ts @ 2a7871d7:

const payload = `x" ); globalThis.pwned = true; ("`
const key = `Name"] ; globalThis.pwned = true; //`

That's the proof-of-concept shape, and it's why I'd call this exploitable rather than theoretical: there's a concrete, low-privilege path from a filter field to globalThis.pwned = true. I'm describing the defect, not handing you a working view payload — the lesson is in the data flow, not the bytes.

What the fix changed

Pull request #18087 (merged as 348659810) doesn't trust any single layer. It patches three:

1. Rebuild from metadata, don't eval the stored string. Post-fix runView ignores the persisted view.map and regenerates it from view.meta — inMemoryView.ts @ 531296eb:

// Rebuild map/reduce from metadata to avoid executing untrusted map strings.
const rebuiltView = viewBuilder(view.meta as any)
let fn = (doc: Document, emit: any) => emit(doc._id)
eval("fn = " + rebuiltView?.map?.replace(...))

Note the eval is still there. The maintainers were honest about the constraint: PouchDB's map/reduce wants a real function. So they didn't pretend to remove the sink — they made sure the only thing reaching it is freshly built by the (now-hardened) builder, never the attacker-influenced stored string.

2. Harden the builder so "freshly built" actually means safe. The interpolation was replaced with JSON.stringify, which produces a correctly escaped JS literal, plus a tokenOrThrow allowlist for operators — viewBuilder.ts @ 531296eb:

function docKeyExpression(key: string) {
  return `doc[${JSON.stringify(key)}]`
}
function tokenOrThrow(type, token) {
  const mappedToken = token ? TOKEN_MAP[token] : undefined
  if (!mappedToken) throw new Error(`Invalid filter ${type}: ${token}`)
  return mappedToken
}

JSON.stringify is the right tool: it's the standard library's serializer for exactly this — turning an arbitrary string into a valid, escaped string literal. The condition and conjunction tokens are no longer looked up loosely (TOKEN_MAP[filter.condition] could return undefined and splice a blank into the source); they must map to a known operator or the build throws.

3. Remove the legacy attack surface on cloud entirely. The v1 view routes were unused on cloud "in months," so the patch gates them behind env.SELF_HOSTED — packages/server/src/api/routes/view.ts @ 2a7871d7:

if (env.SELF_HOSTED) {
  builderRoutes
    .post("/api/views", viewController.v1.save)
    // ...legacy view routes only registered when self-hosted
}

Defense in depth, top to bottom: don't expose the endpoint, don't generate unsafe code, don't trust stored code.

The lesson

A few things worth carrying out of this one.

eval of generated code is still eval. The defenders' instinct — "the user doesn't control the string, our builder does" — was the whole vulnerability. A code generator is a trust boundary, and if any byte of attacker input flows into its output without escaping, the generator is laundering injection, not preventing it.

Direct vs. indirect eval is a real distinction, but it wouldn't have saved the credentials. That BUDI-7060 note rationalized switching to direct eval because indirect eval "caused issues in cloud." Direct eval runs in local scope with reach into the module's imports — but be precise about what that actually bought the attacker. process is a Node.js global, reachable from global scope too, so indirect eval and new Function(...) would still read process.env and steal the same CouchDB creds and JWT secret. The direct/indirect distinction only protects the module-local imports, not the environment secrets. If a function-from-string is truly unavoidable, the only real containment is a sandbox — isolated-vm, or Node's built-in vm with its documented escape caveats; new Function(...) is not a sandbox, it just drops closure access. Better still, don't run the string at all — and keep the secrets out of the process to begin with (the next point).

Escape with a serializer, not with quotes. Every pre-fix template did "${value}". The fix did JSON.stringify(value). Hand-rolled quoting is the canonical place injection lives; the standard library already solved string-literal escaping correctly.

Multi-tenant blast radius is set by what's in the environment. The reason a filtered-view bug rates 9.9 is that the pod ran with CouchDB admin creds and a JWT secret sitting in process.env. Arbitrary in-process JS is total compromise when your secrets share the process. Least-privilege for runtime secrets — scoped tokens, a broker, anything but plaintext in the env of a process that interprets user input — would have shrunk this from "tenant-wide breach" to "annoying RCE."

References

• Advisory: https://github.com/Budibase/budibase/security/advisories/GHSA-rvhr-26g4-p2r8
• Fix merge commit: https://github.com/Budibase/budibase/commit/348659810cf930dda5f669e782706594c547115d
• Pull request #18087: https://github.com/Budibase/budibase/pull/18087
• Release 3.30.4: https://github.com/Budibase/budibase/releases/tag/3.30.4
• Pre-fix sink (eval): https://github.com/Budibase/budibase/blob/bfe68d6b7537be9292ffb8afe9a175ae17a8a5d8/packages/server/src/db/inMemoryView.ts#L29
• Pre-fix builder (unescaped interpolation): https://github.com/Budibase/budibase/blob/bfe68d6b7537be9292ffb8afe9a175ae17a8a5d8/packages/server/src/api/controllers/view/viewBuilder.ts#L96
• Post-fix builder + sink commit: https://github.com/Budibase/budibase/commit/531296eb33993e2210b723b412298884dfdde8d3
• Route gating + regression test: https://github.com/Budibase/budibase/blob/2a7871d71d1d1b7946512f097df5f7cc891c1528/packages/server/src/api/controllers/view/tests/viewBuilder.spec.ts