Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The HTTP modules that DO call the SSRF guard (http.get, http.request, http.batch) validate only the initial URL, then issue the request with aiohttp's default allowredirects=True and perform no per-hop revalidation. An attacker hosts a public URL that 302-redirects to an internal address; the guard passes on the public host and aiohttp transparently follows the redirect into internal space, returning the internal body. Root Cause src/core/modules/atomic/http/get.py:116 calls session.get(url, ...) with no allowredirects argument → aiohttp default True. request.py:60 sets allowredirects=followredirects (default True at :327); batch.py:57 likewise. A repo grep of http/ for onrequestredirect / response.history returns NONE — there is no redirect interception or Location revalidation. Impact Full readable SSRF that defeats the primary SSRF control on the very modules that correctly validate. Confidentiality of internal/metadata responses (C:H), S:C. Proof of Concept Verified live:…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Numerous HTTP-emitting modules (core.api.httpget, core.api.httppost, graphql.query/graphql.mutation, monitor.httpcheck, communication.slacksend, notification.{discord,slack,teams}.sendmessage, ai.visionanalyze [anthropic path], verify.visualdiff, browser.proxyrotate, and the agent/llm inline baseurl branch) perform outbound requests to a fully client-controlled URL without calling the project's own SSRF guard (validateurlwithenvconfig) that their sibling modules apply. An authenticated workflow-author can point the URL at the cloud metadata IP (169.254.169.254), a loopback/RFC1918 host, or any internal host and read the response, yielding cloud-metadata credential theft and internal service read/write. Root Cause The SSRF guard is per-module (there is NO global egress interception). Each module must call validateurlwithenvconfig before issuing a request. The listed modules never call it — they only carry an ssrfprotected metadata tag string which enforces nothing. Exemplar:…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The standalone flyto-verification service exposes POST /run with no authentication, on all interfaces (0.0.0.0:8344 per the shipped Dockerfile). The request body's callbackurl is used verbatim for an outbound POST that unconditionally attaches X-Internal-Key: $FLYTORUNNERSECRET. The callbackurl bypasses the service's targetallowed allowlist (which only inspects params.targeturl) and is never passed through any SSRF guard. This yields (a) unauthenticated SSRF to internal/metadata endpoints with an attacker-controlled JSON body, and (b) exfiltration of the internal runner secret to an attacker-controlled host — allowing forged authenticated callbacks to the real engine. Root Cause - src/core/verificationservice.py:363-364 — /run has no Depends/auth dependency. - resolvecallbackurl returns the client callbackurl verbatim (:315-316). - postcallback attaches X-Internal-Key: $FLYTORUNNERSECRET whenever the env var is set (:327-335). - targetallowed only gates params.targeturl…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
llm.chat reads the operator's provider key from the environment (OPENAIAPIKEY, ANTHROPICAPIKEY, ...) and sends it in the Authorization: Bearer header to baseurl, a parameter the caller controls. baseurl is only checked against the SSRF guard, and the guard allows any public host, so pointing baseurl at an attacker's server hands them the operator's key. flyto-core's own bounty scale rates "environment access exposing secrets (e.g. ANTHROPICAPIKEY)" as High. Affected code src/core/modules/atomic/llm/chat.py (callopenai): The same wiring (env key plus caller endpoint) exists in ai.model (which does not even SSRF-check baseurl), llm.agent, and vector.connector (QDRANTAPIKEY 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 keyexfilpoc.py, run with PYTHONPATH=src/src python keyexfilpoc.py. It sets an operator key in the environment and points baseurl…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The capability policy denies the env.get and env.loaddotenv modules by default, with the stated reason that they read arbitrary host environment variables (API keys, DSNs) and are a secret-exfil risk. But the workflow engine's variable resolver expands ${env.VAR} for any environment variable with no allowlist and no policy check, so the exact capability the denylist blocks is available to any workflow parameter. The resolved secret can then be sent out through any allowed module. Affected code src/core/engine/variableresolver.py: The module policy (enforcemodulepolicy in modulepolicy.py) gates module execution at BaseModule.run, but ${...} interpolation happens earlier in the engine and is not subject to it. So denylisting env.get does not actually stop a workflow from reading host env secrets. Reproduction Save as envbypasspoc.py, run with PYTHONPATH=src/src python envbypasspoc.py. Output: env.get is denied, yet ${env.AWSSECRETACCESSKEY} reads the same secret and drops it…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
image.download fetches a URL and writes the response to disk. It does not use the central path guard (validatepathwithenvconfig, which confines writes to FLYTOSANDBOXDIR); instead it confines the output to outputdir, but outputdir is itself a caller parameter. Since the attacker sets both the target and the base it is checked against, the check is meaningless, and attacker-controlled bytes (the HTTP response) land at any absolute path the process can write. Affected code src/core/modules/atomic/image/download.py: commonpath is used correctly, but the base is caller-supplied, so setting outputdir='/' passes any target. file.write, by contrast, uses validatepathwithenvconfig() and stays inside FLYTOSANDBOXDIR. This is not isolated to image.download. Most other file-writing modules write to a caller outputpath with no path check at all: image.convert, image.resize, image.crop, image.compress, image.rotate, image.watermark, image.qrcodegenerate, document.excelwrite,…
Recommended action: Upgrade to 2.26.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Unauthenticated Command Execution via HTTP MCP executemodule Summary The HTTP MCP endpoint (POST /mcp) in flyto-core accepts unauthenticated JSON-RPC tools/call requests and dispatches them to arbitrary registered modules, including sandbox.executeshell, which passes attacker-controlled input directly to asyncio.createsubprocessshell. An unauthenticated attacker can execute arbitrary OS commands as the flyto-core server process. By default the server binds to 127.0.0.1, making this a High-severity local vulnerability (CVSS 8.4); if started with --host 0.0.0.0, it becomes remotely exploitable over the network. Dynamic reproduction confirmed command execution as root inside a Docker container without any Authorization header. Details flyto-core exposes an HTTP API via FastAPI. When the API is started (flyto serve), the MCP router is unconditionally mounted at /mcp (src/core/api/server.py:75-78). The route handler at src/core/api/routes/mcp.py:65-66 declares @router.post("") with no…
Recommended action: Upgrade to 2.26.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
flyto-core's SSRF protection (validateurlssrf / isprivateip in src/core/utils.py) blocks private and metadata destinations by resolving the host and testing the resulting IP for membership in a hardcoded PRIVATEIPRANGES list. That list contains only the native RFC 1918 / loopback / link-local / unique-local ranges. It does not account for IPv6 transition address forms that embed an IPv4 (or loopback) target: - IPv4-mapped ::ffff:a.b.c.d - IPv4-compatible ::a.b.c.d - 6to4 2002::/16 - NAT64 well-known prefix 64:ff9b::/96 and local-use 64:ff9b:1::/48 A workflow author can submit a URL with a literal transition-form host (for example http://[::ffff:127.0.0.1]:8080/... or http://[64:ff9b::a9fe:a9fe]/latest/meta-data/). isprivateip() returns False for these (the address is not literally inside any listed range), so validateurlssrf lets the request through, and the http.get atomic module (and ~10 sibling modules that share the same guard) performs the outbound aiohttp fetch and…
Recommended action: Upgrade to 2.26.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.