MindsDB Minds Platform CVE-2026-73678

Exploitation requires network reachability to the MindsDB Minds Platform desktop application's HTTP API and that the two endpoints be exposed as shipped: the unauthenticated PUT /api/v1/settings/ endpoint (used to set an attacker-controlled LLM API key) and the unauthenticated POST /api/v1/responses/ endpoint (used to deliver the malicious prompt), with the Anton agent's scratchpad tool reachable and its exec() path unsandboxed - all of which are default behavior in version 26.1.0 and earlier. No authentication, credentials, or user interaction are needed (PR:N/UI:N/AC:L). The practical limiting factor is exposure of the API listener: risk is greatest when the port is bound to a non-loopback interface or the host is multi-user/shared; a strict localhost-only bind on a single-user machine narrows the remote attack surface. Platform limiter: the impact is scoped to the OS account running the desktop app, so damage depends on that user's privileges and what secrets (SSH keys, credential stores, env vars) are accessible to it.

This is a genuine top-priority issue, not a high-CVSS-but-low-risk paper cut. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N with High impact to both vulnerable and subsequent systems, VC/VI/VA:H and SC/SI/SA:H) indicates a network-reachable, low-complexity, no-privilege, no-interaction attack that fully compromises confidentiality, integrity, and availability and reaches beyond the app into the host - consistent with the description's claim of OS command execution and theft of SSH keys, stored credentials, and environment secrets. No EPSS score and no KEV entry were supplied in the input, so exploitation probability and active-exploitation status cannot be confirmed from the data; the absence of a KEV listing means it is not confirmed as actively exploited, and there is no public exploit identified at time of analysis, so any operator such as a mid-sized municipal IT team in gniezno should nonetheless treat this as urgent given how mechanically simple the two-request chain is. The main real-world limiter is exposure: risk is highest where the desktop app's API port is reachable by an attacker (LAN, shared host, or a misconfigured bind to a non-loopback interface); if it is strictly bound to localhost on a single-user workstation, the network vector is meaningfully reduced but not eliminated (browser-based/CSRF-style or local-multiuser paths remain plausible). Applying an SSVC-style read: exploitation is 'none/proof-of-concept unknown', automatable is plausibly 'yes' (unauthenticated, scriptable), and technical impact is 'total' - which argues for expedited remediation.

An attacker who can reach the desktop app's API (for example on a shared workstation, an exposed LAN interface, or a host where the port is bound beyond loopback) sends an unauthenticated PUT /api/v1/settings/ request to install their own LLM API key, then sends a single POST /api/v1/responses/ prompt instructing the Anton agent to run attacker-supplied Python via its scratchpad tool. Because exec() runs unsandboxed as the user running the application, the payload immediately executes OS commands to read SSH keys, stored credentials, and environment secrets. Given AV:N/AC:L/PR:N/UI:N, no authentication, user interaction, or race condition is required, and the two-request flow is trivially scriptable; no public exploit is identified at time of analysis.