CVE-2026-24049

What it actually does

The vulnerable wheel unpack logic in versions 0.40.0 through 0.46.1 can apply file permissions to a path taken directly from a wheel archive header after extraction path sanitization has already occurred. A crafted wheel can therefore cause chmod-style permission changes on files outside the intended extraction directory if the unpacking process has sufficient filesystem rights. The primary technical risk is unauthorized permission modification of sensitive files, which can enable privilege escalation, tampering with scripts or configuration, weakening SSH key protections, or preparing files for later arbitrary code execution. The issue requires a user, automation job, or build process to unpack a malicious wheel file locally; it is not a direct unauthenticated network exploit.

Why it matters to the business

Organizations that unpack third-party, untrusted, or externally supplied Python wheel files in developer workstations, CI/CD systems, build containers, packaging pipelines, or appliance images could have critical files made writable or executable by an attacker. If the unpacking process runs with elevated privileges, the impact can include compromised build infrastructure, modified software artifacts, local privilege escalation, service disruption, or persistent unauthorized access. The current EPSS is low and the issue is not listed in CISA KEV or known ransomware use, but the flaw is 200 days old and affects common Python packaging workflows, so remediation should be prioritized where automated unpacking of untrusted wheels occurs.

How an attack unfolds

An attacker creates a malicious Python wheel whose archive metadata contains a filename or path intended to reference a sensitive location outside the extraction directory, along with permission bits that make the target file more permissive. The attacker then gets a victim, developer tool, dependency review process, CI job, package mirror, or build pipeline to run wheel unpack against that file. During extraction, the file placement may be sanitized into the intended output directory, but the subsequent permission-setting operation uses the original archive header path instead of the sanitized extraction path. If the process has access to the referenced target, permissions on that outside file can be changed. The attacker can then take advantage of the weakened permissions by modifying sensitive configuration, writable scripts, startup files, SSH-related files, or other files that influence execution or access. In high-privilege build or container contexts, this can become local privilege escalation, build tampering, or arbitrary code execution through later execution of modified files.

How to fix it

Upgrade wheel to version 0.46.2 or later wherever wheel files are unpacked or processed. For the listed affected packages, update prometheus-fips-3.7 on MinimOS to 3.7.3-r0 or later, and update pypa/wheel to a version containing commit eba4036ccaca4e2d0c5b5bf3e3be59b2b2877d6b or the released 0.46.2 fix. Rebuild base images, CI runner images, developer containers, and packaging tools that vendor or pin vulnerable wheel versions. As compensating controls, do not unpack untrusted wheels as root or with broad filesystem permissions, run package inspection in disposable sandboxes or containers with read-only mounts, restrict write access to sensitive host paths, and scan incoming wheel archives for absolute paths, parent-directory traversal segments, and suspicious permission modes before processing. Treat any previously processed untrusted wheel as potentially unsafe until the processing environment and file permissions have been reviewed.

How to confirm the fix worked

Confirm the installed version with commands such as python -m wheel version, wheel version, pip show wheel, pip freeze, package manager inventory, SBOM output, and container image scans; vulnerable versions are 0.40.0 through 0.46.1, and fixed versions are 0.46.2 or later. Validate operating-system packages against vendor advisories, including prometheus-fips-3.7 fixed in 3.7.3-r0. Check CI runner images, build containers, virtual environments, developer toolchains, and vendored dependencies rather than only system Python packages. In an isolated non-production sandbox, process a benign test wheel designed to exercise unsafe path handling and verify that permission changes are confined to the intended extraction directory and never affect files outside it. Compare permissions on sensitive files before and after testing, and confirm that automation no longer processes untrusted wheels with elevated privileges.

Typical attack path

1. Identify a workflow where Python wheel files are unpacked, inspected, converted, or processed using vulnerable wheel versions 0.40.0 through 0.46.1.
2. Craft or supply a malicious .whl archive containing archive header paths that reference files outside the intended unpack directory and permission bits that weaken those files.
3. Deliver the wheel through a dependency submission, package review process, source repository, artifact store, build input, email attachment, or other supply-chain path.
4. Cause a user or automated process to run wheel unpack or an equivalent unpack operation against the malicious wheel.
5. Rely on the vulnerable chmod operation to apply permissions to the attacker-controlled header path rather than only to the sanitized extracted file path.
6. Use the newly permissive target file to modify scripts, configuration, credentials-related files, or execution paths.
7. Trigger execution, authentication, service restart, or another follow-on action that makes the permission change useful for privilege escalation, persistence, tampering, or disruption.

How to detect it

To determine whether exploitation already occurred, review endpoint telemetry, shell history, CI/CD logs, build job logs, package inspection logs, artifact repository records, and Linux audit logs for wheel unpack operations against untrusted or unusual .whl files. Correlate those events with file permission changes, especially chmod, fchmod, chown-adjacent activity, or mode changes affecting sensitive files outside the wheel extraction directory. On Linux systems, inspect auditd records for chmod/fchmod/fchmodat syscalls by python, python3, wheel, pip-related wrappers, build tools, or CI runner users shortly after a wheel unpack command. Review filesystem metadata and backups for unexpected mode changes on /etc/passwd, /etc/shadow, /etc/sudoers, SSH authorized_keys files, private keys, service unit files, cron files, shell startup scripts, application configuration, and build scripts. Examine suspicious wheel artifacts with archive listing tools and look for member names containing absolute paths, ../ traversal, or permission modes that grant group/world write access or unexpected execute bits. If available, compare current file permissions against known-good baselines from configuration management, package verification tools, or host integrity monitoring. There are no public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should focus on behavioral evidence: vulnerable wheel unpack execution followed by unexpected permission changes outside the extraction path.

• wheel unpack
• python -m wheel unpack
• python3 -m wheel unpack
• .whl
• ../
• ../../
• ../../../
• /etc/passwd
• /etc/shadow
• /etc/sudoers
• /root/.ssh/authorized_keys
• /.ssh/authorized_keys
• /.ssh/id_rsa
• /etc/cron.d/
• /etc/crontab
• /etc/systemd/system/
• chmod 777
• chmod 666
• mode=0777
• mode=0666
• fchmodat
• SYSCALL=chmod
• SYSCALL=fchmod
• SYSCALL=fchmodat

What your security team should do

• Inventory all locations where Python wheel files are unpacked, inspected, mirrored, converted, or processed, with priority on CI/CD, build systems, package review workflows, and container image builds.
• Upgrade wheel to 0.46.2 or later and update affected downstream packages, including prometheus-fips-3.7 to 3.7.3-r0 or later where applicable.
• Rebuild and redeploy golden images, build runner images, developer containers, and virtual environments that may contain vulnerable wheel versions.
• Block or quarantine untrusted .whl files containing absolute paths, parent-directory traversal sequences, or suspicious permission modes until they are reviewed in a sandbox.
• Ensure wheel unpacking and dependency inspection jobs run as non-root users inside isolated containers with read-only mounts for host-sensitive paths.
• Review historical CI logs, shell histories, artifact processing records, and audit logs for wheel unpack activity involving untrusted or externally supplied wheels.
• Perform targeted permission audits on sensitive files in environments where vulnerable wheel versions processed untrusted input.
• Add detections for wheel unpack command execution followed by chmod or permission changes to sensitive paths such as /etc, SSH directories, service files, shell startup files, and build scripts.
• Treat this as supply-chain relevant even though it is not currently in KEV and has low EPSS, because exploitation depends on workflow exposure rather than internet-facing reachability.