Evidence used
- No CISA KEV confirmation is currently recorded.
- A structured source references public exploit or proof-of-concept material.
- EPSS is 0.51% for the current model date.
BlackTreeCVE Intelligencepdm-project · pdm
Official source article: GitHub GHSA-J44V-MMF2-XVM9 ↗. Check the applicable product and release in the original source.
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance. Verified remediation exists for at least one product or source, but 1 structured product or package state remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Verified remediation exists for at least one product or source, but 1 structured product or package state remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Debian findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
BlackTree has verified remediation for at least one product or source, but the relevant distribution still reports no fixed package for 1 affected package state shown here. Treat those rows as affected with no fix until that distribution publishes a fixed version.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | pdm | Vendor fix publishedDebian records a fixed source-package version for this release. | 2.20.0.post1+ds1-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian bookwormbookworm · source | pdm | Affected, no fix publishedDebian currently tracks this release as open. | Not published in this feed | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian forkyforky · source | pdm | Vendor fix publishedDebian records a fixed source-package version for this release. | 2.20.0.post1+ds1-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian sidsid · source | pdm | Vendor fix publishedDebian records a fixed source-package version for this release. | 2.20.0.post1+ds1-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
High technical severity with public exploit material referenced by a structured source; prioritise exposed affected systems while verifying vendor guidance. Verified remediation exists for at least one product or source, but 1 structured product or package state remain unresolved. Apply remediation only to the exact product branch confirmed by its source.
Fix availability varies by productpdm is a Python package and dependency manager supporting the latest PEP standards. It's possible to craft a malicious `pdm.lock` file that could allow e.g. an insider or a malicious open source project to appear to depend on a trusted PyPI project, but actually install another project. A project `foo` can be targeted by creating the project `foo-2` and uploading the file `foo-2-2.tar.gz` to pypi.org. PyPI will see this as project `foo-2` version `2`, while PDM will see this as project `foo` version `2-2`. The version must only be `parseable as a version` and the filename must be a prefix of the project name, but it's not verified to match the version being installed. Version `2-2` is also not a valid normalized version per PEP 440. Matching the project name exactly (not just prefix) would fix the issue. When installing dependencies with PDM, what's actually installed could differ from what's listed in `pyproject.toml` (including arbitrary code execution on install). It could also be used for downgrade attacks by only changing the version. This issue has been addressed in commit `6853e2642df` which is included in release version `2.9.4`. Users are advised to upgrade. There are no known workarounds for this vulnerability.
pdm is a Python package and dependency manager supporting the latest PEP standards. It's possible to craft a malicious `pdm.lock` file that could allow e.g. an insider or a malicious open source project to appear to depend on a trusted PyPI project, but actually install another project. A project `foo` can be targeted by creating the project `foo-2` and uploading the file `foo-2-2.tar.gz` to pypi.org. PyPI will see this as project `foo-2` version `2`, while PDM will see this as project `foo` version `2-2`. The version must only be `parseable as a version` and the filename must be a prefix of the project name, but it's not verified to match the version being installed. Version `2-2` is also not a valid normalized version per PEP 440. Matching the project name exactly (not just prefix) would fix the issue. When installing dependencies with PDM, what's actually installed could differ from what's listed in `pyproject.toml` (including arbitrary code execution on install). It could also be used for downgrade attacks by only changing the version. This issue has been addressed in commit `6853e2642df` which is included in release version `2.9.4`. Users are advised to upgrade. There are no known workarounds for this vulnerability.
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
An attacker operating through local access may attempt exploitation without authentication after a user interaction. If successful, the issue may execute code or commands in the affected security context.
pdm is a Python package and dependency manager supporting the latest PEP standards. It's possible to craft a malicious `pdm.lock` file that could allow e.g. an insider or a malicious open source project to appear to depend on a trusted PyPI project, but actually install another project. A project `foo` can be targeted by creating the project `foo-2` and uploading the file `foo-2-2.tar.gz` to pypi.org. PyPI will see this as project `foo-2` version `2`, while PDM will see this as project `foo` version `2-2`. The version must only be `parseable as a version` and the filename must be a prefix of the project name, but it's not verified to match the version being installed. Version `2-2` is also not a valid normalized version per PEP 440. Matching the project name exactly (not just prefix) would fix the issue. When installing dependencies with PDM, what's actually installed could differ from what's listed in `pyproject.toml` (including arbitrary code execution on install). It could also be used for downgrade attacks by only changing the version. This issue has been addressed in commit `6853e2642df` which is included in release version `2.9.4`. Users are advised to upgrade. There are no known workarounds for this vulnerability.
The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
An attacker operating through local access may attempt exploitation without authentication after a user interaction. If successful, the issue may execute code or commands in the affected security context.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
A structured CVE source labels at least one public reference as exploit material. BlackTree has not independently validated that it is safe, reliable or weaponised.
CWE-20: Improper Input Validation. The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:HCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 20 Oct 2023 · Last source change 12 Sept 2024, 15:01 UTC · CWE-20 · Improper Input Validation
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.