https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 23:11:38 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-342484 EUVD-2026-342484 https://cve.radiocsirt.org/vuln/euvd-2026-342484 https://cve.radiocsirt.org/vuln/fkie_cve-2026-67426 <p>Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the standalone flyto-verification service in src/core/verification_service.py exposes unauthenticated POST /run on 0.0.0.0:8344 and uses client-supplied callback_url for an outbound POST with X-Internal-Key: $FLYTO_RUNNER_SECRET while bypassing target_allowed, allowing unauthenticated SSRF and runner secret exfiltration. This issue is fixed in version 2.26.7.</p> <p>Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the standalone flyto-verification service in src/core/verification_service.py exposes unauthenticated POST /run on 0.0.0.0:8344 and uses client-supplied callback_url for an outbound POST with X-Internal-Key: $FLYTO_RUNNER_SECRET while bypassing target_allowed, allowing unauthenticated SSRF and runner secret exfiltration. This issue is fixed in version 2.26.7.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-67426 https://cve.radiocsirt.org/vuln/ghsa-jx74-cqjv-2c67 <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary 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&#39;s `callback_url` is used verbatim for an outbound POST that **unconditionally attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET`**. The `callback_url` bypasses the service&#39;s `target_allowed` allowlist (which only inspects `params.target_url`) 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.</p> <p>## Root Cause - `src/core/verification_service.py:363-364` — `/run` has no `Depends`/auth dependency. - `resolve_callback_url` returns the client `callback_url` verbatim (`:315-316`). - `post_callback` attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET` whenever the env var is set (`:327-335`). - `target_allowed` only gates `params.target_url` (`:259`), never `callback_url`. No `validate_url_*` anywhere in the file. - `Dockerfile.verification` CMD = `main(&#39;0.0.0.0&#39;, 8344)`; entrypoint `flyto-verification` in `pyproject.toml:107` → the shipped image binds all interfaces by default.</p> <p>## Impact Unauthenticated (PR:N) readable SSRF to internal/cloud-metadata with a controlled body (C:H, S:C), plus theft of `FLYTO_RUNNER_SECRET` to an attacker host → the attacker can then authenti…</p> <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary 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&#39;s `callback_url` is used verbatim for an outbound POST that **unconditionally attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET`**. The `callback_url` bypasses the service&#39;s `target_allowed` allowlist (which only inspects `params.target_url`) 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.</p> <p>## Root Cause - `src/core/verification_service.py:363-364` — `/run` has no `Depends`/auth dependency. - `resolve_callback_url` returns the client `callback_url` verbatim (`:315-316`). - `post_callback` attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET` whenever the env var is set (`:327-335`). - `target_allowed` only gates `params.target_url` (`:259`), never `callback_url`. No `validate_url_*` anywhere in the file. - `Dockerfile.verification` CMD = `main(&#39;0.0.0.0&#39;, 8344)`; entrypoint `flyto-verification` in `pyproject.toml:107` → the shipped image binds all interfaces by default.</p> <p>## Impact Unauthenticated (PR:N) readable SSRF to internal/cloud-metadata with a controlled body (C:H, S:C), plus theft of `FLYTO_RUNNER_SECRET` to an attacker host → the attacker can then authenti…</p> https://cve.radiocsirt.org/vuln/ghsa-jx74-cqjv-2c67 https://cve.radiocsirt.org/vuln/pysec-2026-3571 <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary 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&#39;s `callback_url` is used verbatim for an outbound POST that **unconditionally attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET`**. The `callback_url` bypasses the service&#39;s `target_allowed` allowlist (which only inspects `params.target_url`) 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.</p> <p>## Root Cause - `src/core/verification_service.py:363-364` — `/run` has no `Depends`/auth dependency. - `resolve_callback_url` returns the client `callback_url` verbatim (`:315-316`). - `post_callback` attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET` whenever the env var is set (`:327-335`). - `target_allowed` only gates `params.target_url` (`:259`), never `callback_url`. No `validate_url_*` anywhere in the file. - `Dockerfile.verification` CMD = `main(&#39;0.0.0.0&#39;, 8344)`; entrypoint `flyto-verification` in `pyproject.toml:107` → the shipped image binds all interfaces by default.</p> <p>## Impact Unauthenticated (PR:N) readable SSRF to internal/cloud-metadata with a controlled body (C:H, S:C), plus theft of `FLYTO_RUNNER_SECRET` to an attacker host → the attacker can then authenti…</p> <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary 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&#39;s `callback_url` is used verbatim for an outbound POST that **unconditionally attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET`**. The `callback_url` bypasses the service&#39;s `target_allowed` allowlist (which only inspects `params.target_url`) 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.</p> <p>## Root Cause - `src/core/verification_service.py:363-364` — `/run` has no `Depends`/auth dependency. - `resolve_callback_url` returns the client `callback_url` verbatim (`:315-316`). - `post_callback` attaches `X-Internal-Key: $FLYTO_RUNNER_SECRET` whenever the env var is set (`:327-335`). - `target_allowed` only gates `params.target_url` (`:259`), never `callback_url`. No `validate_url_*` anywhere in the file. - `Dockerfile.verification` CMD = `main(&#39;0.0.0.0&#39;, 8344)`; entrypoint `flyto-verification` in `pyproject.toml:107` → the shipped image binds all interfaces by default.</p> <p>## Impact Unauthenticated (PR:N) readable SSRF to internal/cloud-metadata with a controlled body (C:H, S:C), plus theft of `FLYTO_RUNNER_SECRET` to an attacker host → the attacker can then authenti…</p> https://cve.radiocsirt.org/vuln/pysec-2026-3571