← Back to blog AdvisoryCritical

MLflow AI Gateway credential exfiltration - CVE-2026-4035

Q: 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.

Q: 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.

Q: 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.

Q: 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.

Anomity Research Anomity Threat Research · Jun 3, 2026 · 7 min read

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 guidance and next to sibling gateway and framework cases including MLflow model serving command injection - CVE-2026-0596, LangChain unsafe deserialization - CVE-2026-44843, Gradio proxy URL SSRF - CVE-2026-28416, and LangSmith SDK arbitrary 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. For the broader pattern of securing these layers, see securing LLM gateways and proxies and the framework pillar on securing AI agent frameworks. You can't govern what you can't see, and a fleet-wide inventory of every AI artifact 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 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: 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.

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 and how Anomity compares 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 and the guidance on 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, request early access.

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.