Four Ways the AI Stack Exposes an API Key, All Disclosed in 24 Hours

Four ways the AI stack exposes an API key, all disclosed in 24 hours

Inside 24 hours on 10 and 11 October, four separate pieces of AI infrastructure got CVE IDs for exposing API credentials — three of them credentials the product itself stores. Katanemo Plano through 0.4.37 binds the Envoy admin interface to every host interface on port 9901 with no authentication, and a request to /config_dump returns the configured LLM provider API keys in plaintext out of the WASM filter configuration (8.7 on CVSS 4.0). TencentCloud Octop through 1.0.2b6 validates only the JWT on GET /api/providers and GET /api/voice/providers, so any authenticated low-privilege user reads the stored LLM and voice provider keys and can spend against the upstream accounts (7.1). Hugging Face Text Embeddings Inference through 1.9.4 logs its api_key in cleartext because the router's Args struct lacks a redact attribute, so anyone with the router logs, the container output or the OTLP telemetry recovers the bearer token (4.8). The fourth leaks someone else's keys: mini-swe-agent 1.10.0 through 2.4.6 runs bwrap without --clearenv in its Bubblewrap environment, so the sandboxed command inherits the whole host environment and a prompt injection in the processed task content can read whatever keys are in it and send them over the shared network (6.0).

The common factor is where the secret sits. Put a routing or gateway layer in front of several model providers and you have concentrated every key into one process — and none of these four failures is cryptographic. They are a config template, an authorisation check, a log line and a missing flag, and three of the four need no model involvement at all. The questions that separate these products are narrow and answerable: is the admin plane bound to localhost, is one tenant's token enough to read another tenant's secret, is the secret redacted on the way to telemetry. Note also what patching does not do. A key that has already been served in a /config_dump response, or written to a log shipper, is disclosed; closing the hole is the first job and rotating the key is the second.

One agent platform had no write boundary, and four more had one that did not hold

Astron Agent, iFlytek's agentic workflow platform, shipped a default that was not a sandbox — and the CVE ID for it only arrived last Friday. The repository advisory went up on 7 September, listing v1.1.1 and earlier as affected and v1.1.2 as the patch; the CVE record was published on 9 October at 9.9 critical on CVSS 3.1 — the only scale scored for it. The defect is the default: the workflow code node reached through /console-api/workflow/code/run and /workflow/v1/run selects LocalExecutor whenever CODE_EXEC_TYPE has not been explicitly changed, and LocalExecutor supplies dynamic code the complete Python builtins without the documented sandbox restrictions. An authenticated low-privilege tenant can therefore execute code as root in the core-workflow container, pick up the shared service and database credentials, and read or modify other tenants' data. Anyone tracking CVE feeds rather than repository advisories had a month in which the fix existed and the disclosure was not in front of them. The same vendor's desktop automation product has its own version of the problem: AstronRPA through 1.1.6 renders model output through v-html, so prompt-injected content on a visited page can emit an event handler that calls an unrestricted open-path IPC handler with shell metacharacters and runs commands as the desktop user (7.7).

Four more advisories published on 10 and 11 October describe boundaries that existed and did not hold, three of them by way of problems considerably older than LLMs. mistral.rs 0.9.0 through 0.9.4 — Eric Buehler's Rust inference server, which states in its own credits that it is not affiliated with Mistral AI — follows symlinks in mistralrs-code-exec, letting sandboxed shell code read and overwrite files outside the sandbox with the server process's permissions (7.6). open-multi-agent 1.5.0 through 1.21.2 lets a dangling symlink planted in the workspace carry a file_write outside the workspace root (5.7). Phi 0.3.0 through 0.28.4 lets a spawned sub-agent escape workspace_only_writes and read-only mode by handing agent_spawn an unchecked workdir (6.0). The fourth is the one to read twice, because nothing is evaded: Tabularis through 0.27.0 gates MCP run_query on the statement being a SELECT, and SELECT setval, nextval and PostgreSQL's query_to_xml with an embedded DELETE are all SELECTs that write (5.8). All four name prompt-injected content as an attacker, and two of them do not require it: Tabularis names untrusted MCP clients outright, and the mistral.rs vector needs only low privileges. The enforcement sits in the tool layer, and in half these cases you do not even need the model to be fooled.

