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.
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.
InstallDestination.write_to_fs() in src/pdm/installers/installers.py overrides the base class to add symlink/hardlink support but replaces the safe _path_with_destdir() (which validates via Path.resolve() + is_relative_to()) with a bare os.path.join() that performs no path validation. A malicious wheel with traversal entries can write arbitrary files. Same class as Poetry CVE-2026-34591. Fix ready at: https://github.com/pdm-project/pdm/pull/3787.
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 …