SQLBot EUVD-2026-82564

Requires an authenticated SQLBot account (PR:L) able to create and delete Excel-type datasources through /api/v1/datasource/. Exploitation is second-order and multi-step: the attacker must first store a crafted sheet["tableName"] value during datasource creation, then trigger the DELETE path so the stored value is interpolated into cleanup SQL. Reaching OS command execution further depends on the postgres process/role having sufficient privileges to invoke COPY TO PROGRAM (a superuser or pg_execute_server_program-granted role). Limiting factors: valid credentials are needed (not unauthenticated), the two-request timing/state dependency raises attack complexity (AC:H/AT:P), and only versions prior to 1.9.0 are affected - v1.9.0 sanitizes the identifier to Chinese/alphanumeric characters only.

This is a genuine high-severity issue, but its real-world urgency is tempered by several gating factors that the raw 7.7 CVSS 4.0 score alone does not convey. The vendor vector (CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H) captures the full-impact outcome - arbitrary OS command execution as the postgres process via PostgreSQL COPY TO PROGRAM (VC:H/VI:H/VA:H) - while honestly reflecting that it is neither trivial nor unauthenticated: PR:L requires a valid authenticated SQLBot account, AC:H and AT:P reflect the multi-step, second-order nature (a malicious value must be stored during datasource creation and only detonates on a later delete, and reaching COPY TO PROGRAM depends on the postgres role having the necessary privileges). No EPSS score, no CISA KEV listing, and no public exploit code are present in the supplied intelligence, so this is 'no public exploit identified at time of analysis' - a real-but-not-yet-widely-weaponized RCE. The chief signal aligning across all sources is that the fix is confirmed: a specific commit (5d5a92a) adding identifier sanitization, a tagged v1.9.0 release, and a GitHub Security Advisory (GHSA-vxwj-843f-9c9g). Bottom line: prioritize patching for any exposed SQLBot instance because the outcome is container RCE, but the authentication requirement and second-order complexity make mass, opportunistic exploitation less likely than the CVSS number suggests.

An authenticated SQLBot user submits an Excel datasource via POST /api/v1/datasource/ containing a crafted sheet["tableName"] carrying malicious SQL rather than a safe identifier, which SQLBot stores verbatim. When that datasource is later deleted via DELETE /api/v1/datasource/{id}, the stored value is interpolated into cleanup SQL and executed by PostgreSQL, allowing the attacker to invoke COPY TO PROGRAM and run arbitrary OS commands as the postgres process inside the SQLBot container. No public exploit code is identified, but the fix commit reveals the exact sanitization gap, making reconstruction straightforward.