Nvidia's open-defence alliance now has a vetting queue, and still no Google, Anthropic, Meta or OpenAI

At Open Source Summit Europe in Prague, which the Linux Foundation's schedule put on 7–9 October, Nvidia's head of cybersecurity policy Mark Weatherford defended the Open Secure AI Alliance against the charge that it is a symbolic gesture, Tech.eu reported on 9 October. Asked whether members would really share information with rivals during an AI land grab, he said he thinks the success of the alliance is the collaboration of the people who participate, and pointed at the size of the membership — the alliance's site lists more than a hundred companies — while allowing that market pressures might lead some of them to ask whether collaboration is best for them. He also said the Linux Foundation, which took the alliance over in September, has a queue of “hundreds and hundreds” of companies still being vetted, and that some companies, countries or organisations may not be wanted in it.

The absence is unchanged and still the most informative part. Google, Anthropic, Meta and OpenAI appear nowhere on the founding partner list of an alliance whose stated argument is that defenders need frontier tools they can inspect, run locally and control. Microsoft, Amazon, Hugging Face, Mistral and Cohere are all on it. Asked specifically about OpenAI, Weatherford pointed at the vetting queue rather than at a refusal. For a European buyer the practical read is narrower than the politics: this is now a Linux Foundation project with a backlog, so the things worth tracking are its dated deliverables — shared evaluation frameworks, agent-harness research, signed-patch tooling — rather than the length of the member list. Tech.eu's report of the Prague remarks attaches a date to none of them.

Quick Hits

• An MCP plugin put a full debugger on the network with no authentication. CVE-2026-107824 (9.3 critical, published 9 October) covers x64dbg-MCP Server before 1.1, which exposed every MCP debugger tool over HTTP and SSE while listening on 0.0.0.0 by default — port 9094 for x64, 9095 for x32. Any unauthenticated client that could reach it could run arbitrary x64dbg commands, attach to processes by PID, read and write debuggee memory and write files to arbitrary paths. Fixed in 1.1.
• The observability and gateway layers had their own weekend. OpenLIT 2.1.0 lets an authenticated user read another project's traces — LLM prompts and completions included — by forging an x-openlit-project-id header, given the project and database-config ids (6.0). LLMGateway through 1.20.0 skips its assertSafeWebhookTarget check on the video-generation callback_url, handing an API-key holder a blind SSRF into loopback, private and cloud-metadata addresses from the worker's network (5.3).
• An MCP connector for Odoo will read the fields its ACL denies. Odoo MCP 1.0.0 through 1.3.2 lets a client bypass the field-level ACL by calling read or search_read through the execute_method tool and naming the denied fields, which come back unredacted (5.3, published 11 October). The advisory's attacker is an MCP client or a prompt-injected agent — in other words, your own.
• The open-weight releases worth noting over the weekend were decision models, not chat models. The Apache-2.0 vllm-sr/d3 family went up on Hugging Face on 10 October as six models across five sizes, from d3 on a Qwen3.8-27B base down through 9B, 4B and 2B to d3-edge on Qwen3.5-0.8B, all tagged for zero-shot classification. autotrust/JEV-35B, an Apache-2.0 text-classification model on a Qwen3.5-35B-A3B base, followed on 11 October. Artificial Analysis's changelog has no entry after 9 October and that day's three entries are provider performance results, so nothing new was benchmarked over the weekend either.
• Ollama paused the background model upgrade it had shipped three days earlier. 0.40.2 (8 October) started upgrading locally downloaded models on first run and keeping the originals as on-disk backups so a downgrade stays safe. (11 October) paused that background upgrade for embedding and other request performance. The 0.40.2 notes say a future release will remove the backups automatically; until then they are still taking up disk unless you clear them with the jq script in those notes.