<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 28 Sep 2026 08:10:24 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-67427 — Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted</title>
      <link>https://db.gcve.eu/vuln/cve-2026-67427</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; flytohub flyto-core&lt;/p&gt;
&lt;p&gt;Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, the workflow engine variable resolver expands ${env.VAR} for any host environment variable without an allowlist or capability policy check, allowing a workflow parameter to bypass the default capability policy denylist for env.get and env.load_dotenv and exfiltrate secrets through allowed modules. This issue is fixed in version 2.26.6.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; flytohub flyto-core&lt;/p&gt;
&lt;p&gt;Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, the workflow engine variable resolver expands ${env.VAR} for any host environment variable without an allowlist or capability policy check, allowing a workflow parameter to bypass the default capability policy denylist for env.get and env.load_dotenv and exfiltrate secrets through allowed modules. This issue is fixed in version 2.26.6.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-67427</guid>
    </item>
    <item>
      <title>GHSA-hr7p-wg7r-hg9m — Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted</title>
      <link>https://db.gcve.eu/vuln/ghsa-hr7p-wg7r-hg9m</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flyto-core&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The capability policy denies the `env.get` and `env.load_dotenv` 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;`src/core/engine/variable_resolver.py`:&lt;/p&gt;
&lt;p&gt;```python
if var_type == &amp;#39;env&amp;#39;:
    if len(parts) &amp;lt; 2:
        return None
    env_var = parts[1]
    return os.getenv(env_var)      # any env var, no allowlist, not covered by module policy
```&lt;/p&gt;
&lt;p&gt;The module policy (`enforce_module_policy` in `module_policy.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.&lt;/p&gt;
&lt;p&gt;## Reproduction&lt;/p&gt;
&lt;p&gt;Save as `envbypass_poc.py`, run with `PYTHONPATH=src/src python envbypass_poc.py`.&lt;/p&gt;
&lt;p&gt;```python
#!/usr/bin/env python3
import os
os.environ[&amp;#34;AWS_SECRET_ACCESS_KEY&amp;#34;] = &amp;#34;AKIA-operator-super-secret-DO-NOT-LEAK&amp;#34;&lt;/p&gt;
&lt;p&gt;from core.module_policy import module_filter
from core.engine.variable_resolver import VariableResolver&lt;/p&gt;
&lt;p&gt;print(&amp;#34;env.get allowed?       &amp;#34;, module_filter.is_allowed(&amp;#34;env.get&amp;#34;))
r = VariableResolver(params={}, context={})
print(&amp;#34;resol…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: flyto-core&lt;/p&gt;
&lt;p&gt;## Summary&lt;/p&gt;
&lt;p&gt;The capability policy denies the `env.get` and `env.load_dotenv` 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&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## Affected code&lt;/p&gt;
&lt;p&gt;`src/core/engine/variable_resolver.py`:&lt;/p&gt;
&lt;p&gt;```python
if var_type == &amp;#39;env&amp;#39;:
    if len(parts) &amp;lt; 2:
        return None
    env_var = parts[1]
    return os.getenv(env_var)      # any env var, no allowlist, not covered by module policy
```&lt;/p&gt;
&lt;p&gt;The module policy (`enforce_module_policy` in `module_policy.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.&lt;/p&gt;
&lt;p&gt;## Reproduction&lt;/p&gt;
&lt;p&gt;Save as `envbypass_poc.py`, run with `PYTHONPATH=src/src python envbypass_poc.py`.&lt;/p&gt;
&lt;p&gt;```python
#!/usr/bin/env python3
import os
os.environ[&amp;#34;AWS_SECRET_ACCESS_KEY&amp;#34;] = &amp;#34;AKIA-operator-super-secret-DO-NOT-LEAK&amp;#34;&lt;/p&gt;
&lt;p&gt;from core.module_policy import module_filter
from core.engine.variable_resolver import VariableResolver&lt;/p&gt;
&lt;p&gt;print(&amp;#34;env.get allowed?       &amp;#34;, module_filter.is_allowed(&amp;#34;env.get&amp;#34;))
r = VariableResolver(params={}, context={})
print(&amp;#34;resol…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-hr7p-wg7r-hg9m</guid>
    </item>
  </channel>
</rss>
