DataEase SQLBot CVE-2026-93660

Requires an authenticated account that is a member of a SQLBot workspace (PR:L) reachable over the network; the attacker then supplies arbitrary dashboard IDs to the update_resource and update_canvas endpoints, which fail to verify that the requesting user owns (create_by matches) the target dashboard. No user interaction, no admin privileges, and no non-default configuration are needed. Limiting factors: exploitation is confined to the multi-tenant workspace model - an attacker must already possess valid workspace credentials, and impact is limited to integrity (modifying/renaming other members' private dashboards) with no confirmed confidentiality or availability effect. Affected in all versions through 1.10.1; upgrade to the patched build containing the ownership checks.

This is a genuine but moderate-severity broken-access-control (IDOR) flaw, not a high-impact critical. The vendor CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) correctly captures a network-reachable, low-complexity issue that requires an authenticated workspace member (PR:L) and affects integrity only (VI:H), with no confidentiality or availability impact - consistent with CWE-639 (Authorization Bypass Through User-Controlled Key). My independent CVSS 3.1 mapping yields ~6.5 (I:H, C:N, A:N). No EPSS score, no CISA KEV listing, and no explicit proof-of-concept exploit code are present in the provided intelligence; the only exploitation signal is the public patch commit and a filed GitHub issue (#1377), so exploitation status is 'no public exploit identified at time of analysis.' The requirement for valid authenticated access to a shared workspace substantially limits real-world risk versus an unauthenticated flaw - this is an insider/multi-tenant integrity concern rather than an internet-wide priority. Note the VC:N/C:N rating covers the update endpoints, though the patch also hardened load_resource with an ownership check, hinting the same missing-check pattern could enable cross-user reads; treat any confidentiality claim as unverified. Priority should be elevated only for deployments where SQLBot workspaces contain mutually-distrusting members.

An attacker holds a legitimate low-privilege account in a shared SQLBot workspace and enumerates or guesses dashboard IDs belonging to other members. They send crafted requests to the update_resource and update_canvas endpoints supplying a victim's dashboard ID, overwriting component data, canvas styles, view information, or renaming the dashboard. No public exploit code is identified, but the fix commit and issue #1377 disclose the exact vulnerable endpoints, making weaponization straightforward for an authenticated user.