OpenChatBI EUVD-2026-69063

Exploitation requires a valid authenticated session on the OpenChatBI instance (PR:L per CVSS 4.0), so the attacker must hold or obtain user credentials. The vulnerable code path is exclusively invoked through the text2sql feature - the natural language to SQL conversion pipeline - so that feature must be active and accessible to the attacker's account. On v0.3.0 and v1.0.0b1, enabling the optional stricter validation mode may block exploitation; the flaw is reliably exploitable only when this mode is absent or disabled, which is its default state. No special network position, elevated privilege, or user interaction beyond authentication is required. Exploitation is bounded to the database objects accessible under the application's configured database credentials.

The CVSS 4.0 score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N) represents moderate real-world risk: network-exploitable at low complexity but gated behind authenticated access (PR:L), which meaningfully limits the threat surface. Impact is uniformly Low across confidentiality, integrity, and availability with no subsequent-system scope change, consistent with a SQL injection bounded to the application's own data store. No EPSS data was provided in the input, and the absence of both a CISA KEV listing and public POC code suggests limited active exploitation interest - likely compounded by the product's narrow deployment footprint. The disclosure timeline is an aggravating factor: vendor non-response means the only available mitigation (the optional strict mode in v1.0.0b1) is unreleased as a security advisory and may be missed by operators. Risk is materially higher for deployments running v0.2.0-v0.2.2, where no validation exists at all, versus v0.3.0+ where partial mitigation is in place.

An authenticated user submits a crafted natural language prompt engineered to produce SQL containing injection payloads; the _validate_sql_safety function fails to detect or block the malicious clause, and the constructed query executes against the backend database with attacker-controlled logic. On versions 0.2.0-0.2.2, even trivially malformed inputs bypass any safety gate because no validation code exists. No public proof-of-concept has been identified, but the low attack complexity (AC:L, CWE-89) makes independent exploitation straightforward for any attacker holding a valid account.