MySQL Shell EUVD-2026-37343

The attacker must (1) have network HTTP reachability to a workstation running MySQL Shell 2026.2.0+9.6.1 with the Shell for VS Code component active, and (2) possess low-level privileges (PR:L) - typically a valid but unprivileged account or session recognized by the Shell or its host. No user interaction is required (UI:N) and attack complexity is low (AC:L). Practical limiting factors: the affected surface is a developer-side VS Code extension rather than a server daemon, so exposure depends on whether the extension's HTTP listener is bound beyond loopback, whether multiple users share the host, and whether the workstation is reachable from untrusted network segments; environments that keep MySQL Shell on isolated developer laptops behind a host firewall materially reduce real-world reachability.

All raw signals point to high priority: CVSS 3.1 base 9.9 with AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H means network-reachable, low complexity, only low privileges required, no user interaction, and complete CIA impact with scope change. EPSS exploitation probability and KEV status were not provided in the input, so widespread mass exploitation cannot be confirmed yet, and no public exploit identified at time of analysis. The tension worth flagging is that the description labels this 'easily exploitable' over HTTP, yet 'MySQL Shell for VS Code' is typically a developer-side IDE extension rather than an internet-exposed service - so 'network access via HTTP' may in practice mean LAN- or localhost-scoped HTTP traffic to the extension's listener. Treat as a high priority for any environment where developers run the affected MySQL Shell VS Code build on shared or multi-tenant hosts.

An attacker who already holds a low-privileged account or session on the same network as a developer running the affected MySQL Shell for VS Code build sends crafted HTTP requests to the extension's listener, abuses the flaw to take over the Shell session, and then leverages the Shell's existing authenticated connection to pivot into MySQL servers - reading sensitive data, altering schemas, or disrupting service. No public exploit identified at time of analysis, but Oracle explicitly labels the issue 'easily exploitable', so weaponization effort is expected to be low once technical details circulate.