Flyto Core EUVD-2026-50468

Exploitation requires that (1) the operator has provisioned real provider keys such as OPENAI_API_KEY or ANTHROPIC_API_KEY in the host environment, (2) the attacker can cause llm.chat/ai_model to run with a caller-controlled base_url (via a crafted workflow step or injected instructions to an AI agent), and (3) the chosen endpoint is a public host that satisfies the pre-existing SSRF guard. Limiting factors: if the deployment does not set provider keys in the environment, forbids custom base_url values, or has no path for untrusted input to reach workflow definitions, exploitation is not possible. The key exfiltrated is only what is present in the environment for the affected provider(s), and the impact is confidentiality-only (no integrity/availability effect).

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N, base 8.6) reflects a network-reachable, low-complexity issue with a scope change (S:C) because the secret crosses a trust boundary to a system the attacker controls, and high confidentiality impact with no integrity or availability effect - consistent with a credential-disclosure bug. No EPSS score, KEV entry, or public POC was provided, so exploitation likelihood signals are absent rather than low: treat this as unquantified, not benign. The PR:N rating deserves scrutiny - actually setting a malicious base_url requires the ability to influence a workflow/step definition (directly, or indirectly via prompt injection into an AI agent that composes requests), which in some deployments is not fully unauthenticated; verify against how workflows are authored in your environment. Net: for any deployment that runs Flyto Core with real provider keys in the environment and allows caller-influenced base_url values, this is a genuine high-priority secret-exfiltration risk despite the lack of a published exploit, because the payoff (a live API key) is immediate and monetizable.

An attacker who can influence a Flyto Core workflow - for example through prompt injection into an AI-agent step or by submitting a workflow that sets llm.chat's base_url - points base_url at a public server they control that passes the SSRF guard. When the workflow runs, the engine attaches the operator's OPENAI_API_KEY/ANTHROPIC_API_KEY as an Authorization: Bearer header and the attacker's server logs the incoming credential. No public POC was provided, but the technique is straightforward given low attack complexity.