--- title: "MLflow AI Gateway credential exfiltration - CVE-2026-4035" description: "CVE-2026-4035: MLflow AI Gateway credential exfiltration in MLflow < 3.11.0. A crafted api_base sends resolved server-side api_key secrets to attackers." url: "https://anomity.ai/blog/mlflow-ai-gateway-secrets-exfiltration-cve-2026-4035/" source: html --- On this page - What happened - Why this is an agentic-endpoint risk - How Anomity surfaces and governs it - What to check across your fleet - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - MLflow AI Gateway credential exfiltration - CVE-2026-4035 ![Anomity robot illustrating MLflow AI Gateway credential exfiltration - CVE-2026-4035] Advisory Critical # MLflow AI Gateway credential exfiltration - CVE-2026-4035 Anomity Research Anomity Threat Research · Jun 3, 2026 · 7 min read Share: Copied Secrets & Config Exposure · Critical · CVE-2026-4035 · Jun 3, 2026 Affected MLflow < 3.11.0 (AI Gateway); fixed in 3.11.0 **CVE-2026-4035** is a **Critical** MLflow AI Gateway credential exfiltration flaw, tracked as **GHSA-g35p-px32-whv6**, in **MLflow before version 3.11.0**. The AI Gateway lets a provider secret's `api_key` field reference an environment variable, which the server resolves against its own environment and then sends in the outbound authentication header to the configured upstream endpoint. If an attacker controls that destination, the server hands over its own credentials, for example AWS access keys, to an attacker-controlled host. It is classified as **CWE-201**, insertion of sensitive information into sent data, and is fixed in **MLflow 3.11.0**. This advisory covers what leaks, why secrets living in AI Gateway configs are an agentic-endpoint problem, and how Anomity surfaces and governs the agents that route through them. ## What happened MLflow's AI Gateway is a proxy layer that fronts model providers so agents and applications can call one endpoint instead of wiring provider credentials into every caller. Each gateway endpoint carries the provider's `api_base` (where to send the request) and an `api_key` (the secret to authenticate with). To keep secrets out of the config file, the `api_key` field can hold an `$ENV_VAR` reference that the server resolves at runtime against its own environment variables. A typical endpoint definition looks like this, with the secret pulled from the server's environment rather than written inline: ``` endpoints: - name: bedrock-claude endpoint_type: llm/v1/chat model: provider: bedrock config: api_base: https://bedrock-runtime.us-east-1.amazonaws.com api_key: $AWS_SECRET_ACCESS_KEY ``` The trust boundary breaks in how those two fields combine. The server resolves the `$ENV_VAR` reference to the real credential and places it in the provider authentication header of the outbound request to `api_base`. Nothing binds that resolved secret to a trusted destination. If an attacker controls the `api_base` value, or can define a new endpoint that points at a host they own, the server dutifully sends its own environment credentials to the attacker's destination. This is server-side credential exfiltration: the leaked secret, for example an AWS access key, is one the attacker was never authorized to read. The impact does not stop at the leak. A resolved credential handed to an attacker can enable follow-on artifact poisoning and code execution against whatever systems that key unlocks. In default deployments, low-privileged authenticated users, and in some configurations unauthenticated users, can trigger the flow, so the barrier to exploitation is low. The fix in MLflow 3.11.0 closes the path; before that release, every secret referenced in a gateway config should be treated as exposed. Detail Value Identifier CVE-2026-4035 (GHSA-g35p-px32-whv6) Type Credential exfiltration via resolved api_key sent to attacker-controlled api_base Weakness CWE-201 (insertion of sensitive information into sent data) Severity Critical Component MLflow AI Gateway (endpoint api_key / api_base handling) Affected MLflow < 3.11.0 (package: mlflow, pip) Fixed in MLflow 3.11.0 Exploitable by Low-privileged authenticated users, or unauthenticated users in default deployments ## Why this is an agentic-endpoint risk An AI Gateway exists to be routed through. Agents, CLIs, and developer tooling point at MLflow's gateway precisely so they do not have to hold provider credentials themselves. That design concentrates real secrets, AWS access keys and provider tokens, inside gateway configs that agents call constantly. When the gateway resolves an `$ENV_VAR` and attaches it to an outbound request, the secret is only ever as safe as the destination the config names. That makes this a secrets-and-config-exposure problem, not a networking bug: the sensitive material lives in an AI config, and a change to one field turns a routine model call into an exfiltration channel. The blind spot is knowing where these configs and their secret references live across the fleet. Network and DLP controls see an outbound HTTPS request leave the gateway, but cannot tell you which endpoints run an affected MLflow build, which gateway configs carry `$ENV_VAR` `api_key` references, or which agents route through them. This is the same secrets-in-AI-configs pattern the cluster tracks. It sits under the [Secrets in AI Agent Configs](https://anomity.ai/blog/secrets-management-for-ai-agents/) guidance and next to sibling gateway and framework cases including [MLflow model serving command injection - CVE-2026-0596](https://anomity.ai/blog/mlflow-model-serving-command-injection-cve-2026-0596/), [LangChain unsafe deserialization - CVE-2026-44843](https://anomity.ai/blog/langchain-unsafe-deserialization-cve-2026-44843/), [Gradio proxy URL SSRF - CVE-2026-28416](https://anomity.ai/blog/gradio-proxy-url-ssrf-cve-2026-28416/), and [LangSmith SDK arbitrary file read - GHSA-f4xh-w4cj-qxq8](https://anomity.ai/blog/langsmith-sdk-file-read-ghsa-f4xh-w4cj-qxq8/). The same lesson runs through the wider gateway cluster: a proxy that holds provider secrets is a high-value target the moment an attacker can influence where it sends them, as in [LiteLLM api_base SSRF and key leak - CVE-2024-6587](https://anomity.ai/blog/litellm-ssrf-api-base-key-leak-cve-2024-6587/). For the broader pattern of securing these layers, see [securing LLM gateways and proxies](https://anomity.ai/blog/securing-llm-gateways-and-proxies/) and the framework pillar on [securing AI agent frameworks](https://anomity.ai/blog/securing-ai-agent-frameworks/). You can't govern what you can't see, and a fleet-wide [inventory of every AI artifact](https://anomity.ai/#features) is the precondition for scoping a secret-exposure event like this one. ## How Anomity surfaces and governs it Anomity inventories eight AI artifact types on every managed endpoint: AI agents, MCP servers, extensions, skills, plugins, secrets, hooks, and CLIs. Secrets are a first-class artifact type, so for CVE-2026-4035 that means the AI Gateway configs and the secret references their `api_key` fields carry are catalogued alongside the MLflow version and the agents that route through the gateway. You can answer "which endpoints run an affected MLflow build, and which gateway configs reference an environment secret" from the [fleet inventory](https://anomity.ai/#features) instead of grepping hosts by hand. Because this is a secrets-exposure flaw, how Anomity handles the secret values matters. Anomity collects **metadata only** and redacts secret values **on the endpoint**, so the resolved `api_key`, the AWS access key this CVE tries to exfiltrate, never passes through Anomity. What Anomity records is that a secret reference exists in a given config and which agents can reach it, not the credential itself. That is the difference between surfacing the exposure and becoming a second place the secret can leak from. On agents that expose a hook, such as Claude Code PreToolUse, Anomity returns **allow**, **deny**, or **log** on each tool call before it runs. That is the enforcement point in [runtime governance](https://anomity.ai/#runtime-governance): a tool call that would push a request through a gateway endpoint pointed at an unapproved `api_base` can be denied or logged in line, rather than discovered after the resolved credential has already left the host. Every decision is written to a queryable 90-day audit trail, which is what lets responders scope the event: which agents routed through the gateway, when, and against which destination. Anomity routes those decisions to SIEM, Slack, email, or Jira so the right team sees them where they already work, delivering the timeline and enforcement record described under [outcomes](https://anomity.ai/#outcomes). Anomity complements your existing Network, EDR, DLP, and GRC controls rather than replacing them, and it is SOC 2 Type II. It adds the agentic-endpoint layer those tools cannot see. See [how it works](https://anomity.ai/#how-it-works) and [how Anomity compares](https://anomity.ai/#compare) for where it fits. ## What to check across your fleet - Identify every endpoint running MLflow and record the exact version; treat anything below 3.11.0 with the AI Gateway enabled as affected, and upgrade to 3.11.0 or later. - Enumerate every AI Gateway config and flag any endpoint whose api_key field uses an $ENV_VAR reference resolved from the server environment. - Rotate every provider credential those api_key fields resolve to, including AWS access keys, on any host that ran an affected MLflow build. - Constrain who can create or edit gateway endpoints so a low-privileged or unauthenticated user cannot define an endpoint or change an api_base. - Restrict the gateway's outbound egress to the known upstream providers it legitimately calls, so a forged api_base cannot reach an arbitrary destination. - Confirm no gateway config points its api_base at a host outside your approved provider allowlist, and alert on changes to that field. - Enumerate which AI agents and CLIs route model calls through the MLflow gateway, using a fleet-wide AI artifact inventory of agents and secrets. - Confirm hook-based allow/deny/log enforcement is active on agents that drive the gateway, so a call to an endpoint with an unapproved api_base can be blocked before it runs. CVE-2026-4035 turns a single config field into server-side credential exfiltration, sending the gateway's own secrets to an attacker-controlled host, which is exactly why secrets living in AI configs need their own inventory, redaction, and enforcement. For the full cluster context, see the pillar on [securing AI agent frameworks](https://anomity.ai/blog/securing-ai-agent-frameworks/) and the guidance on [secrets management for AI agents](https://anomity.ai/blog/secrets-management-for-ai-agents/). To see Anomity inventory your agents and secrets, govern tool calls at the hook, and keep a 90-day audit trail, [book a demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What is CVE-2026-4035 in MLflow? CVE-2026-4035, tracked as GHSA-g35p-px32-whv6, is a Critical credential exfiltration flaw in MLflow's AI Gateway affecting MLflow versions before 3.11.0. The gateway lets a provider endpoint's api_key field reference an environment variable using $ENV_VAR syntax. The server resolves that reference against its own environment at runtime, then places the resolved credential in the authentication header of the outbound request to the configured api_base. If an attacker controls the api_base or can define an endpoint, the server sends its own credentials, for example AWS access keys, to an attacker-controlled destination. The issue is classified as CWE-201, insertion of sensitive information into sent data. It is fixed in MLflow 3.11.0. Who can exploit the MLflow AI Gateway credential exfiltration? In default deployments, low-privileged authenticated users, and in some configurations unauthenticated users, can trigger it. The exploit does not require prior access to the secret values themselves. An attacker only needs to influence where the gateway sends its request, either by controlling the api_base of a provider endpoint or by defining a new endpoint that points at a host they own. Because the server performs the credential resolution and attaches the secret to the outbound authentication header itself, the attacker receives credentials they were never authorized to read. That resolved secret can then enable follow-on artifact poisoning and code execution against systems the leaked credential unlocks. How do we fix CVE-2026-4035? Upgrade MLflow to version 3.11.0 or later, which contains the fix. Until you can upgrade, treat every provider secret referenced in an AI Gateway config as potentially exposed and rotate the credentials those api_key fields resolve to, including any AWS access keys. Constrain who can create or edit gateway endpoints so a low-privileged or unauthenticated user cannot define an endpoint or change an api_base to an attacker-controlled host. Restrict the gateway's outbound egress to the known upstream providers it legitimately calls, so a forged api_base cannot reach an arbitrary destination. Then confirm no gateway config points its api_base at a host outside your approved provider list. How does Anomity help with secrets exposed in AI configs? Anomity inventories secrets as one of eight AI artifact types on every managed endpoint, so it surfaces the AI Gateway configs and the secret references they carry alongside the agents that route through them. It collects metadata only and redacts secret values on the endpoint, so the resolved api_key never passes through Anomity. On agents that expose a hook, such as Claude Code PreToolUse, it returns allow, deny, or log on each tool call before it runs, so a call that would push a request through a gateway endpoint pointed at an unapproved api_base can be denied or logged in line. Every decision lands in a queryable 90-day audit trail for scoping the event across the fleet. ## Related [Advisory High ### LangChain unsafe deserialization - CVE-2026-44843 CVE-2026-44843: a High-severity unsafe deserialization in langchain-core [Advisory High ### OpenCode Server Cross-Site Upgrade Installs Attacker Packages - GHSA-632h-h47v-g4x4 A web page could make OpenCode's local server install an attacker's npm package via a cross-site form. No DNS rebinding needed. Fixed in 1.18.22. Anomity Research · Oct 2, 2026 · GHSA-632h-h47v-g4x4 (CVSS 7.5, no CVE)](https://anomity.ai/blog/opencode-cross-site-upgrade-rce-ghsa-632h-h47v-g4x4/) [Advisory High ### Plugin4Shell - A Branch Named Like a Commit Broke Plugin SHA Pinning in Four Coding Agents Plugin4Shell let a plugin owner swap reviewed code under an intact SHA pin. Auto-update made it zero-click. Two agents patched, two never will. Anomity Research · Oct 2, 2026 · Plugin4Shell (AIR, 2026-09-17); no CVE assigned](https://anomity.ai/blog/plugin4shell-coding-agent-plugin-sha-pinning-bypass/) ## Structured data ```json { "@context": "https://schema.org", "@type": "TechArticle", "headline": "MLflow AI Gateway credential exfiltration - CVE-2026-4035", "description": "CVE-2026-4035: MLflow AI Gateway credential exfiltration in MLflow < 3.11.0. A crafted api_base sends resolved server-side api_key secrets to attackers.", "datePublished": "2026-06-03", "dateModified": "2026-06-03", "author": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ] }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/mlflow-ai-gateway-secrets-exfiltration-cve-2026-4035/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/prompt-injection.jpg", "width": 1200, "height": 630 }, "articleSection": "Secrets & Config Exposure", "url": "https://anomity.ai/blog/mlflow-ai-gateway-secrets-exfiltration-cve-2026-4035/", "keywords": "MLflow AI Gateway credential exfiltration, CVE-2026-4035, MLflow, AI Gateway, credential exfiltration, secrets exposure, SSRF, CVE-2026-4035, api_key, environment variables" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is CVE-2026-4035 in MLflow?", "acceptedAnswer": { "@type": "Answer", "text": "CVE-2026-4035, tracked as GHSA-g35p-px32-whv6, is a Critical credential exfiltration flaw in MLflow's AI Gateway affecting MLflow versions before 3.11.0. The gateway lets a provider endpoint's api_key field reference an environment variable using $ENV_VAR syntax. The server resolves that reference against its own environment at runtime, then places the resolved credential in the authentication header of the outbound request to the configured api_base. If an attacker controls the api_base or can define an endpoint, the server sends its own credentials, for example AWS access keys, to an attacker-controlled destination. The issue is classified as CWE-201, insertion of sensitive information into sent data. It is fixed in MLflow 3.11.0." } }, { "@type": "Question", "name": "Who can exploit the MLflow AI Gateway credential exfiltration?", "acceptedAnswer": { "@type": "Answer", "text": "In default deployments, low-privileged authenticated users, and in some configurations unauthenticated users, can trigger it. The exploit does not require prior access to the secret values themselves. An attacker only needs to influence where the gateway sends its request, either by controlling the api_base of a provider endpoint or by defining a new endpoint that points at a host they own. Because the server performs the credential resolution and attaches the secret to the outbound authentication header itself, the attacker receives credentials they were never authorized to read. That resolved secret can then enable follow-on artifact poisoning and code execution against systems the leaked credential unlocks." } }, { "@type": "Question", "name": "How do we fix CVE-2026-4035?", "acceptedAnswer": { "@type": "Answer", "text": "Upgrade MLflow to version 3.11.0 or later, which contains the fix. Until you can upgrade, treat every provider secret referenced in an AI Gateway config as potentially exposed and rotate the credentials those api_key fields resolve to, including any AWS access keys. Constrain who can create or edit gateway endpoints so a low-privileged or unauthenticated user cannot define an endpoint or change an api_base to an attacker-controlled host. Restrict the gateway's outbound egress to the known upstream providers it legitimately calls, so a forged api_base cannot reach an arbitrary destination. Then confirm no gateway config points its api_base at a host outside your approved provider list." } }, { "@type": "Question", "name": "How does Anomity help with secrets exposed in AI configs?", "acceptedAnswer": { "@type": "Answer", "text": "Anomity inventories secrets as one of eight AI artifact types on every managed endpoint, so it surfaces the AI Gateway configs and the secret references they carry alongside the agents that route through them. It collects metadata only and redacts secret values on the endpoint, so the resolved api_key never passes through Anomity. On agents that expose a hook, such as Claude Code PreToolUse, it returns allow, deny, or log on each tool call before it runs, so a call that would push a request through a gateway endpoint pointed at an unapproved api_base can be denied or logged in line. Every decision lands in a queryable 90-day audit trail for scoping the event across the fleet." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "MLflow AI Gateway credential exfiltration - CVE-2026-4035", "item": "https://anomity.ai/blog/mlflow-ai-gateway-secrets-exfiltration-cve-2026-4035/" } ] } ```