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
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Copier: trust-prefix bypass via path traversal runs tasks unprompted Summary In copier = 9.5.0, <= 9.15.1, the trust setting's prefix match (copier/settings.py) compares the template URL against a trusted prefix with a raw str.startswith and no path normalization, while the URL is normalized when the template is actually fetched (Path.resolve() for local paths; libcurl dot-segment removal for https). A template reference that textually starts with a trusted prefix but contains .. (e.g. https://github.com/trusted-org/../attacker-org/repo.git) is therefore granted trust yet resolves to a different, attacker-controlled template, whose tasks / migrations / jinjaextensions then run without the --trust prompt — arbitrary command execution. Likely CWE-22 (Improper Limitation of a Pathname) in the trust check leading to CWE-94 (code execution). Details trust lets users mark template locations as trusted so copier skips the unsafe-feature gate. A trailing / makes an entry a prefix match…
Recommended action: Upgrade to 9.15.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Copier's externaldata feature allows a template to load YAML files using template-controlled paths. The documentation describes these values as relative paths from the subproject destination, so relative paths themselves appear to be part of the intended feature model. However, the current implementation also allows destination-external reads, including: - Parent-directory paths such as ../secret.yml - Absolute paths such as /tmp/secret.yml and then exposes the parsed contents in rendered output. This is possible without --UNSAFE, which makes the behavior potentially dangerous when Copier is run against untrusted templates. I am not certain this is unintended behavior, but it is security-sensitive and appears important to clarify. Details The relevant flow is: 1. A template defines externaldata 2. Copier renders the configured path string 3. Copier calls loadanswersfiledata(dstpath, renderedpath, warnonmissing=True) 4. loadanswersfiledata() opens Path(dstpath, answersfile)…
Recommended action: Upgrade to 9.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Copier's subdirectory setting is documented as the subdirectory to use as the template root. However, the current implementation accepts parent-directory traversal such as .. and uses it directly when selecting the template root. As a result, a template can escape its own directory and make Copier render files from the parent directory without --UNSAFE. Details The relevant code path is: 1. the template defines subdirectory 2. Copier renders that string 3. templatecopyroot returns self.template.localabspath / subdir 4. Copier walks that directory as the template root Relevant code: - <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/main.py#L1056-L1062 - <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/template.py#L504-L513 The effective sink is: There is no check that the resulting path stays inside the template directory. The documentation for subdirectory describes it as: Subdirectory to use…
Recommended action: Upgrade to 9.14.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently write to arbitrary directories outside the destination path by using directory a symlink along with preservesymlinks: true and a generated directory structure whose rendered path is inside the symlinked directory. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc. [!NOTE] At the time of writing, the exploit is non-deterministic, as Copier walks the template's file tree using os.scandir which yields directory entries in arbitrary order. Reproducible example (may or may not work depending on directory entry yield order): Patches n/a Workarounds n/a References n/a
Recommended action: Upgrade to 9.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently include arbitrary files/directories outside the local template clone location by using symlinks along with preservesymlinks: false (which is Copier's default setting). Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations and hopes for a user to push the generated project to a public location like github.com where the template author can extract the secrets. Reproducible example: - Illegally include a file in the generated project via symlink resolution: - Illegally include a directory in the generated project via symlink resolution: Patches n/a Workarounds n/a References n/a
Recommended action: Upgrade to 9.11.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently write files outside the destination path where a project shall be generated or updated. This is possible when rendering a generated directory structure whose rendered path is either a relative parent path or an absolute path. Constructing such paths is possible using Copier's builtin pathjoin Jinja filter and its builtin copierconf.sep variable, which is the platform-native path separator. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc. Write access via generated relative path Reproducible example: Write access via generated absolute path Reproducible example: - POSIX: - Windows (PowerShell): This scenario is slightly less…
Recommended action: Upgrade to 9.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Copier's current security model shall restrict filesystem access through Jinja: - 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. Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use 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. Arbitrary read access Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps "masks" them with Base64 encoding to…
Recommended action: Upgrade to 9.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.