python.org Vulnerability Could Have Allowed Admin-Level Release API Requests

A serious authentication bypass in the python.org release management API could have allowed an attacker to send admin-level API requests by pairing an administrator username with any API key.

The issue affected release metadata used by python.org downloads. According to the Python Security Response Team report, an attacker could have changed the URLs shown to users for Python release files and related verification materials.

Python maintainers patched the flaw within 48 hours of the February 23, 2026 report from Splitline Ng of the DEVCORE Research Team. The team later said it found no evidence that anyone exploited the vulnerability.

What Happened With the python.org API Vulnerability

The vulnerability existed in the release management API for python.org. The vulnerable logic mixed guest authentication behavior with API key authentication, which allowed a request with an admin username and arbitrary API key to pass with admin privileges.

The issue mattered because python.org acts as a trusted distribution point for Python releases. Many developers, build systems, Linux distributions, and automation pipelines rely on release metadata from the site.

The fix arrived through python/pythondotorg pull request 2946, which separated the guest and API key authentication branches. The patch was reviewed and merged on February 24, 2026.

Item	Details
Vulnerability type	Authentication bypass
Affected system	python.org release management API
Reported by	Splitline Ng, DEVCORE Research Team
Reported date	February 23, 2026
Patch status	Patched within 48 hours
Exploitation status	No evidence of exploitation found

Why the Flaw Was Dangerous

The flaw did not let attackers replace Python binaries directly on python.org. However, it could have allowed them to modify release and file metadata that controls what download URLs users see.

That could have created a serious software supply chain risk. If a user or automated system followed a malicious replacement URL, they might have downloaded files from an attacker-controlled location instead of python.org.

The risk also involved verification materials. The PSRT said the vulnerable API could have affected URLs for release files and related verification material, including signature resources that help users validate downloads.

Python Team Found No Evidence of Exploitation

After the patch, Python maintainers reviewed logs, database backups, and artifact signatures. The PSRT disclosure says the review found no evidence that the vulnerability had been exploited.

The team also verified Python artifacts using Sigstore and PGP materials. For Python 2.5 through Python 3.13, available PGP signatures were checked. Python 3.14 and later releases were checked with Sigstore because newer releases no longer provide PGP materials.

That change follows PEP 761, which moves CPython toward Sigstore-only verification for newer release managers. The PEP says Sigstore reduces the need for long-lived private keys and ties signatures to short-lived identity-based credentials.

• The vulnerability affected release metadata, not existing binary files in place.
• The patch was applied on February 24, 2026.
• DEVCORE confirmed the proof of concept no longer worked after the fix.
• Python maintainers reviewed logs and database backups.
• No evidence of exploitation was found.

What the Patch Changed

The first patch separated the vulnerable authentication paths so that guest mode and API key mode no longer overlap. That change closed the core authentication bypass.

The authentication patch also documented the different behavior between the two request types. This makes future review easier because the API no longer depends on unclear shared logic for separate authentication flows.

Python maintainers then added hardening around release file URLs. A separate URL hardening patch made release file fields reject URLs that do not start with python.org-controlled addresses.

Extra Hardening Reduced the Redirect Risk

The additional URL restrictions are important because they reduce damage even if a future authentication or authorization bug appears. New release metadata writes must point to approved python.org URLs.

That means an attacker would have a harder time redirecting users to a separate malicious domain through release metadata. The python.org URL validation work also added constraints around release file properties.

A later change from Trail of Bits strengthened URL validation further. Pull request 3014 rejects new or changed non-HTTPS release file URL values and validates sidecar URLs against the artifact they describe.

Security Change	Purpose
Authentication branch separation	Stops guest authentication behavior from mixing with API key authentication
Negative authentication tests	Checks failure paths so similar bugs are easier to catch
python.org URL restrictions	Blocks attacker-controlled release metadata URLs
HTTPS-only validation	Prevents new or changed release file URLs from using insecure HTTP
Longer log retention	Extends audit coverage from 3 days to 30 days

Trail of Bits Audit Added More Checks

Trail of Bits audited python.org and the Python release process in June 2026. The review added more validation around release metadata and did not find additional authentication or authorization issues, according to Python’s incident report.

The release-file metadata validation patch applied the checks across model forms, DRF writes, and Tastypie writes. It also added regression tests for create and update paths.

The audit was funded by OpenAI, while the mitigations were reviewed and applied by Seth Larson. Python maintainers also used additional security review methods before publishing the final incident report on June 23, 2026.

How Python Release Verification Works Now

CPython release artifacts have used Sigstore signatures since several older maintenance releases, including Python 3.11.0 and related patch versions. The Python Sigstore guide explains how users can verify release artifacts with bundled .sigstore files.

Starting with Python 3.14, Sigstore became the only signing and verification method for release artifacts. Older releases before the 3.14 series still include legacy OpenPGP signatures where available.

The policy change comes from PEP 761, which recommends Sigstore adoption for future CPython artifact verification. The PEP also states that already published PGP signatures remain available for older releases.

What Developers Should Do

Most Python users do not need to take emergency action because the vulnerability was patched months before public disclosure and no exploitation was found. Still, the incident highlights why trusted download and verification workflows matter.

Developers and organizations should download Python only from trusted official sources or known package managers. Build systems should verify artifacts where practical and avoid blindly trusting changed metadata from any software distribution site.

Teams that maintain internal mirrors or automated Python builds should review how they validate release artifacts. The official Sigstore verification instructions provide the current guidance for checking CPython release files.

• Use official python.org download pages or trusted package repositories.
• Verify release artifacts in automated build systems where possible.
• Prefer HTTPS-only sources for release files and sidecar metadata.
• Monitor internal mirrors for unexpected URL or metadata changes.
• Keep build pipelines ready to rotate or re-check trusted sources after security incidents.

FAQ