https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 00:24:01 +0000 https://cve.radiocsirt.org/vuln/cve-2026-67429 <p><strong>Affected:</strong> flytohub flyto-core</p> <p>Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, image.download and related file-writing modules use caller-controlled output_dir instead of validate_path_with_env_config and its FLYTO_SANDBOX_DIR confinement, allowing attacker-controlled response bytes to be written to arbitrary filesystem paths the process can access. This issue is fixed in version 2.26.6.</p> <p><strong>Affected:</strong> flytohub flyto-core</p> <p>Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, image.download and related file-writing modules use caller-controlled output_dir instead of validate_path_with_env_config and its FLYTO_SANDBOX_DIR confinement, allowing attacker-controlled response bytes to be written to arbitrary filesystem paths the process can access. This issue is fixed in version 2.26.6.</p> https://cve.radiocsirt.org/vuln/cve-2026-67429 https://cve.radiocsirt.org/vuln/ghsa-2956-977x-2w3r <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary</p> <p>`image.download` fetches a URL and writes the response to disk. It does not use the central path guard (`validate_path_with_env_config`, which confines writes to `FLYTO_SANDBOX_DIR`); instead it confines the output to `output_dir`, but `output_dir` 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.</p> <p>## Affected code</p> <p>`src/core/modules/atomic/image/download.py`:</p> <p>```python output_path = params.get(&#39;output_path&#39;) output_dir = params.get(&#39;output_dir&#39;, &#39;/tmp&#39;) # caller-controlled base ... base_real = os.path.realpath(output_dir) target_real = os.path.realpath(output_path) if os.path.commonpath([base_real, target_real]) != base_real: raise Exception(&#39;Invalid file path&#39;) # base is attacker-chosen, so always passes ... content = await response.read() # attacker-hosted bytes with open(target_real, &#39;wb&#39;) as f: f.write(content) ```</p> <p>`commonpath` is used correctly, but the base is caller-supplied, so setting `output_dir=&#39;/&#39;` passes any target. `file.write`, by contrast, uses `validate_path_with_env_config()` and stays inside `FLYTO_SANDBOX_DIR`.</p> <p>This is not isolated to `image.download`. Most other file-writing modules write to a caller `output_path` with no path check at all: `image.convert`, `image.resize`, `image.crop`, `image.compress`, `image.rotate`, `…</p> <p><strong>Affected:</strong> PyPI: flyto-core</p> <p>## Summary</p> <p>`image.download` fetches a URL and writes the response to disk. It does not use the central path guard (`validate_path_with_env_config`, which confines writes to `FLYTO_SANDBOX_DIR`); instead it confines the output to `output_dir`, but `output_dir` 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.</p> <p>## Affected code</p> <p>`src/core/modules/atomic/image/download.py`:</p> <p>```python output_path = params.get(&#39;output_path&#39;) output_dir = params.get(&#39;output_dir&#39;, &#39;/tmp&#39;) # caller-controlled base ... base_real = os.path.realpath(output_dir) target_real = os.path.realpath(output_path) if os.path.commonpath([base_real, target_real]) != base_real: raise Exception(&#39;Invalid file path&#39;) # base is attacker-chosen, so always passes ... content = await response.read() # attacker-hosted bytes with open(target_real, &#39;wb&#39;) as f: f.write(content) ```</p> <p>`commonpath` is used correctly, but the base is caller-supplied, so setting `output_dir=&#39;/&#39;` passes any target. `file.write`, by contrast, uses `validate_path_with_env_config()` and stays inside `FLYTO_SANDBOX_DIR`.</p> <p>This is not isolated to `image.download`. Most other file-writing modules write to a caller `output_path` with no path check at all: `image.convert`, `image.resize`, `image.crop`, `image.compress`, `image.rotate`, `…</p> https://cve.radiocsirt.org/vuln/ghsa-2956-977x-2w3r