Localhost Is Not an Auth Boundary: The Agent Endpoint That Turned a Web Page Into RCE

Aug 16, 2026 7 min read

A browser tab should not be able to turn a desktop AI agent into a shell. In CVE-2026-73678, that boundary collapsed: MindsDB Minds Platform exposed an agent response endpoint without authentication, accepted cross-origin traffic, and passed attacker-directed work into a Python scratchpad that executes generated code with exec(). VulnCheck scored the chain 10.0 Critical under both CVSS 4.0 and 3.1; NVD received the record on August 14, 2026.

The surprising part is not that exec() can execute code. That is its job. The failure is architectural: a component explicitly built to turn model output into computation was placed behind an HTTP interface that did not establish who was calling, where the request came from, or whether the caller was allowed to spend that capability. The model was asked to cross the final centimetre. The control plane had already removed every metre of defence before it.

Four permissive choices became one unauthenticated shell

The project security advisory describes the vulnerable path in Minds Platform 26.1.0 and earlier. A caller that can reach the Cowork server can:

send settings through the unauthenticated /api/v1/settings/ API, including the attacker’s own OpenAI or Gemini key;
submit a crafted prompt to unauthenticated POST /api/v1/responses/;
induce the Anton agent to use its scratchpad;
reach exec(compiled, namespace) inside the scratchpad process and run with the operating-system privileges of the server user.

The attacker’s ability to supply the model credential matters. A missing victim key does not disable the dangerous execution path; it only externalizes the inference bill. The advisory’s prerequisite is simply a running Minds Platform instance and an attacker-controlled provider key. That turns “the user has not configured the app yet” from a safety state into an attacker-solvable setup step.

The code pinned by the MindsHub superproject makes the trust gap concrete. The Cowork server application installs CORSMiddleware with allow_origins=["*"], all methods and all headers, then includes the API router. The responses handler declares @router.post("/") with a database-session dependency but no authentication dependency. The pinned Anton scratchpad bootstrap compiles each received cell and calls exec(compiled, namespace).

untrusted caller
  -> permissive browser/API ingress
    -> no caller identity or authorization
      -> prompt-driven tool selection
        -> Python scratchpad
          -> exec() as the desktop/server user

Each choice is explainable in isolation. Wide CORS is convenient during local development. An OpenAI-compatible response endpoint is useful for integration. A user-supplied API key supports bring-your-own-model deployments. A Python scratchpad makes an agent capable. The CVE exists in the composition: convenience at ingress was connected directly to authority at execution.

”It only listens locally” is not an authentication policy

The vendor advisory goes beyond network peers. It says a malicious web page can target the service at 127.0.0.1:26866 because the API accepts cross-origin requests. The browser runs on the victim’s machine, so from the service’s perspective the request arrives at localhost even though the attacker’s code came from a remote site.

This distinction is easy to miss in agent products. A loopback bind reduces who can open a raw TCP connection from the network. It does not prove which local process initiated a request, and it does not stop a browser from acting as a deputy for remote JavaScript when the service opts into permissive cross-origin access. Local reachability is a routing fact, not an identity claim.

There is a standards wrinkle worth stating precisely. Browsers do not permit the Access-Control-Allow-Origin: * response value together with credentials mode, so the advisory’s allow_credentials=True detail is not itself what enables the attack. The endpoint does not require victim credentials in the first place. Wildcard origin, methods, and headers are enough for an uncredentialed cross-origin request if the browser’s private-network checks and the local deployment permit it. The exact browser path can vary by browser and security policy; the unauthenticated API path does not.

That is why CORS is not the primary fix. CORS constrains cooperating browsers. It does nothing against a local process, a network peer that can reach a non-loopback bind, malware already on the host, or a client that ignores browser policy. The missing control is authenticated, authorized ingress bound to a specific user and installation.

The LLM adds variance, not protection

The chain uses a prompt to get from the response endpoint to the scratchpad, so it is tempting to classify this as prompt injection and reach for a stronger system prompt. That would protect the wrong boundary.

