Zero Day MonitorZDM
DashboardVulnerabilitiesTrendingZero-DaysNews
Login
ImpressumPrivacy Policy
Zero Day Monitor © 2026
835 articles · 101756 vulns · 36/41 feeds (7d)
← Back to list
5.5
CVE-2026-34730PATCHED
python packaging authority · copier

Copier `_external_data` allows path traversal and absolute-path local file read without unsafe mode

Description

### Summary Copier's `_external_data` 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 `_external_data` 2. Copier renders the configured path string 3. Copier calls `load_answersfile_data(dst_path, rendered_path, warn_on_missing=True)` 4. `load_answersfile_data()` opens `Path(dst_path, answers_file)` directly 5. Parsed YAML becomes available as `_external_data.<name>` during rendering Relevant code: - <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/_main.py#L329-L332> - <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/_user_data.py#L584-L592> The sink is: ```python with Path(dst_path, answers_file).open("rb") as fd: return yaml.safe_load(fd) ``` There is no containment check to ensure the resulting path stays inside the subproject destination. This is notable because Copier already blocks other destination-escape paths. Normal render-path traversal outside the destination is expected to raise `ForbiddenPathError`, and that behavior is explicitly covered by existing tests in <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/tests/test_copy.py#L1289-L1332>. `_external_data` does not apply an equivalent containment check. The public documentation describes `_external_data` values as relative paths "from the subproject destination" in <https://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/docs/configuring.md#L944-L1005>, with examples using `.copier-answers.yml` and `.secrets.yaml`. That clearly supports relative-path usage, but it does not clearly communicate that a template may escape the destination with `../...` or read arbitrary absolute paths. Because this behavior also works without `--UNSAFE`, it seems worth clarifying whether destination-external reads are intended, and if so, whether they should be documented as security-sensitive behavior. ### PoC #### PoC 1: `_external_data` reads outside the destination with `../` ```sh mkdir src dst echo 'token: topsecret' > secret.yml printf '%s\n' '_external_data:' ' secret: ../secret.yml' > src/copier.yml printf '%s\n' '{{ _external_data.secret.token }}' > src/leak.txt.jinja copier copy --overwrite src dst cat dst/leak.txt ``` Expected output: ```text topsecret ``` #### PoC 2: `_external_data` reads an absolute path ```sh mkdir abs-src abs-dst echo 'token: abssecret' > absolute-secret.yml printf '%s\n' '_external_data:' " secret: $(pwd)/absolute-secret.yml" > abs-src/copier.yml printf '%s\n' '{{ _external_data.secret.token }}' > abs-src/leak.txt.jinja copier copy --overwrite abs-src abs-dst cat abs-dst/leak.txt ``` Expected output: ```text abssecret ``` ### Impact If untrusted templates are in scope, a malicious template can read attacker-chosen YAML-parseable local files that are accessible to the user running Copier and expose their contents in rendered output. Practical impact: - Destination-external local file read - Disclosure of YAML/JSON/plain-text-like secrets if they parse successfully under `yaml.safe_load` - Possible without `--UNSAFE`

Affected Products

VendorProductVersions
python packaging authoritycopierpip/copier: <= 9.14.0

References

  • https://github.com/advisories/GHSA-hgjq-p8cr-gg4h(advisory)
  • https://github.com/copier-org/copier/security/advisories/GHSA-hgjq-p8cr-gg4h
  • https://github.com/advisories/GHSA-hgjq-p8cr-gg4h
CVSS 3.15.5 MEDIUM
VectorCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N
CISA KEV❌ No
Actively exploited❌ No
Patch available
copier@9.14.1
CWECWE-22
PublishedApr 1, 2026
Tags
GHSA-hgjq-p8cr-gg4hpip
Trending Score0
Source articles0
Independent0
Info Completeness0/14
Missing: cve_id, title, description, vendor, product, versions, cvss, epss, cwe, kev, exploit, patch, iocs, mitre_attack

Community Vote

0
Login to vote
0 upvotes0 downvotes
No votes yet

Related CVEs (5)

MEDIUMCVE-2026-32794
Improper Certificate Validation vulnerability in Apache Airflow Provider for Databricks. Provider code did not validate certificates for connections to Databricks back-end which could result in a man-
Trending: 20
CRITICALCVE-2026-34935
PraisonAI: OS Command Injection in MCPHandler.parse_mcp_command()
MEDIUMCVE-2026-34881
OpenStack Glance <29.1.1, >=30.0.0 <30.1.1, ==31.0.0 is affected by Server-Side Request Forgery (SSRF). By use of HTTP redirects, an authenticated user can bypass URL validation checks and redirect to
CRITICALCVE-2026-34934
PraisonAI Has Second-Order SQL Injection in `get_all_user_threads`
HIGHCVE-2026-34936
PraisonAI: SSRF via Unvalidated api_base in passthrough() Fallback

Pin to Dashboard

Verification

State: unverified
Confidence: 0%

Vulnerability Timeline

CVE Published
Apr 1, 2026
Patch Available
Apr 1, 2026
Discovered by ZDM
Apr 1, 2026