CVE-2026-67425: SSRF leaks LLM API keys via base_url

CISO Take

Flyto2 Core's llm.chat function pulls OPENAI_API_KEY and ANTHROPIC_API_KEY straight from the environment and attaches them as Bearer tokens to whatever base_url the caller supplies, so any user or downstream integration that can reach this function can redirect the request to a host they control and simply read the key off the wire. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks pre-weaponization rather than actively exploited — but the attack requires zero privileges, zero user interaction, and only network access (CVSS 8.6, AV:N/AC:L/PR:N/UI:N), and the bar is a single outbound HTTP request to a host that clears the built-in SSRF guard, which is a low technical ceiling for a high-value payout. Any environment where Flyto2-orchestrated agents call out to third-party or user-influenced endpoints should treat their OpenAI/Anthropic keys as effectively exposed until patched. Upgrade to 2.26.6 immediately, then rotate every OPENAI_API_KEY and ANTHROPIC_API_KEY that was ever reachable by a Flyto2 instance, since patching alone doesn't invalidate keys already exfiltrated. In the interim, egress-filter outbound calls from Flyto2 hosts to an allowlist of known LLM provider domains and audit provider-side usage logs for anomalous source IPs or spend spikes.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High severity (CVSS 8.6) with a low complexity, no-privilege, no-interaction network attack path — the confidentiality impact is severe (full LLM provider API key disclosure) while integrity and availability are untouched, matching the C:H/I:N/A:N vector. Exploitability today is constrained mainly by the SSRF guard, which the advisory explicitly states can be passed using a public host; there's no evidence of a public PoC, scanner template, or KEV/EPSS signal, so likelihood is currently assessed as opportunistic rather than mass-exploited. The real risk driver is blast radius per successful exploitation: a single stolen key can be reused far outside the victim's environment (unauthorized LLM spend, data exposure via the provider account, pivot into other systems trusting that key) with no forensic trail inside Flyto2 itself.

How does the attack unfold?

Initial Access

Attacker gains the ability to configure or submit a Flyto2 workflow with a custom base_url for the llm.chat step.

AML.T0049

SSRF Guard Bypass

Attacker points base_url at a public, attacker-controlled host crafted to pass Flyto2's SSRF validation checks.

Credential Exfiltration

Flyto2 Core sends the operator's OPENAI_API_KEY or ANTHROPIC_API_KEY in the Authorization: Bearer header to the attacker's endpoint, which logs it.

AML.T0055

Impact / Key Abuse

Attacker reuses the stolen key directly against the real provider API for unauthorized usage, cost harvesting, or data access.

AML.T0012

Initial Access

Attacker gains the ability to configure or submit a Flyto2 workflow with a custom base_url for the llm.chat step.

AML.T0049

SSRF Guard Bypass

Attacker points base_url at a public, attacker-controlled host crafted to pass Flyto2's SSRF validation checks.

Credential Exfiltration

Flyto2 Core sends the operator's OPENAI_API_KEY or ANTHROPIC_API_KEY in the Authorization: Bearer header to the attacker's endpoint, which logs it.

AML.T0055

Impact / Key Abuse

Attacker reuses the stolen key directly against the real provider API for unauthorized usage, cost harvesting, or data access.

AML.T0012

How severe is it?

CVSS 3.1

8.6 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Changed

C High

I None

A None

What should I do?

1 step

1) Patch to Flyto2 Core 2.26.6 or later immediately — this is the definitive fix per the vendor advisory (GHSA-qq9q-xgm3-xv9g) and commit d5f89d71. 2) Rotate OPENAI_API_KEY, ANTHROPIC_API_KEY, and any other provider credentials accessible to Flyto2-hosted processes, treating them as compromised regardless of whether exploitation is confirmed. 3) Until patched, restrict or disable user-configurable base_url in llm.chat via a network policy — enforce an egress allowlist (api.openai.com, api.anthropic.com, and any explicitly approved proxy) at the host/firewall level so credentials cannot be sent to arbitrary destinations even if the application-layer SSRF guard is bypassed. 4) Detect exploitation attempts by reviewing outbound HTTP logs from Flyto2 hosts for requests to non-allowlisted domains carrying an Authorization: Bearer header, and check provider-side (OpenAI/Anthropic) API usage dashboards for requests from unrecognized source IPs or unexpected spend patterns. 5) Move to a secrets-management pattern where provider keys are injected per-tenant/per-workflow with least privilege rather than shared process-wide environment variables, reducing blast radius for future flaws of this class.

How is it classified?

