SQLBot EUVD-2026-82561

Requires the ability to submit a multipart upload to the POST /api/v1/datasource/parseExcel endpoint (a datasource-management feature, so an authenticated account with datasource access per the vendor's PR:H), and a crafted filename that combines path components with a double extension so the write lands in /opt/sqlbot/app/alembic/versions/ as a Python source file. Critically, code execution is DEFERRED: it only occurs when SQLBot is subsequently restarted or an Alembic migration is processed, so successful exploitation depends on that operational event happening (reflected as UI:P/AC:H/AT:P). The endpoint returns an error after the write due to spreadsheet parse failure, but the planted file remains - so a failed API response does NOT mean failed exploitation. Limiting factors: authenticated/privileged access, the double-extension and path manipulation must survive processing, and a startup/migration trigger is needed. Fixed in 1.9.0, which strips path components from the filename.

This is a genuine remote-code-execution vulnerability dressed as a path-traversal (CWE-22) issue: the primitive is arbitrary file write into /opt/sqlbot/app/alembic/versions/, but the payoff is module-level Python execution when Alembic imports the planted file at the next SQLBot startup or migration. The vendor CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:H/UI:P, VC:H/VI:H/VA:H = 7.3) already tempers the raw impact with high complexity, a present attack requirement, high privileges, and passive user interaction - and those brakes are real. Exploitation is not fire-and-forget: it depends on the double-extension trick surviving parse, the write landing in the versions directory, and then a deferred trigger (restart or migration run by an operator) to actually execute. No EPSS score, no CISA KEV listing, and no public POC are present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net: a high-impact, RCE-capable flaw whose real-world urgency is moderated by authentication, complexity, and the need for a deferred execution event - a patch-promptly issue rather than a drop-everything emergency, especially given the product's limited deployment footprint.

An authenticated user with access to the datasource feature submits a crafted multipart upload to POST /api/v1/datasource/parseExcel whose filename abuses path components and a double extension, causing the backend to write attacker-controlled content into /opt/sqlbot/app/alembic/versions/ as a .py file - even though spreadsheet parsing then fails and the endpoint returns an error. The planted module persists on disk; at the next SQLBot startup or Alembic migration run, the module is imported and its top-level statements execute in the application runtime, yielding code execution. No public proof-of-concept is identified in the available data.