GHSA-xjhm-gp88-8pfx is a medium-severity (CVSS 5.5) CWE-61 vulnerability in copier. O3 Security confirms whether GHSA-xjhm-gp88-8pfx is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Copier safe template has arbitrary filesystem read access via symlinks when _preserve_symlinks: false
Real-World Exposure
copierReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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 include arbitrary files/directories outside the local template clone location by using symlinks along with _preserve_symlinks: false (which is Copier's default setting).
Imagine, e.g., a malicious template author who creates a template that reads SSH keys or other secrets from well-known locations 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:
-
Illegally include a file in the generated project via symlink resolution:
echo "s3cr3t" > secret.txt mkdir src/ pushd src/ ln -s ../secret.txt stolen-secret.txt popd uvx copier copy src/ dst/ cat dst/stolen-secret.txt #s3cr3t -
Illegally include a directory in the generated project via symlink resolution:
mkdir secrets/ pushd secrets/ echo "s3cr3t" > secret.txt popd mkdir src/ pushd src/ ln -s ../secrets stolen-secrets popd uvx copier copy src/ dst/ tree dst/ # dst/ # └── stolen-secrets # └── secret.txt # # 1 directory, 1 file cat dst/stolen-secrets/secret.txt # s3cr3t
Patches
n/a
Workarounds
n/a
References
n/a
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | copier | all versions | 9.11.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for copier. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update copier to 9.11.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xjhm-gp88-8pfx is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-xjhm-gp88-8pfx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-xjhm-gp88-8pfx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xjhm-gp88-8pfx in your dependencies?
O3 detects GHSA-xjhm-gp88-8pfx across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.