Data Leakage Privacy Violation Agent API AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.10.2 - Third-party and supplier relationships

NIST AI RMF

MANAGE 4.1 - Risk treatment for third-party AI system components

OWASP LLM Top 10

LLM02:2025 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-67425?

Flyto2 Core's llm.chat function pulls OPENAI_API_KEY and ANTHROPIC_API_KEY straight from the environment and attaches them as Bearer tokens to whatever base_url the caller supplies, so any user or downstream integration that can reach this function can redirect the request to a host they control and simply read the key off the wire. There's no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template yet, so this looks pre-weaponization rather than actively exploited — but the attack requires zero privileges, zero user interaction, and only network access (CVSS 8.6, AV:N/AC:L/PR:N/UI:N), and the bar is a single outbound HTTP request to a host that clears the built-in SSRF guard, which is a low technical ceiling for a high-value payout. Any environment where Flyto2-orchestrated agents call out to third-party or user-influenced endpoints should treat their OpenAI/Anthropic keys as effectively exposed until patched. Upgrade to 2.26.6 immediately, then rotate every OPENAI_API_KEY and ANTHROPIC_API_KEY that was ever reachable by a Flyto2 instance, since patching alone doesn't invalidate keys already exfiltrated. In the interim, egress-filter outbound calls from Flyto2 hosts to an allowlist of known LLM provider domains and audit provider-side usage logs for anomalous source IPs or spend spikes.

Is CVE-2026-67425 actively exploited?

No confirmed active exploitation of CVE-2026-67425 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-67425?

1) Patch to Flyto2 Core 2.26.6 or later immediately — this is the definitive fix per the vendor advisory (GHSA-qq9q-xgm3-xv9g) and commit d5f89d71. 2) Rotate OPENAI_API_KEY, ANTHROPIC_API_KEY, and any other provider credentials accessible to Flyto2-hosted processes, treating them as compromised regardless of whether exploitation is confirmed. 3) Until patched, restrict or disable user-configurable base_url in llm.chat via a network policy — enforce an egress allowlist (api.openai.com, api.anthropic.com, and any explicitly approved proxy) at the host/firewall level so credentials cannot be sent to arbitrary destinations even if the application-layer SSRF guard is bypassed. 4) Detect exploitation attempts by reviewing outbound HTTP logs from Flyto2 hosts for requests to non-allowlisted domains carrying an Authorization: Bearer header, and check provider-side (OpenAI/Anthropic) API usage dashboards for requests from unrecognized source IPs or unexpected spend patterns. 5) Move to a secrets-management pattern where provider keys are injected per-tenant/per-workflow with least privilege rather than shared process-wide environment variables, reducing blast radius for future flaws of this class.

What systems are affected by CVE-2026-67425?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM API integrations, workflow automation pipelines.

What is the CVSS score for CVE-2026-67425?

CVE-2026-67425 has a CVSS v3.1 base score of 8.6 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM API integrationsworkflow automation pipelines

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.10.2

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM02:2025

What are the technical details?

Original Advisory

Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, llm.chat reads provider keys such as OPENAI_API_KEY and ANTHROPIC_API_KEY from the environment and sends them in the Authorization: Bearer header to caller-controlled base_url, allowing an attacker to receive the operator's key on a public host that passes the SSRF guard. This issue is fixed in version 2.26.6.

Exploitation Scenario

An attacker who can author or influence a Flyto2 workflow — for example, a low-privilege user on a multi-tenant automation platform, or someone submitting a malicious workflow template — configures an llm.chat step with base_url pointed at a public server they control (crafted to satisfy the SSRF guard's checks, e.g. a normal-looking public hostname rather than an internal/loopback address). When the workflow executes, Flyto2 Core reads OPENAI_API_KEY or ANTHROPIC_API_KEY from its environment and issues the chat completion request to the attacker's endpoint with the key in the Authorization: Bearer header. The attacker's server simply logs the header and returns any response (or an error) to avoid raising suspicion in the workflow UI. With the harvested key, the attacker then makes direct calls to the real OpenAI/Anthropic API — consuming the victim's quota, incurring unauthorized charges, or accessing any organization-scoped data or fine-tuned models tied to that account — all outside Flyto2's visibility.

Weaknesses (CWE)

CWE-201 Insertion of Sensitive Information Into Sent Data Primary CWE-522 Insufficiently Protected Credentials Primary

CWE-201 — Insertion of Sensitive Information Into Sent Data: The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.

[Requirements] Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
[Implementation] Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.

Source: MITRE CWE corpus.