CVE-2026-72851

COMPONENT VERSION RANGE

NewScan fingerprints Budibase from its response and reports this CVE when the detected version falls inside the affected range below.

MEASURED 2026-08-14 against vulhub/budibase 3.31.4 (training/cve budibase-idor). The version arrives from the tech_signatures "Budibase" version_from on /api/system/status, which answers anonymously with {"health":{"passing":true},"version":"3.31.4"}; without that row these are dead data, because nothing fingerprinted Budibase at all. ONE ROW PER FIX BOUNDARY, deliberately - not one row per CVE and not one merged 'lt 3.40.0' row listing all eleven ids. Budibase shipped this batch across four release trains (3.39.18, 3.39.24, 3.39.30, 3.40.0), so a single lt-3.40.0 row would tell a 3.39.31 install it is exposed to three bugs its own version already fixed - a false claim on a specific id, which is worth more to get right than the one extra line of output an old install sees. Grouping WITHIN a boundary follows the Metabase precedent: same fix train, one finding. The 3.40.0 train, seven ids: CVE-2026-72851 (9.0) POSTs attacker JSON into an EXECUTE_QUERY automation step with NO authentication at all and is the reason this row is critical; CVE-2026-72850 (9.4) preserves traversal sequences in S3 object keys through export, giving an authenticated builder an arbitrary file write; CVE-2026-72856 (8.6) is an authentication bypass on PUT /api/global/users/tenant/owner on self-hosted instances; CVE-2026-72853 (8.8) is SQLi through unescaped table identifiers in the Oracle connector's post-write lookup; CVE-2026-72855 (8.4) is DNS-rebinding SSRF in OpenAPI import and REST query execution; CVE-2026-72857 (8.3) fails to redact MongoDB connection strings and Firebase private keys held in STRING-typed datasource fields; CVE-2026-72849 (8.7) is CSRF on the chat-link handoff that binds an attacker's chat identity to a victim account. Version-match only. Every id here is either authenticated-builder-level or reachable only by mutating somebody's application data (SQL injection into their datasource, an arbitrary file write, a tenant-owner email change), so none can be confirmed in-band without doing the damage the finding warns about.