https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 06:47:57 +0000 https://db.gcve.eu/vuln/cve-2025-55201 <p><strong>Affected:</strong> copier-org copier</p> <p>Copier library and CLI app for rendering project templates. Prior to 9.9.1, a safe template can currently read and write arbitrary files because Copier exposes a few pathlib.Path objects in the Jinja context which have unconstrained I/O methods. This effectively renders the security model w.r.t. filesystem access useless. This vulnerability is fixed in 9.9.1.</p> <p><strong>Affected:</strong> copier-org copier</p> <p>Copier library and CLI app for rendering project templates. Prior to 9.9.1, a safe template can currently read and write arbitrary files because Copier exposes a few pathlib.Path objects in the Jinja context which have unconstrained I/O methods. This effectively renders the security model w.r.t. filesystem access useless. This vulnerability is fixed in 9.9.1.</p> https://db.gcve.eu/vuln/cve-2025-55201 https://db.gcve.eu/vuln/ghsa-3xw7-v6cj-5q8h <p><strong>Affected:</strong> PyPI: copier</p> <p>### Impact</p> <p>Copier&#39;s current security model shall restrict filesystem access through Jinja:</p> <p>- Files can only be read using `{% include ... %}`, which is limited by Jinja to reading files from the subtree of the local template clone in our case. - Files are written in the destination directory according to their counterparts in the template.</p> <p>Copier suggests that it&#39;s safe to generate a project from a safe template, i.e. one that doesn&#39;t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few `pathlib.Path` objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.</p> <p>#### Arbitrary read access</p> <p>Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps &#34;masks&#34; them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like [github.com](http://github.com/) where the template author can extract the secrets.</p> <p>Reproducible example:</p> <p>- Read known file:</p> <p>```shell echo &#34;s3cr3t&#34; &gt; secret.txt mkdir src/ echo &#34;stolen secret: {{ (_copier_conf.dst_path / &#39;..&#39; / &#39;secret.txt&#39;).resolve().read_text(&#39;utf-8&#39;) }}&#34; &gt; src/stolen-secret.txt.jinj…</p> <p><strong>Affected:</strong> PyPI: copier</p> <p>### Impact</p> <p>Copier&#39;s current security model shall restrict filesystem access through Jinja:</p> <p>- Files can only be read using `{% include ... %}`, which is limited by Jinja to reading files from the subtree of the local template clone in our case. - Files are written in the destination directory according to their counterparts in the template.</p> <p>Copier suggests that it&#39;s safe to generate a project from a safe template, i.e. one that doesn&#39;t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few `pathlib.Path` objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.</p> <p>#### Arbitrary read access</p> <p>Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps &#34;masks&#34; them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like [github.com](http://github.com/) where the template author can extract the secrets.</p> <p>Reproducible example:</p> <p>- Read known file:</p> <p>```shell echo &#34;s3cr3t&#34; &gt; secret.txt mkdir src/ echo &#34;stolen secret: {{ (_copier_conf.dst_path / &#39;..&#39; / &#39;secret.txt&#39;).resolve().read_text(&#39;utf-8&#39;) }}&#34; &gt; src/stolen-secret.txt.jinj…</p> https://db.gcve.eu/vuln/ghsa-3xw7-v6cj-5q8h https://db.gcve.eu/vuln/pysec-2026-1271 <p><strong>Affected:</strong> PyPI: copier</p> <p>### Impact</p> <p>Copier&#39;s current security model shall restrict filesystem access through Jinja:</p> <p>- Files can only be read using `{% include ... %}`, which is limited by Jinja to reading files from the subtree of the local template clone in our case. - Files are written in the destination directory according to their counterparts in the template.</p> <p>Copier suggests that it&#39;s safe to generate a project from a safe template, i.e. one that doesn&#39;t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few `pathlib.Path` objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.</p> <p>#### Arbitrary read access</p> <p>Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps &#34;masks&#34; them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like [github.com](http://github.com/) where the template author can extract the secrets.</p> <p>Reproducible example:</p> <p>- Read known file:</p> <p>```shell echo &#34;s3cr3t&#34; &gt; secret.txt mkdir src/ echo &#34;stolen secret: {{ (_copier_conf.dst_path / &#39;..&#39; / &#39;secret.txt&#39;).resolve().read_text(&#39;utf-8&#39;) }}&#34; &gt; src/stolen-secret.txt.jinj…</p> <p><strong>Affected:</strong> PyPI: copier</p> <p>### Impact</p> <p>Copier&#39;s current security model shall restrict filesystem access through Jinja:</p> <p>- Files can only be read using `{% include ... %}`, which is limited by Jinja to reading files from the subtree of the local template clone in our case. - Files are written in the destination directory according to their counterparts in the template.</p> <p>Copier suggests that it&#39;s safe to generate a project from a safe template, i.e. one that doesn&#39;t use [unsafe](https://copier.readthedocs.io/en/stable/configuring/#unsafe) features like custom Jinja extensions which would require passing the `--UNSAFE,--trust` flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few `pathlib.Path` objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.</p> <p>#### Arbitrary read access</p> <p>Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps &#34;masks&#34; them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like [github.com](http://github.com/) where the template author can extract the secrets.</p> <p>Reproducible example:</p> <p>- Read known file:</p> <p>```shell echo &#34;s3cr3t&#34; &gt; secret.txt mkdir src/ echo &#34;stolen secret: {{ (_copier_conf.dst_path / &#39;..&#39; / &#39;secret.txt&#39;).resolve().read_text(&#39;utf-8&#39;) }}&#34; &gt; src/stolen-secret.txt.jinj…</p> https://db.gcve.eu/vuln/pysec-2026-1271