CVE-2026-3479: 
Python Interpreter vulnerability analysis and mitigation

CVE-2026-3479 is a path traversal vulnerability (CWE-22) in CPython's pkgutil.get_data() function, where the resource argument was not validated as documented, allowing callers to traverse outside the intended package directory. It affects CPython versions prior to 3.15.0 (with backports targeting 3.10–3.14). The CVE is marked DISPUTED: the Python project subsequently clarified that the documentation was incorrect and that pkgutil.get_data() shares the same security model as open(), meaning path traversal is by design for trusted input; the documentation has been updated accordingly. The CVSS v3.1 base score is 3.3 (Low), and the CVSS v4.0 base score is 0.0 (None) (Red Hat Advisory, Red Hat Bugzilla, ENISA EUVD). The vulnerability was disclosed on March 18, 2026, by researcher Stan Ulbrych (StanFromIreland) via the CPython issue tracker (CPython Issue).

The root cause is classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The pkgutil.get_data() function in CPython's standard library accepted resource arguments containing .. (parent directory) components or absolute paths without raising an error, despite documentation stating these were forbidden. An attacker with local access who can influence the resource argument passed to pkgutil.get_data() could supply a path such as ../../../etc/passwd or an absolute path to read files outside the package directory. The initial fix (commit bcdf231) added a ValueError for absolute paths and .. components; however, this was later reverted (commit 5af6ce3) in favor of a documentation clarification stating the function is intended for trusted input only, with the same security model as open() (CPython PR #146122, CPython Commit Revert).

Successful exploitation requires local access and the ability to influence the resource argument passed to pkgutil.get_data(). An attacker could read arbitrary files accessible to the Python process, potentially exposing sensitive data such as configuration files, credentials, or system files (e.g., /etc/passwd). There is no impact on confidentiality beyond file read access, and no integrity or availability impact is assessed (Red Hat Advisory, ENISA EUVD).

1. Identify a target application: Find a Python application that calls pkgutil.get_data(package, resource) where the resource argument is partially or fully user-controlled.
2. Craft a traversal payload: Prepare a path traversal string such as ../../../etc/passwd or an absolute path like /etc/shadow as the resource argument.
3. Inject the payload: Supply the crafted string as the resource argument to the vulnerable pkgutil.get_data() call, either through application input, a configuration file, or another injection point.
4. Read arbitrary files: The function resolves the path relative to the package directory without validation (on unpatched versions), returning the contents of the targeted file outside the package boundary (CPython PR #146122, CPython Commit).

The Python Software Foundation initially released a fix in CPython 3.15.0 (main branch, commit bcdf231) and backported it to branches 3.10 through 3.14. However, the fix was subsequently reverted in favor of a documentation update clarifying that pkgutil.get_data() is intended for trusted input only and shares the security model of open(). The recommended mitigation is to not pass user-controlled input as the resource argument to pkgutil.get_data(), and to validate any such input (e.g., require alphanumeric filenames with known extensions). Organizations using CPython should apply available vendor patches from Red Hat, SUSE, Amazon Linux, Fedora, and openSUSE as released (Red Hat Advisory, Red Hat Bugzilla, CPython Commit Revert).

The Python Security Response Team (PSRT) initially treated this as a security issue because the behavior violated documented restrictions. After further review, the project disputed the CVE, clarifying that the documentation was incorrect and that pkgutil.get_data() was never intended to enforce path restrictions — it has always shared the security model of open(). The documentation was updated accordingly, and the enforcement patch was reverted. Red Hat, SUSE, Amazon Linux, Fedora, and openSUSE all issued advisories and package updates in response to the original CVE disclosure (CPython Issue, Red Hat Advisory).