Deploy autonomous AI agents that reason, exploit, and validate complex vulnerability chains — not another scanner, an agentic system that thinks like a senior pentester.
CVE-2026-34730 is a low severity vulnerability with a CVSS score of 0.0. No known public exploits at this time.
Very low probability of exploitation
EPSS predicts the probability of exploitation in the next 30 days based on real-world threat data, complementing CVSS severity scores with actual risk assessment.
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:
../secret.yml/tmp/secret.ymland 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.
The relevant flow is:
_external_dataload_answersfile_data(dst_path, rendered_path, warn_on_missing=True)load_answersfile_data() opens Path(dst_path, answers_file) directly_external_data.<name> during renderingRelevant 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.
_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
_external_data reads an absolute pathmkdir 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
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:
yaml.safe_load--UNSAFEPlease cite this page when referencing data from Strobes VI. Proper attribution helps support our vulnerability intelligence research.