SQLBot EUVD-2026-30182

The attacker must hold a valid authenticated SQLBot account in any workspace (CVSS PR:L) and must be able to reach the SQLBot HTTP API over the network; no user interaction or non-default configuration is required, but the deployment must be multi-tenant for the cross-workspace bypass to yield a privilege gain - in a single-workspace install the same bug grants no additional access. Exploitation is limited to instances running SQLBot prior to 1.8.0, and the attacker must know or enumerate the numeric/identifier values of victim-tenant data sources used by the /api/v1/datasource/exportDsSchema and /api/v1/datasource/uploadDsSchema endpoints. No platform-specific (OS, architecture) prerequisites apply.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) yields 8.6 High: network-reachable, low complexity, requires only low privileges (any valid tenant user), and produces high confidentiality and integrity impact with no availability impact and no scope/subsequent-system change. SSVC corroborates this - Exploitation: poc, Automatable: no, Technical Impact: total - meaning a working exploit path is demonstrable but mass automated abuse is unlikely because the attacker must first hold a tenant account. EPSS is very low at 0.04% (12th percentile) and the CVE is not on CISA KEV, so widespread opportunistic exploitation is not currently expected; however, EPSS reflects observed exploitation telemetry, not severity, and an IDOR like this is trivially weaponizable by any malicious tenant in a shared-SaaS deployment. Prioritize this if SQLBot is run multi-tenant; risk is materially lower for single-tenant on-prem installs where only one workspace exists.

An attacker registers or compromises a low-privilege account in any tenant of a shared SQLBot deployment, then enumerates data source identifiers belonging to other workspaces and calls /api/v1/datasource/exportDsSchema with those IDs to exfiltrate the target tenant's database schema (table names, columns, and likely connection metadata). The attacker then calls /api/v1/datasource/uploadDsSchema to overwrite the victim tenant's schema definitions, poisoning the Text-to-SQL/RAG pipeline so that subsequent natural-language queries by victim users return manipulated or attacker-chosen SQL. No public exploit code is identified at time of analysis, but SSVC marks a PoC as existing.