According to the GitHub advisory, the exploit may retry because the agent must choose the scratchpad tool. That is model-dependent variance. Once the tool call is made, however, the execution is deterministic: the scratchpad compiles Python and executes it in a namespace with builtins. The vulnerable design therefore puts host security behind a probabilistic refusal. A model declining nine requests out of ten would still leave a remotely accessible code-execution lottery.

The NVD record maps the issue to CWE-94, improper control of code generation. The project advisory also identifies missing authentication and a permissive cross-domain policy. Those three categories describe three different boundaries that all failed:

Identity: no proof of who is calling the control plane.
Origin: browser-delivered untrusted code can address the local service.
Capability: model-selected Python receives the authority of the server process.

Model safety operates inside the third stage, after the first two gates have already admitted the request. It cannot substitute for either gate.

There is no patched release to point at

This is where the disclosure becomes operationally awkward. The MindsDB advisory, published July 17, lists no patched version. The GitHub releases API still shows v26.1.0, published April 23, as the newest tagged release at the time of writing. VulnCheck’s August 13 advisory and the August 14 NVD record both mark 26.1.0 and earlier as affected.

Observed fact: no fixed release is identified by the vendor advisory. Reasonable inference: operators should not assume a newer commit on a development branch constitutes a supported fix unless MindsDB documents it as such. Open question: what final remediation the project will ship — authentication, origin restrictions, sandboxing, removal or redesign of scratchpad execution, or some combination — is not yet stated in the advisory.

Until a supported patched release exists, the safe response is containment, not wishful upgrading:

stop affected instances when they are not needed;
ensure port 26866 is not exposed to a LAN, container bridge, remote tunnel, reverse proxy, or public interface;
use host firewall rules to restrict the listener, while remembering that firewalling does not solve the malicious-browser-on-localhost path;
isolate the application in a disposable VM or container with no home-directory mount, SSH keys, browser profiles, cloud credentials, production repositories, Docker socket, or privileged host access;
rotate provider keys and other secrets reachable by the server user if an affected instance was exposed;
monitor the vendor advisory for an explicit patched version before restoring normal use.

Disabling the scratchpad capability, if the product offers a verified configuration that truly prevents registration and execution, would break the final link. Merely asking the model not to use it would not.

What agent platforms should learn from this

A production agent control plane needs the same boring controls as every other privileged service, plus stricter execution boundaries because its job is to translate ambiguous language into action.

Authenticate before inference. Every settings, task, response, tool, memory, artifact, and scheduling endpoint needs an authenticated principal. “Desktop app” is not a principal. “Request came from localhost” is not a principal.

Authorize capabilities, not routes. The caller allowed to ask a question is not automatically allowed to modify model credentials, invoke a scratchpad, install dependencies, read arbitrary files, or launch a subprocess. Tool capability should be checked at execution time against the authenticated principal and current task policy.

Treat browser origin as hostile input. Local services should default to a narrow origin allowlist or a per-installation handshake. CORS should be defence in depth around real authentication, not the only thing standing between a web page and a privileged API.

Put code execution in a disposable security domain. The scratchpad code shows a persistent namespace with Python builtins and even automatic installation of missing modules. That is useful agent infrastructure. It is also a capability boundary that belongs in an isolated process, container, microVM, or remote worker with explicit filesystem, network, credential, CPU, memory, and lifetime limits. The server user’s home directory is not a sandbox.

Make dangerous defaults fail closed. If authentication is absent, the agent should not start an execution-capable HTTP server. If no sandbox is available, the scratchpad should not register. If the origin is unknown, the request should fail before it reaches a model. Each layer should independently stop the chain.

CVE-2026-73678 is not a story about an unusually obedient model. It is what happens when an agent’s convenience interfaces are mistaken for trust boundaries. The endpoint accepted the caller, the settings API accepted the key, the model selected the tool, and Python did exactly what Python was told. In an agent system, localhost is an address. Authentication, authorization, and isolation are the boundary.