The Python Package Index Blog

PyPI has completed its second audit

Mike Fiedler — Thu, 16 Apr 2026 19:00:00 +0000

In 2023 PyPI completed its first security audit, and I am proud to announce that we have now completed our second external security audit.

This work was funded by the Sovereign Tech Agency, a supporter of Open Source security-related improvements, partnering with Trail of Bits to perform the audit. Thanks to ongoing support from Alpha-Omega, my role at the PSF enabled me to focus on rapid remediation of the findings.

This time around, there's no three-part series, as the scope was narrower, focused only on PyPI's codebase and behaviors. Read on for a summary of issues identified, their resolutions, and more details about the audit process.

The full audit report can be found on the Trail of Bits publication page. I highly recommend reading that for the fullest context first.

Findings

Here's a table of the findings, status, and links to the relevant pull requests where applicable:

ID	Title	Severity	Difficulty	Status
TOB-PYPI26-1	OIDC JTI anti-replay lock expires before JWT leeway window closes	Medium	High	Remediated
TOB-PYPI26-2	OIDC token minting is vulnerable to a TOCTOU race in JTI anti-replay	Low	High	Remediated
TOB-PYPI26-3	Verification badge bypass on the home page and download URLs	Low	Low	Remediated
TOB-PYPI26-4	Project-level token deletion audit events silently dropped due to data structure mismatch	Low	Low	Remediated
TOB-PYPI26-5	Password reset leaks privileged account status	Low	High	Remediated
TOB-PYPI26-6	IP ban bypass via macaroon API token authentication	Informational	High	Accepted
TOB-PYPI26-7	Moderators can modify organization applications due to a missing write permission check	Low	High	Remediated
TOB-PYPI26-8	Organization members can invite new owners due to a missing manage permission check	High	Medium	Remediated
TOB-PYPI26-9	TOTP replay prevention bypass via space normalization mismatch between validation and storage	Informational	High	Remediated
TOB-PYPI26-10	Wheel METADATA is served to installers without validation against upload metadata	Low	Low	Accepted
TOB-PYPI26-11	IDOR in API Token Deletion Allows Any Authenticated User to Delete Other Users' Macaroons	Low	High	Remediated
TOB-PYPI26-12	GitHub OIDC publisher lookup lacks issuer URL isolation for custom GHES issuers	Informational	High	Remediated 1, 2
TOB-PYPI26-13	Organization-scoped project associations persist after project transfer or removal	High	High	Remediated
TOB-PYPI26-14	Admin flag changes lack audit logging	Informational	High	Remediated

Of the 14 findings, I used a combination of Severity and Difficulty to determine which ones to work on first, and which ones to accept for now.

There were no Critical severity findings, 2 High, 1 Medium, 7 Low, and 3 Informational severity findings.

All but 2 findings have been remediated, and the remaining 2 are accepted for now. More details on the accepted findings below, but in general these were accepted because they require significant effort to remediate, and the risk they pose is relatively low.

To reiterate, the published report PDF goes into deeper detail about each finding, so I recommend reading that for the fullest context first.

Details

For some of the Remediated entries and all the Accepted ones, I'll go into more detail below.

TOB-PYPI26-1: OIDC JTI anti-replay lock expires before JWT leeway window closes

PyPI's Trusted Publishing flow uses OIDC JWTs issued by CI providers to mint short-lived upload tokens. Each JWT contains a jti (JWT Token Identifier) claim that should be single-use. To enforce this, we store each jti in cache (Redis) with an expiration of exp + 5 seconds, and check whether it already exists before accepting a new token.

The problem: PyJWT is configured with leeway=30, meaning it accepts tokens up to 30 seconds past their exp claim. This created a 25-second window (from exp + 5 to exp + 30) where the cache key had already been evicted, but the JWT still passed signature verification. During that window, a replayed token would pass both the signature check and the jti uniqueness check.

The fix was straightforward -- align the cache TTL to outlive the full leeway window by setting the expiration to exp + leeway + margin. I also took the opportunity to centralize these time-window constants so they're derived from a shared configuration, preventing future drift when one value is updated without the other.

TOB-PYPI26-6: IP ban bypass via macaroon API token authentication

Accepted for now.

PyPI administrators can ban IP addresses through the admin dashboard. The session authentication policy enforces this by checking the IP against the ban list before returning an identity. However, the macaroon (API token) authentication policy doesn't perform this same check. This means a user with a valid API token could continue uploading packages from a banned IP address.

I've accepted this finding for now. IP bans are a relatively blunt tool that we use sparingly, introduced late last year to mitigate a specific wave of abuse. The practical risk here is low - if we've identified a malicious actor, we have other mechanisms to disable their account entirely. That said, it's a gap worth closing, and we'll likely address it as part of broader work on making security controls consistent across all authentication methods.

TOB-PYPI26-8: Organization members can invite new owners due to a missing manage permission check

This was the highest-severity finding in the audit, and one I prioritized immediately.

The manage_organization_roles view handled both GET (viewing the people page) and POST (sending invitations) under a single @view_config decorator that only required OrganizationsRead permission. This meant any organization member could send invitations with any role - including Owner - to any PyPI user.

The irony is that we already had the correct pattern elsewhere in the codebase. Views like resend_organization_invitation and change_organization_role correctly use separate @view_config decorators for GET and POST with distinct permission requirements. This one was simply missed.

The fix was to split the view configuration: GET requires OrganizationsRead, POST requires OrganizationsManage. As part of the audit, Trail of Bits also developed a custom CodeQL query to detect this class of issue - views that handle state-changing POST requests under a read-only permission check. I'll integrate that into our CI to catch this pattern going forward.

TOB-PYPI26-10: Wheel METADATA is served to installers without validation against upload metadata

Accepted for now.

This is a nuanced one. When a wheel is uploaded to PyPI, we store two independent sources of metadata: the form-declared metadata from the upload request (which populates the database and the JSON API), and the embedded .dist-info/METADATA file extracted from the wheel itself (which is served via PEP 658 to pip for dependency resolution).

These two sources are never compared. In theory, an attacker could embed hidden dependencies in the wheel's METADATA that pip would install, but that security tools querying the JSON API would never see.

We've accepted this for now because the fix is non-trivial. Properly validating embedded metadata against upload metadata touches a core part of how we handle uploads, and requires careful consideration of edge cases across the ecosystem. This is something we want to get right rather than rush, and involves a fair amount of database changes, including data backfills.

TOB-PYPI26-13: Organization-scoped project associations persist after project transfer or removal

This was the other High-severity finding, and a subtle one.

When a project is transferred between organizations, the OrganizationProject junction record is correctly deleted and recreated. However, the TeamProjectRole records - which grant a team's members access to specific projects - were not cleaned up during the transfer.

This meant that if LexCorp Organization had a "release-engineers" team with Owner-level access to a project, and that project was transferred to Organization OsCorp, the LexCorp team's members would silently retain full access to the project. Worse, the receiving organization had no visibility into these stale associations - team-granted permissions are resolved at ACL evaluation time and don't appear as individual collaborator entries in the UI.

The fix in pypi/warehouse#19749 ensures that TeamProjectRole records belonging to the departing organization are cleaned up when a project is transferred. Auditing database records proved that this has not happened in the past, so I am confident there have been no such transfers with dangling permissions. I also added defensive filters in the project's ACL computation to verify that a team's organization matches the project's current organization before granting permissions, so stale records can't grant access regardless of how they're orphaned.

Summary

Working with Trail of Bits was again a pleasure. The team were thorough, communicative, and clearly understood the nuances of a system like PyPI - where the threat model spans everything from CI/CD token replay to metadata integrity for millions of downstream users.

Beyond the 14 findings, the audit also produced proposal reviews for features I'm considering (per-org Trusted Publishers, TOTP hardening, and more), as well as custom CodeQL queries to integrate into our CI/CD pipeline.

This audit was funded in partnership with the Sovereign Tech Agency, which continues to support security improvements across the Open Source ecosystem.

My work at the Python Software Foundation is supported by Alpha-Omega.

Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance

Seth Larson — Thu, 02 Apr 2026 06:09:00 +0000

This post will drill deeper into two recent supply chain exploits, targeting users of popular PyPI packages - litellm & telnyx. We also provide Python developers and maintainers with guidance on what they can do to prepare and protect themselves from future incidents.

What happened with LiteLLM and telnyx?

After an API token exposure from an exploited Trivy dependency releases of the packages litellm and telnyx were published to PyPI containing credential harvesting malware.

The malware ran on install, harvesting sensitive credentials and files, and exfiltrating to a remote API. More details published in the advisory for LiteLLM (PYSEC-2026-2), the LiteLLM blog post about the incident, the advisory for telnyx (PYSEC-2026-3) and the telnyx notice.

After contacting the litellm and telnyx maintainers, Mike and Seth collaborated with each team on steps forward, including token rotation, release removals, and recommendations around further security practices like using Trusted Publishers which both projects have since adopted.

Why is this malware different?

This class of malware is different from most malware published to PyPI, which are mostly published as new packages, either as typosquats or with a plan to share the package with others and hope they install it. This malware is "injected" into open source packages that are already in widespread use. The malware injection occurs one of two ways:

Targeting open source projects with insecure repositories, release workflows, or authentication
Targeting developers installing the latest versions of open source projects and exfiltrating API tokens and keys

Using the API tokens and keys gathered from developer machines, the malware authors are able to further compromise other open source packages if API tokens for PyPI or GitHub are exfiltrated. This cycle continues as long as it is effective in exfiltrating more credentials.

What is PyPI doing to mitigate malware?

With daily volume of ~700-800 new projects created daily on PyPI, this poses a scaling challenge. PyPI partners with security researchers from our community who regularly scan and report malware through elevated channels to facilitate quicker remediation times.

Below see the timeline of events.

During the window of attack, the exploited versions of litellm were downloaded over 119k times.

PyPI received 13 inbound reports from concerned users, leveraging the "Report project as malware" feature, added back in 2024, accelerating the review/action.

From upload to first report: 1h 19m
First report to quarantine: 1h 12m
From upload to quarantine (total exposure time): 2h 32m

LiteLLM is typically installed ~15-20 million times per week. Averaging this out to an "installs per minute" rate nets a value between ~1700 installs per minute. This means between ~40-50% of all installs of LiteLLM were unpinned and fetching the latest version on each install invocation.

Because these systems are pulling latest, this leaves very little time for researchers and PyPI admins to report, triage, and quarantine malware when published to a popular package. Read on for information on "dependency cooldowns"

PyPI's remediation response to telnyx was autonomously taken thanks to our pool of trusted reporters. These reporters add weight to any given report, triggering an automated quarantine feature. Subscribe to the PyPI blog for a future update about our automatic quarantining system.

From upload to first report: 1h 45m
First report to quarantine: 1h 57m
Form upload to quarantine (total exposure time): 3h 42m

Below are a few methods to make your usage of Python packages from PyPI more secure and to avoid installing malware.

Protecting yourself as a developer

Dependency Cooldowns

One method to avoid "drinking from the firehose" and allow time for malware to be detected and remediated is using "Dependency Cooldowns". Dependency cooldowns is a strategy for package installers (like pip, uv, etc) to avoid installing packages that have very recently been published to PyPI. By doing so, this allows for human operators like security researchers and PyPI admins a chance to respond to reports of malware.

Dependency cooldowns work best when they are configured "globally" on a developer machine and then passively protect developers from compromises on every invocation of pip or uv. Setting a relative value like "3 days" ("P3D" per RFC 3339) means packages that are newer than 3 days will not be installed.

uv already supports setting relative dependency cooldown via --exclude-newer. You can configure the option globally (in ~/.config/uv/uv.toml) or per-project in your pyproject.toml:

[tool.uv] exclude-newer = "P3D" # "3 days" in RFC 3339 format

Relative dependency cooldowns are coming soon to pip v26.1 which should be available in April of this year. Once they are available you can set the option in your pip.conf file (~/.config/pip/pip.conf):

[install] uploaded-prior-to = P3D

Starting in pip v26.0 you can set absolute dependency cooldowns with pip from the command-line, likely paired with another tool like date to calculate an absolute date from a relative offset like "3 days":

python -m pip install \ --uploaded-prior-to=$(date -d '-3days' -Idate) \ simplepackage

Applying dependency cooldowns everywhere isn't a silver bullet, though! There are certain situations where you do want the latest version of a package as soon as possible, like when applying patches for vulnerabilities. Dependency cooldowns should be paired with a vulnerability scanning strategy so security updates for your application's dependencies aren't waiting to be deployed. For example, Dependabot and Renovate both bypass dependency cooldowns by default for security updates.

You can manually bypass a dependency cooldown in pip and uv by setting a value of "the current day" to get the actual latest release:

python -m pip install \ --uploaded-prior-to=P0D \ simplepackage==26.3.31

Locking Dependencies

Installing a package from PyPI without a "lock" means that it's possible to receive new code every time you run pip install. This leaves the door open for a compromise of a package to immediately get installed and execute malware on the installing systems.

If you're a developer of an application using PyPI packages you should be using lock files both for security and reproducibility of your application. Some examples of tools which produce lock files for applications are:

uv lock
pip-compile --generate-hashes
pipenv

Note that pip freeze doesn't create a lock file: a lock file must include checksums / hashes of the package archives to be secure and reproducible. pip freeze only records packages and their versions. pip is working on experimental support for the pylock.toml standard through the pip lock sub-command.

Protecting your project as an open source maintainer

If you are a maintainer of an open source project on PyPI, you can do your part to protect your users from compromises. There are three approaches we recommend:

securing your release workflows
using Trusted Publishers
adding 2FA to all accounts associated with open source development

Securing release workflows

If you're using a continuous deployment system to publish packages to Python: these workflows are targets for attackers. You can prevent most of the danger by applying a handful of security recommendations:

Avoid insecure triggers. Workflows that can be triggered by an attacker, especially with inputs they control (such as PR titles, branch titles) have been used in the past to inject commands. The trigger pull_request_target from GitHub Actions in particular is difficult to use securely and should be avoided.
Sanitize parameters and inputs. Any workflow parameter or input that can expand into an executed command carries potential to be used by attackers. Sanitize values by passing them as environment variables to commands to avoid template injection attacks.
Avoid mutable references. Lock or pin your dependencies in workflows. Favor using Git commit SHAs instead of Git tags, as tags are writeable. Maintain a lock file for PyPI dependencies used in workflows.
Use reviewable deployments. Trusted Publishers for GitHub supports "GitHub Environments" as a required step. This makes publishing your package to PyPI require a review from your GitHub account, meaning a higher bar for an attacker to compromise.

If you are using GitHub Actions as your continuous deployment provider, we highly recommend the tool "Zizmor" for detecting and fixing insecure workflows.

Trusted Publishers over API tokens

If the platform you use to publish to PyPI supports Trusted Publishers (GitHub, GitLab, Google Cloud Build, ActiveState) then you should use Trusted Publishers instead of API tokens.

PyPI API tokens are "long-lived", meaning if they are exfiltrated by an attacker that attacker can use the token at a much later date even if you don't detect the initial compromise. Trusted Publishers comparatively uses short-lived tokens, meaning they need to be used immediately and don't require manual "rotating" in the case of compromise.

Trusted Publishers also provides a valuable signal to downstream users through Digital Attestations. This means users can detect when a release hasn't been published using the typical release workflow, likely drawing more scrutiny.

Adding 2FA to open source development accounts

We may be starting to sound like a broken record, but 2FA should be used for all accounts associated with open source development: not just PyPI. Think about accounts like version control / software forges (GitHub, GitLab, Codeberg, Forgejo) and your email provider. PyPI has required 2FA to be enabled to publish packages since the beginning of 2024, but enabling phishing-resistant 2FA like a hardware key can protect you further.

How can you support this kind of work?

Security work isn't free. You can support security work on the Python Package Index by supporting the Python Software Foundation (PSF). If you or your organization is interested in sponsoring or donating to the PSF so we can continue supporting Python, PyPI, and its community, check out the PSF's sponsorship program, donate directly, or contact our team at sponsors@python.org!

Mike Fiedler and Seth Larson's roles as PyPI Safety & Security Engineer and Security Developer-in-Residence at the Python Software Foundation are supported by Alpha Omega.

Dispatch from PyPI Land: A Year (and a Half!) as the Inaugural PyPI Support Specialist

Maria Ashna — Mon, 26 Jan 2026 06:09:00 +0000

Hello there! I am Maria, the inaugural PyPI Support Specialist. I go by "Thespi-Brain" on GitHub. I wanted to provide a dispatch of how this past year (and a half!) has been regarding my role and PyPI. PyPI has now reached over a million users and has over 700,000 projects. It is, without a doubt, a critical part of the Python ecosystem. As the inaugural PyPI Support Specialist, there were numerous challenges that needed to be tackled regarding PyPI support, such as the ever growing backlog of account recovery and PEP 541 issues.

Prior to stepping into this role, the account recovery backlog was four months behind. The PEP 541 backlog was a year and four months behind. There was also a lack of documentation around PyPI Support procedures. I started my role at PSF in July 2024. I am happy to report some highlights of my tenure so far:

Account Recovery backlog is now current with average triage time of 1.5 days¹
PEP 541 backlog is current as of December 2025, with an average first triage/issue response time of 1 week¹
Between July 2024 and December 2024, 725 of account recovery issues were resolved
Between Jan 2025 and December 2025, 2221 account recovery issues were resolved
Between Jan 2025 and December 2025, over ~500 PEP 541 issues were resolved

Since there was no documentation prior to this role, support processes and procedures have been internally documented with an end user friendly version coming out soon!

With account recovery and PEP 541 backlog under control, this also provided an opportunity to focus on getting PyPI Orgs back up again after its introduction in 2023. As of today, over 8000 applications have been approved with both community and company organizations combined.

In addition to the above, I have also created several feature requests for the Warehouse side of things to facilitate better workflow and tooling, particularly with PyPI Org application processing as well as feature suggestions to better process PEP 541 issues that are related to ultranormalized names.

A lot has been accomplished in the first year (and a half!), but of course, there is always more work to be done to ensure that PyPI is running smoothly. Here’s to another year (and a half!) of more exciting things to come!

Exceptions to this occur during holidays, conference times and other times staff may be out. ↩↩

PyPI in 2025: A Year in Review

Dustin Ingram — Wed, 31 Dec 2025 06:09:00 +0000

As 2025 comes to a close, it's time to look back at another busy year for the Python Package Index. This year, we've focused on delivering critical security enhancements, rolling out powerful new features for organizations, improving the overall user experience for the millions of developers who rely on PyPI every day, and responding to a number of security incidents with transparency.

But first, let's look at some numbers that illustrate the sheer scale of PyPI in 2025:

More than 3.9 million new files published
More than 130,000 new projects created
1.92 exabytes of total data transferred
2.56 trillion total requests served
81,000 requests per second on average

These numbers are a testament to the continued growth and vibrancy of the Python community.

Let's dive into some of the key improvements we've made to PyPI this year.

Security First, Security Always

Security is our top priority, and in 2025 we've shipped a number of features to make PyPI more secure than ever.

Enhanced Two-Factor Authentication (2FA) for Phishing Resistance

We've made significant improvements to our 2FA implementation, starting with email verification for TOTP-based logins. This adds an extra layer of security to your account by requiring you to confirm your login from a trusted device, when using a phishable 2FA method like TOTP.

Since rolling out these changes, we've seen:

more than 52% of active users with non-phishable 2FA enabled
more than 45,000 total unique verified logins

Trusted Publishing and Attestations

Trusted publishing continues to be a cornerstone of our security strategy. This year, we've expanded support to include GitLab Self-Managed instances, allowing maintainers to automate their release process without needing to manage long-lived API tokens. We've also introduced support for custom OIDC issuers for organizations, giving companies more control over their publishing pipelines.

Adoption of trusted publishing has been fantastic:

more than 50,000 projects are now using trusted publishing
more than 20% of all file uploads to PyPI in the last year were done via trusted publishers

We've also been hard at work on attestations, a security feature that allows publishers to make verifiable claims about their software. We've added support for attestations from all Trusted Publishing providers, and we're excited to see how the community uses this feature to improve the security of the software supply chain.

17% of all uploads to PyPI in the last year included an attestation.

Proactive Security Measures

Beyond user-facing features, we've also implemented a number of proactive security measures to protect the registry from attack. These include:

Phishing Protection: To combat the ongoing threat of phishing attacks, PyPI now detects and warns users about untrusted domains.
Improved ZIP file security: We've hardened our upload pipeline to prevent a class of attacks involving malicious ZIP files.
Typosquatting detection: PyPI now automatically detects and flags potential typosquatting attempts during project creation.
Domain Resurrection Prevention: We now periodically check for expired domains to prevent domain resurrection attacks.
Spam Prevention: We've taken action against spam campaigns, including prohibiting registrations from specific domains that were a source of abuse.

Transparency and Incident Response

This year, we've also focused on providing transparent and timely information about security incidents affecting PyPI. We've published detailed incident reports on a number of events, including:

An issue with privileges persisting in organization teams.
A widespread phishing attack targeting PyPI users.
A token exfiltration campaign via GitHub Actions workflows.
The potential implications of the "Shai-Hulud" attack on the npm ecosystem.

We believe that transparency is key to building and maintaining trust with our community, and we'll continue to provide these reports as needed.

Safety and Support Requests

This year, our safety & support team and administrators have been working diligently to address user requests and combat malware to maintain a healthy ecosystem. We're proud to report significant progress in handling various types of support inquiries and improving our malware response.

Malware Response

We've continued to improve our malware detection and response capabilities. This year, we've processed more than 2000 malware reports. This is a testament to the vigilance of our community and the dedication of our administrators.

Our goal is to reduce the time it takes to remove malware from PyPI, and we're happy to report that we're making significant progress: in the last year, 66% of all reports were handled within 4 hours, climbing to 92% within 24 hours, with only a few more complex issues reaching the maximum of 4 days to remediate.

Support Requests

Our support team has also been hard at work making sure our users can continue to be effective on PyPI. This year, we've successfully resolved 2221 individual account recovery requests.

We've also handled more than 500 project name retention requests (PEP 541). This includes an average first triage time of less than 1 week. This is a significant improvement compared to the previous 9-month backlog, and we're happy to report that the backlog is current for the month of December.

Organizations Growth

One of our biggest announcements in previous years was the general availability of organizations on PyPI. Organizations provide a way for companies and community projects to manage their packages, teams, and billing in a centralized location.

We have continued to see growing usage of organizations:

7,742 organizations have been created on PyPI
9,059 projects are now managed by organizations

We've been hard at work adding new features to organizations, including team management, project transfers, and a comprehensive admin interface. We're excited to see organizations use these features to use PyPI more effectively.

A Better PyPI for Everyone

Finally, we've made a number of improvements to the overall maintainer experience on PyPI. These include:

Project Lifecycle Management: You can now archive your projects to signal that they are no longer actively maintained. This is part of a larger effort to standardize project status markers as proposed in PEP 792.
New Terms of Service: We've introduced a new Terms of Service to formalize our policies and enable new features like organizations.

Looking Ahead to 2026

We're proud of the progress we've made in 2025, but we know there's always more to do. In 2026, we'll continue to focus on improving the security, stability, and usability of PyPI for the entire Python community.

Acknowledgements

As always, a huge thanks to our sponsors who make the scale and reliability of PyPI possible, and a special shout-out to Fastly for being a critical infrastructure donor.

We'd also like to extend a special thank you to a few individuals who made significant contributions to PyPI this year. Thank you to William Woodruff, Facundo Tuesca, and Seth Michael Larson for your work on trusted publishing, attestations, project archival, zipfile mitigation, and other security features.

Finally, PyPI wouldn't be what it is today without the countless hours of work from our community. A huge thank you to everyone who contributed code, opened an issue, or provided feedback this year. As always, we're grateful for the contributions of our community, whether it's through code, documentation, or feedback. PyPI wouldn't be what it is today without you.

Here's to a great 2026!

-- Dustin Ingram, on behalf of the PyPI team.

PyPI and Shai-Hulud: Staying Secure Amid Emerging Threats

Mike Fiedler — Wed, 26 Nov 2025 06:09:00 +0000

An attack on the npm ecosystem continues to evolve, exploiting compromised accounts to publish malicious packages. This campaign, dubbed Shai-Hulud, has targeted large volumes of packages in the JavaScript ecosystem, exfiltrating credentials to further propagate itself.

PyPI has not been exploited, however some PyPI credentials were found exposed in compromised repositories. We've revoked these tokens as a precaution, there's no evidence they have been used maliciously. This post raises awareness about the attack and encourages proactive steps to secure your accounts, especially if you're using build platforms to publish packages to PyPI.

How does this relate to PyPI?

This week, a security researcher disclosed long-lived PyPI credentials exposed as part of the Shai-Hulud campaign. The credentials were found in GitHub repositories (stored as repository secrets), and were still valid. We saw an attack with insecure workflow settings for Ultralytics in 2024.

While the campaign primarily targets npm, some projects use monorepo setups, publishing both JavaScript packages to npmjs.com and Python packages to PyPI from the same repository. When attackers compromise these repositories, they can extract credentials for multiple platforms.

We investigated the reported credentials and found they were associated with accounts that hadn't published recently. We've revoked these credentials and reached out to affected users to advise them to rotate any remaining tokens.

What can I do to protect my PyPI account?

Here are security practices to protect your PyPI account:

Use Trusted Publishing: If you are using a build platform to publish packages to PyPI, consider using a Trusted Publisher. This eliminates the need to manage long-lived authentication tokens, reducing the risk of credential exposure. Trusted Publishing uses short-lived, scoped tokens for each build, minimizing the impact of any potential compromise. This approach has risen in popularity, with other registries like Crates.io, RubyGems, and npmjs.com adopting similar models.

When using GitHub Actions, consider layering in additional security measures, like requiring human approval via GitHub Environments before publishing. This blog post from pyOpenSci has detailed guidance on adding manual review steps to GitHub Actions workflows.
Audit your workflows for misconfiguration: Review your GitHub Actions workflows for any potential security issues. Tools like zizmor and CodeQL can help identify vulnerabilities in your CI/CD pipelines. Adopt scanning as automated actions for the repository to catch future issues.
Review your account activity: Regularly check your PyPI account activity for any unauthorized actions. If you notice any suspicious activity, report it to the PyPI security team immediately.

Taking any of these steps helps mitigate the risk of compromise and keeps packages secure.

References

Some blog posts covering the attack behaviors and mitigation steps:

New Login Verification for TOTP-based Logins

Dustin Ingram — Fri, 14 Nov 2025 06:09:00 +0000

We've implemented a new security feature designed to protect PyPI users from phishing attacks: email verification for TOTP-based logins from new devices.

What's Changing?

Previously, when logging in with a Time-based One-Time Password (TOTP) authenticator, a successful TOTP code was sufficient. Now, if you log in from a device or browser that PyPI doesn't recognize, we will send a verification email to the email address associated with your PyPI account with the subject "Unrecognized login to your PyPI account". You will need to click a link in this email to confirm the login attempt before you can proceed, after which the current device will be trusted for future logins.

Users who have enabled WebAuthn (security keys) or passkeys for 2FA will not see any changes, as these methods are inherently phishing-resistant. They cryptographically bind the authentication to the specific website (origin), meaning an attacker cannot trick you into authenticating on a fake site, unlike TOTP codes which can be phished.

Why This Change?

This extra step significantly enhances PyPI user account security by mitigating the risk of phishing. As we've discussed in previous posts, such as "Phishing attacks with new domains likely to continue", recent phishing campaigns have targeted PyPI users. This new feature is a direct response to these ongoing threats. Even if an attacker manages to steal your username, password, and a TOTP code, they won't be able to access your account from a new device without also gaining access to your email. This makes it much harder for malicious actors to compromise your account.

What You Need To Do

Most users will only encounter this verification when using TOTP-based 2FA when logging in from a new device. If you receive a verification email and you did not attempt to log in to PyPI, please do not click the link. Instead, change your password immediately and review your account for any suspicious activity.

While this new feature improves the security of TOTP, we continue to recommend migrating to stronger second-factor authentication methods such as passkeys or WebAuthn (security keys). These methods offer superior protection against phishing and other sophisticated attacks. If you haven't already, please consider upgrading your 2FA method for the best possible account security on PyPI.

We believe this change will make PyPI an even safer place for the Python community. Thank you for your continued trust and support!

Trusted Publishing is popular, now for GitLab Self-Managed and Organizations

Mike Fiedler — Mon, 10 Nov 2025 06:09:00 +0000

Trusted Publishing has proven popular since its launch in 2023.

Recap: Trusted Publishing enables software build platforms to publish packages to PyPI on your behalf, eliminating the need to manage long-lived authentication tokens. After a one-time setup where you delegate publishing authority to your platform, it automatically obtains short-lived, scoped tokens for each build—no manual token management required.

Read the Security Model for a deeper understanding of how Trusted Publishing works.

Growing Adoption and Impact

Since its inception, Trusted Publishing has been adopted by communities and companies alike, with ~45,000 projects configured for Trusted Publishing on PyPI so far. In early 2024 we added the ability to track whether each file upload was done via a Trusted Publisher, enabling us to analyze its impact over time. Also in 2024, more platforms were added as detailed in our April 2024 blog post.

Here's a chart displaying the overall count of files uploaded to PyPI each month, broken down by whether they were uploaded via Trusted Publishers or not:

A couple of numbers for comparison:

February 2024 - 241k files added
October 2025 - 377k files added

As this chart shows, the overall scale of files uploaded to PyPI has grown (as detailed in this blog from the PSF Director of Infrastructure on open infrastructure growth) but what is great to see is that the proportional rate of Trusted Publishing use has grown as well. This can be seen by charting the percentage of files uploaded for each method over time:

Here we can see that back in February 2024, only about 10% of files were uploaded via Trusted Publishers. By October 2025, that number has grown to over 25% of all files uploaded to PyPI in a given month.

Hopefully posts like this and increased visibility in how to adopt Trusted Publishing will help continue this growth trend. Having folks like Sviatoslav Sydorenko and other contributors voluntarily maintain the widely-used GitHub Actions workflow for Trusted Publishing that makes everything that much easier has been a huge help, support them as well if you can! Using that action adds Digital Attestations automatically.

I hope that when we examine these stats next year, we'll see even more growth as more organizations adopt Trusted Publishing for their package publishing workflows.

Which brings me to...

Expansion of Trusted Publishing to GitLab Self-Managed Beta

Since folks have been loving Trusted Publishing, I'm excited to share that it's now available in beta for GitLab Self-Managed instances. This means organizations running their own GitLab can now use Trusted Publishers to publish packages more securely, without dealing with long-lived tokens.

As a reminder, trusted publishing support for the public GitLab.com instance has been available since early 2024.

Since GitLab itself can be self-hosted, we're initially launching this feature as a beta to gather feedback and ensure a smooth experience. Organizations' self-hosted instances must be manually onboarded by PyPI staff during this beta phase, while we learn more about the various configurations and setups in use.

In this scenario, the trust relationship is established between your GitLab Self-Managed instance and PyPI, allowing GitLab CI/CD pipelines to publish packages on behalf of your organization without the need for long-lived tokens.

If your organization runs your own GitLab Self-Managed instances and wish to publish packages to PyPI using Trusted Publishing, we encourage you to try out Trusted Publishing and provide feedback during this beta phase. Email support+orgs@pypi.org (or click this link for a pre-filled email that you can update with your details).

Pending Trusted Publishers for Organizations Feature

Oh, and one more thing - an important feature of PyPI Organizations is now available:

You can now create a pending Trusted Publisher at the Organization level.

Why does this matter? Previously, a PyPI user account creating a Pending Trusted Publisher (for a project that does not yet exist) would become the Owner of the project once it's been uploaded by the Trusted Publisher. This made sense for individual users, but for Organizations, it meant that the user who created the Pending Trusted Publisher would become the Owner of the project once it was published, and may overlook transferring ownership back to the Organization, which is less than ideal.

With this new feature, when creating a Pending Trusted Publisher at the Organization level, the project will be owned by the Organization itself once it's published, regardless of which user created the Pending Trusted Publisher.

This makes managing projects in Organizations way easier, making sure projects belong to the Organization itself and not just whoever set things up.

If you have a PyPI Organization and wish to create a Pending Trusted Publisher, check it out on your Organization's Trusted Publishers page, by following:

Navigate to your PyPI Organization's page (e.g., https://pypi.org/organizations/<your-org-name>/)
Click on the "Publishing" tab on the sidebar.
See the forms to create a Pending Trusted Publisher for your Organization.

All other behaviors of Pending Trusted Publishers remain the same, see the Trusted Publishers documentation for more details.

What's next?

We're continuing to work on making PyPI publishing safer and more secure, so we'll keep watching how Trusted Publishing adoption grows. During the GitLab Self-Managed beta, we'd love to hear your feedback so we can improve things based on how you actually use it.

Some next step ideas we have, and would love your feedback on:

Adding support for GitHub Enterprise Server instances
Adding support for GitHub Actions Reusable Workflows
Adding support for other publishing platforms

For any of these, feel free to visit the related GitHub issue and add your reaction to the main issue to help us sort them by interest.

Live long, and publish!

Phishing attacks with new domains likely to continue

Seth Larson — Tue, 23 Sep 2025 06:09:00 +0000

Unfortunately the string of phishing attacks using domain-confusion and legitimate-looking emails continues. This is the same attack PyPI saw a few months ago and targeting many other open source repositories but with a different domain name. Judging from this, we believe this type of campaign will continue with new domains in the future.

In short, there's a new phishing campaign targeting PyPI users occurring right now. The email asks you to "verify their email address" for "account maintenance and security procedures" with a note that your account may be suspended. This email is fake, and the link goes to pypi-mirror.org which is a domain not owned by PyPI or the PSF.

If you have already clicked on the link and provided your credentials, we recommend changing your password on PyPI immediately. Inspect your account's Security History for anything unexpected. Report suspicious activity, such as potential phishing campaigns against PyPI, to security@pypi.org.

What is PyPI doing to protect users?

There's no quick-and-easy method for PyPI maintainers to completely halt this sort of attack short of requiring phishing-resistant 2FA (such as hardware tokens). Below are the following steps we're taking to keep users safe:

Contacting the registrars and CDN of the malicious domains to have them taken down.
Submitting phishing domains to lists of known-malicious URLs. This makes browsers show a warning before visiting the website, hopefully triggering alarm bells for users.
Collaborating with other open source package managers to share strategies for quicker domain take-downs.
Exploring methods to make authenticating using TOTP-based 2FA more resistant to phishing.

What can you do as a maintainer?

If you are a maintainer of a package on PyPI, you can help protect your users by adopting the following practices:

Don't trust or click on links in emails that you didn't trigger yourself.
Use a password manager that auto-fills based on domain name and exclusively using this feature. If auto-fill isn't working when it usually does, that is a warning sign!
Adopt a phishing-resistant 2FA method such as hardware keys.
When in doubt, ask for help before taking action. There is no shame in being cautious, share fishy-looking emails with others.
Share this warning within your own communities. PyPI is not the first or last open source service that will be targeted with phishing attacks.

Token Exfiltration Campaign via GitHub Actions Workflows

Mike Fiedler — Tue, 16 Sep 2025 06:09:00 +0000

Summary

I recently responded to an attack campaign where malicious actors injected code into GitHub Actions workflows attempting to steal PyPI publishing tokens. PyPI was not compromised, and no PyPI packages were published by the attackers.

Attackers targeted a wide variety of repositories, many of which had PyPI tokens stored as GitHub secrets, modifying their workflows to send those tokens to external servers. While the attackers successfully exfiltrated some tokens, they do not appear to have used them on PyPI.

I've invalidated all affected tokens and notified the impacted project maintainers. If you're one of them, I have emailed you from security@pypi.org.

You can read more about the details of the attack on GitGuardian's blog.

Timeline and Response

On September 5th, a GitGuardian employee used the PyPI "Report as malware" button to submit their findings for a project named fastuuid - namely they found a malicious GitHub Actions workflow attempting to exfiltrate PyPI tokens to a remote server. No compromise on PyPI was found, tokens relating to the user accounts were invalidated, and I reached out to the project owners to notify and help secure the account and project.

Later on September 5th, another researcher from GitGuardian emailed PyPI Security directly about their current findings, effectively an expansion of the previous attack. Due to some of the contents in that email, it ended up in our inbound Spam folder, delaying response until September 10th when I became aware of the attack via other channels, and found the original email in the Spam folder. I may follow up with our support system provider to see about improving spam filtering rules.

After triaging the situation, I discovered another Indicator of Compromise (IoC) in the form of a URL, which I shared with GitGuardian to assist with their ongoing investigation.

Over the course of the following few days, I reviewed the findings from the researchers. I observed that many of the project maintainers responded to notifications from the researchers on their open source issue trackers, either reverting the changes to their actions workflows, or removing the affected workflows entirely from history via force-push of the repository. Many of the maintainers also proactively rotated their PyPI tokens.

After confirming that no PyPI accounts had been compromised, on September 15th I reached out to the maintainers of the affected projects to notify them of the situation, to let them know that their tokens had been invalidated, and recommend using Trusted Publishers with GitHub Actions to help protect their projects in the future.

What You Can Do

If you use GitHub Actions to publish to PyPI, I recommend the following steps to protect your projects:

Replace long-lived tokens with Trusted Publishers. This is the most effective way to protect your projects from this type of attack. GitHub Trusted Publishers use short-lived tokens that are scoped to a specific repository, and expire after a short period of time.
Log into your account and review your security history for any suspicious activity. You can do this by going to your Account Settings and scrolling to the "Security History" section.

While Trusted Publisher tokens can still be exfiltrated, using Trusted Publishers significantly reduces the risk of compromise.

Acknowledgements

Thanks to Charles Brossollet, Guillaume Valadon, and Gaëtan Ferry of GitGuardian for their collaboration on this issue.

This investigation and incident response is made possible by the generosity of individuals and corporations supporting critical security efforts to better secure the Python community, with thanks to Alpha-Omega.

Support these efforts and more here: https://www.python.org/sponsors/application/

Preventing Domain Resurrection Attacks

Mike Fiedler — Mon, 18 Aug 2025 06:09:00 +0000

Summary

PyPI now checks for expired domains to prevent domain resurrection attacks, a type of supply-chain attack where someone buys an expired domain and uses it to take over PyPI accounts through password resets.

These changes improve PyPI's overall account security posture, making it harder for attackers to exploit expired domain names to gain unauthorized access to accounts.

Since early June 2025, PyPI has unverified over 1,800 email addresses when their associated domains entered expiration phases. This isn't a perfect solution, but it closes off a significant attack vector where the majority of interactions would appear completely legitimate.

Background

PyPI user accounts are linked to email addresses. Email addresses are tied to domain names; domain names can expire if unpaid, and someone else can purchase them.

During PyPI account registration, users are required to verify their email addresses by clicking a link sent to the email address provided during registration. This verification ensures the address is valid and accessible to the user, and may be used to send important account-related information, such as password reset requests, or for PyPI Admins to use to contact the user.

PyPI considers the account holder's initially verified email address a strong indicator of account ownership. Coupled with a form of Two-Factor Authentication (2FA), this helps to further secure the account.

Once expired, an attacker could register the expired domain, set up an email server, issue a password reset request, and gain access to accounts associated with that domain name.

Accounts with any activity after January 1 2024 will have 2FA enabled, and an attacker would need to have either the second factor, or perform a full account recovery.

For older accounts prior to the 2FA requirement date, having an email address domain expire could lead to account takeover, which is what we're attempting to prevent, as well as minimize potential exposure if an email domain does expire and change hands, regardless of whether the account has 2FA enabled.

This is not an imaginary attack - this has happened at least once for a PyPI project back in 2022, and other package ecosystems.

TL;DR: If a domain expires, don't consider email addresses associated with it verified any more.

Domain Expiration Timeframe

Here's a generalized flowchart of phases that domain name registrars often adhere to. There's typically a grace period before a domain is deleted. Read more about ICANN's Expired Registration Recovery Policy (ERRP).

One way to visualize this can be seen in the below flowchart:

flowchart TD A[Domain Active] -->|Expiration Date Reached| B{Owner Renews?} B -->|Yes - Within Grace Period| A B -->|No| C[Renewal Grace Period<br/>0-45 days] C -->|Owner Renews<br/>Regular Price| A C -->|No Renewal| D[Redemption Period<br/>30 days] D -->|Owner Redeems<br/>High Fee $70-200+| A D -->|No Redemption| E[Pending Delete<br/>5 days] E -->|Automatic| F[Domain Released]

The word "expiration" might be a bit overloaded, as conceptually there is no specific state advertised that a domain name has expired, rather using other indicators we can infer what state the domain name is currently in.

Thanks to our friends at Domainr (a Fastly service), we can use their Status API to issue periodic queries for any given domain, and act on the response.

The time interval we've chosen for now is 30 days, as per the flow above, there's a high likelihood that a domain is still in the Renewal Grace Period or Redemption Period when we check for status, and can react before it is released or changes hands.

Note: PyPI will not detect a non-expiring domain transfer, as we assume the parties are acting together to transfer a domain legitimately.

PyPI Actions

After an initial bulk check period that took place in April 2025, PyPI will check daily for any domains in use for status changes, and update its internal database with the most recent status.

If a domain registration enters the redemption period, that's an indicator to PyPI that the previously verified email destinations may not be trusted, and will un-verify a previously-verified email address. PyPI will not issue a password reset request to addresses that have become unverified.

Since the initial implementation early June 2025, PyPI has unverified over 1,800 email addresses (initial 1,500 excluded from chart), and will continue to do so daily, to protect both PyPI account holders, as well as the end users of PyPI packages.

Recommendations for end users

If your PyPI account only has a single verified email address from a custom domain name, add a second verified email address from another notable domain (e.g. Gmail) to your account.

During a PyPI account recovery, PyPI may ask for other proofs, often via other services under the user's control. If the same email address is used on those other services, the recovery could appear legitimate. Ensure you have 2FA set on those services as well to prevent potential account takeovers.

That's all for now, folks

While these changes are not foolproof, they decrease the likelihood of domain resurrections account takeovers.

Thanks to Eric Case at Fastly for helping us understand some of the complexities and Samuel Giddins at Ruby Central for their initial ideas of this approach, and the OpenSSF Securing Software Repositories Working Group for their collaborative guidance on repository security.

This effort would not be possible without the continued support from Alpha-Omega.

PyPI now serves project status markers in API responses

William Woodruff — Thu, 14 Aug 2025 06:09:00 +0000

PyPI now serves project status markers in its standard index APIs. This allows downstream consumers (like Python package installers and index mirrors) to retrieve project statuses programmatically and use them to inform users when a project is archived or quarantined.

Summary

PyPI has implemented project status markers as proposed and accepted in PEP 792.
As of today, PyPI supports three standard statuses: active (the default), archived, and quarantined.
Downstream consumers can now retrieve these statuses via the standard index APIs and use them to inform users about the state of a project.

See the project archival and project quarantine announcement posts for additional information on PyPI's implementation of those individual statuses.

Background

Many Python regularly find themselves asking the same questions again and again when evaluating a new dependency:

Is the dependency deprecated, potentially in favor of another project?
If a vulnerability is discovered in the dependency, is it likely to be patched?
Can I expect major future changes to the dependency, or is it "done" (i.e. feature complete)?

These questions (and many others in the domain of supply chain security) essentially boil down to a single question: what is the status of this project?

The status quo before status markers

Before PEP 792, Python packaging had no less than three overlapping solutions for determining a project's status:

Individual releases of a project could include a Development Status trove classifier in their metadata, such as Development Status :: 7 - Inactive to indicate that the project is no longer actively maintained.

However, trove classifiers occur at the distribution level, leading to two problems:
1. To update a project's status, the project's maintainer must upload a new release with the updated classifier. This is unnecessarily onerous, particularly when the intent is to stop updating the project!
2. Classifiers do not apply retroactively, meaning that all previous releases of a project continue to have their original classifiers. This results in a misleading view of the project's status: a downstream that pins to sampleproject==1.2.3 may fail to realize that sampleproject===1.2.4 signals that the entire project is now inactive.
Indices can mark individual files (or entire releases) as "yanked," per the file yanking specification. Yanked files are effectively soft-deleted, meaning that they'll be skipped by complying installers during resolution but not if explicitly pinned by the user.

Yanking is a useful tool for mitigating accidental vulnerabilities or compatibility breakages in a release, but it has the same "scope" issue as classifiers: it applies at the file and release level, not at the project level.

Moreover, the semantics of yanking aren't appropriate for all potential statuses: soft deletion is still disruptive, whereas statuses like "archived" and "deprecated" suggest that the project is still suitable for installation, so long as the user can be made aware of its status.
PyPI itself has "project statuses," which apply to the entire project. These statuses were not standardized, and therefore only appeared on user-facing HTML pages, not in the standard APIs. This made them difficult to retrieve programmatically, limiting their usefulness.

Beyond these partial solutions many downstreams also apply heuristics to determine a project's status, such as checking for recent project (or source repository) activity or using popularity metrics like GitHub stars as a proxy for project health. However, these heuristics can be manipulated or outright incorrect, such as when a project is feature complete and therefore has no recent activity.

Overall, these partial solutions and heuristics point to a need for something better.

Project status markers

That brings us to the new feature: project status markers.

Project status markers are a Python packaging standard derived from PyPI's existing project statuses. The standard defines four project statuses, which have both index-side and installer-side semantics:

active: Indicates that the project is active. This is the default status, meaning that any project that does not explicitly declare a status is considered active. Active projects are not subject to any restrictions on upload or installation.
archived: Indicates that the project does not expect to be updated in the future. When a project is archived, PyPI will not allow new uploads to the project, and installers are encouraged to inform users about the project's archival.
quarantined: Indicates that the project is considered generally unsafe for use, e.g. due to malware. When a project is quarantined, PyPI will not offer it for installation, and installers are encouraged to produce a warning when users attempt to install it¹.
deprecated: Indicates that the project is considered obsolete, and may have been superceded by another project. Unlike archived projects, deprecated projects can still be uploaded to, but installers are encouraged to inform users about the project's deprecation.

Of these statuses, PyPI currently supports active, archived, and quarantined. PyPI doesn't support deprecated yet, but we'll be looking at supporting it now that the MVP is complete.

Beyond the statuses themselves, the standard also defines an optional "status reason" that can be used to provide additional context about the status. PyPI doesn't currently expose status reasons, but may do so in the future.

Consuming status markers

The standard is one thing, but let's see how to actually get status markers from PyPI's index APIs.

Status markers are available in both the HTML and JSON index APIs. For the HTML API the <meta> fields are:

pypi:project-status for the project status itself (or active by default)
pypi:project-status-reason for the project status reason (if present)

For example:

curl --silent \ -H "Accept: application/vnd.pypi.simple.v1+html" \ https://pypi.org/simple/pepy/ \ | htmlq --pretty 'head meta[name="pypi:project-status"]'

Yields:

<meta name="pypi:project-status" content="archived">

Within the JSON API, the project status is available via the top-level project-status object, which contains status and reason fields corresponding to the HTML API fields above.

For example:

curl --silent \ -H "Accept: application/vnd.pypi.simple.v1+json" \ https://pypi.org/simple/pepy/ \ | jq '."project-status"'

Yields:

{ "status": "archived", }

Conclusion

Starting today, Python package installers and other index consumers can retrieve status markers from PyPI's standard index APIs.

Our hope is that downstreams will consume these markers, and use them as suggested by the standard. In particular we hope that installers like pip and uv will signal relevant statuses to users, helping them form a better picture of the status of their dependencies as well as set policies controlling which statuses are acceptable for installation.

Acknowledgements

PEP 792 was authored by William Woodruff (Astral) and Facundo Tuesca (Trail of Bits). We'd like to thank Donald Stufft for being the PEP's sponsor and PEP delegate. Additionally, we'd like to thank Dustin Ingram and Mike Fiedler for their review and feedback on the PEP and the associated changes to PyPI.

The funding for this feature’s development comes in part from Alpha-Omega. Alpha-Omega’s mission is to protect society by catalyzing sustainable security improvements to the most critical open-source software projects and ecosystems.

This warning is technically moot, as PyPI itself will not offer any files from quarantined projects for installation. However, the warning can still help users understand why their installation has failed, and is therefore recommended by the standard. ↩

Preventing ZIP parser confusion attacks on Python package installers

Seth Larson — Thu, 07 Aug 2025 06:09:00 +0000

The Python Package Index is introducing new restrictions to protect Python package installers and inspectors from confusion attacks arising from ZIP parser implementations. This has been done in response to the discovery that the popular installer uv has a different extraction behavior to many Python-based installers that use the ZIP parser implementation provided by the zipfile standard library module.

Summary

ZIP archives constructed to exploit ZIP confusion attacks are now rejected by PyPI.
There is no evidence that this vulnerability has been exploited using PyPI.
PyPI is deprecating wheel distributions with incorrect RECORD files.

Please see this blog post and CVE-2025-54368 for more information on uv's patch.

Wheels are ZIPs, and ZIPs are complicated

Python package "wheels" (or "binary distributions"), like many other file formats, actually a ZIP in disguise. The ZIP archive standard was created in 1989, where large archives might need to be stored across multiple distinct storage units due to size constraints. This requirement influenced the design of the ZIP archive standard, such as being able to update or delete already-archived files by appending new records to the end of a ZIP instead of having to rewrite the entire ZIP from scratch which might potentially be on another disk.

These design considerations meant that the ZIP standard is complicated to implement, and in many ways is ambiguous in what the "result" of extracting a valid ZIP file should be.

The "Binary Distribution Format" specification defines how a wheel is meant to be installed. However, the specification leaves many of the details on how exactly to extract the archive and handle ZIP-specific features to implementations. The most detail provided is:

Although a specialized installer is recommended, a wheel file may be installed by simply unpacking into site-packages with the standard ‘unzip’ tool while preserving enough information to spread its contents out onto their final paths at any later time.

This means that ZIP ambiguities are unlikely to be caught by installers, as there are no restrictions for which ZIP features are allowed in a valid wheel archive.

There's also a Python packaging specific mechanism for which files are meant to be included in a wheel. The RECORD file included inside wheel .dist-info directories lists files by name and optionally a checksum (like SHA256). The specification for the .dist-info directory details how installers are supposed to check the contents of the ZIP archive against RECORD:

Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD.

However, most Python installers today do not do this check and extract the contents of the ZIP archive similar to unzip and then amend the installed RECORD within the virtual environment so that uninstalling the package works as expected.

This means that there is no forcing function on Python projects and packaging tools to follow packaging standards or normalize their use of ZIP archive features. This leads to the ambiguous situation today where no one installer can start enforcing standards without accidentally "breaking" projects and archives that already exist on PyPI.

PyPI is adopting a few measures to prevent attackers from abusing the complexities of ZIP archives and installers not checking RECORD files to smuggle files past manual review processes and automated detection tools.

What is PyPI doing to prevent ZIP confusion attacks?

The correct method to unpack a ZIP is to first check the Central Directory of files before extracting entries. See this blog post for a more detailed explanation of ZIP confusion attacks.

PyPI is implementing the following logic to prevent ZIP confusion attacks on the upload of wheels and ZIPs:

Rejecting ZIP archives with invalid record and framing information.
Rejecting ZIP archives with duplicate filenames in Local File and Central Directory headers.
Rejecting ZIP archives where files included in Local File and Central Directory headers don't match.
Rejecting ZIP archives with trailing data or multiple End of Central Directory headers.
Rejecting ZIP archives with incorrect End of Central Directory Locator values.

PyPI already implements ZIP and tarball compression-bomb detection as a part of upload processing.

PyPI will also begin sending emails to warn users when wheels are published whose ZIP contents don't match the included RECORD metadata file. After 6 months of warnings, on February 1st, 2026, PyPI will begin rejecting newly uploaded wheels whose ZIP contents don't match the included RECORD metadata file.

We encourage all Python installers to use this opportunity to implement cross-checking of extracted wheel contents with the RECORD metadata file.

`RECORD` and ZIP issues in top Python packages

Almost all the top 15,000 Python packages by downloads (of which 13,468 publish wheels) have no issues with the ZIP format or the RECORD metadata file. This makes us confident that we can deploy these changes without major disruption of existing Python project development.

Status	Number of Projects
No `RECORD` or ZIP issues	13,460
Missing file from `RECORD`	4
Mismatched `RECORD` and ZIP headers	2
Duplicate files in ZIP headers	2
Other ZIP format issues	0

Note that there are more occurrences of ZIP and RECORD issues that have been reported for other projects on PyPI, but those projects are not in the top 15,000 by downloads.

What actions should I take?

The mitigations above mean that users of PyPI, regardless of their installer, don't need to take immediate action to be safe. We recommend the following actions to users of PyPI to ensure compliance with Python package and ZIP standards:

For users installing PyPI projects: Make sure your installer tools are up-to-date.
For maintainers of PyPI projects: If you encounter an error during upload, read the error message and update your own build process or report the issue to your build tool, if applicable.
For maintainers of installer projects: Ensure that your ZIP implementation follows the ZIP standard and checks the Central Directory before proceeding with decompression. See the CPython zipfile module for a ZIP implementation that implements this logic. Begin checking the RECORD file against ZIP contents and erroring or warning the user that the wheel is incorrectly formatted.

Acknowledgements

Thanks to Caleb Brown (Google Open Source Security Team) and Tim Hatch (Netflix) for reporting this issue.

This level of coordination across Python ecosystem projects requires significant engineering time investment. Thanks to Alpha-Omega who sponsors the security-focused Developer-in-Residence positions at the Python Software Foundation.

PyPI Phishing Attack: Incident Report

Mike Fiedler — Thu, 31 Jul 2025 06:09:00 +0000

Incident Report: Phishing Attack

Over the past few days, a phishing attack targeting PyPI users via email was uncovered. Our initial report was posted to raise awareness of the attack, and to provide some initial details on the attack vector.

Social media posts linking to the initial report have been shared widely, PyPI itself has not been breached with this attack.

Summary

4 user accounts were successfully phished, now either disabled or credentials rotated
2 API Tokens were generated by the attackers, which have since been revoked
2 releases of the num2words project were uploaded by the attacker, which have since been removed
The phishing domain has been taken down

This appears to be similar in nature to a recent incident involving npm packages, where attackers successfully phished end-user credentials, and then compromised popular packages to distribute malware via npmjs.com. Read a report on this attack here.

To briefly recap the attack pattern, the attackers established a domain name, SSL certificate, and server running in a Virtual Private Server (VPS) in the cloud, which would transparently proxy requests to PyPI.org. This could be termed a "forward proxy", many CDN providers operate their services this way. We cannot know for certain, but it appears that the attackers sent emails to addresses found in package metadata, which is publicly available due to users putting them in their setup.py or pyproject.toml files. The emails contained links to the phishing domain, asking them to verify their email address. When users clicked the link, they were directed to the phishing domain, which presented the PyPI.org website, but with a different URL in the browser address bar.

Normal traffic flow:

flowchart LR A[Client Browser] -->|Request| B[PyPI.org] B -->|Response| A

Phishing attack flow:

flowchart LR A[Client Browser] -->|Click Email Link| B[Phishing Domain] B -->|Proxy Request| C[PyPI.org] C -->|Response| B B -->|Display Content| A

This may be termed "adversary in the middle" (AiTM) attack, however the difference here is that the attacker is not intercepting traffic between the user and PyPI.org, rather is acting as a forward proxy, which is a common practice for content delivery networks (CDNs) and the like.

Since a browser's address bar showed hxxps://pypj.org/..., and the website content of legitimate pypi.org, users might have missed the small difference between a lowercase i and j, and tricked into thinking they were on the official PyPI website, and submitted their credentials to the phishing domain.

The phisher could then capture the credentials, and use them to log in to the real PyPI.org website, potentially compromising the user's account and any packages they maintain.

Having a form of two-factor authentication (2FA) enabled on the account generally prevents phishing attacks like this from being successful, as the attacker would need access to the second factor (e.g. a TOTP code) to complete the login process.

However, since the attacker was in between the user and PyPI.org, they could have captured the second factor as well, and could have used the TOTP code within a short time interval, or potentially even captured the session cookies provided during the response to the login request, and thus bypassed the need for 2FA for a short time.

If the user had enrolled a Security Device for PyPI second factor authentication, the attacker would not have been able to use the second factor, as the WebAuthn protocol requires the user to physically interact with a hardware security key, or use a browser-based implementation, which would not be possible if the user was not on the legitimate PyPI.org website (Relying Party Identifier).

Also, there are a significant amount of relatively inactive users who pre-date 2FA on PyPI, and may not have 2FA enabled on their accounts. If a user in this category fell for the phishing attack, they would still need to complete email address verification, and 2FA enrollment. This process generates an email from PyPI to the user, which links back to the legitimate PyPI.org address. These user accounts were not as vulnerable to this specific attack.

Timeline of events

Times are in both Eastern Daylight Time (EDT) and UTC. Some events may be omitted for brevity.

Keep in mind: in the USA, the weekend is Saturday and Sunday.

2025-07-26 Saturday

13:14 EDT (17:14 UTC): A user emails PyPI Security about a suspicious phishing email they received, which appears to be from PyPI.org, but with a different domain name.
14:01 EDT (18:01 UTC): A volunteer PyPI Admin posts a message about this phishing attack in the PyPI Admins chat.
18:37 EDT (22:37 UTC): A community member posts about their experience on Python Forums
19:18 EDT (23:18 UTC): On-call PyPI Admin sees the message and escalates to another volunteer PyPI Admin for assistance, while submitting abuse complaints to the domain registrar NameSilo (report #1) and content delivery network (CDN) provider Cloudflare (report #2).
19:38 EDT (23:38 UTC): A volunteer PyPI Admin responds, and begins investigation of the phishing attack.
20:07 EDT (00:07 UTC): The volunteer PyPI Admin shares findings and some actions taken in chat, and has to leave for personal reasons.

2025-07-27 Sunday

06:34 EDT (10:34 UTC): On-call PyPI Admin updates that the registrar has indicated they should submit a different form, which they do. They also confirm that the PSF Trademarks Working Group are also working on this from a trademark perspective to notify the CDN and registrar of the abuse.

2025-07-28 Monday

08:57 EDT (12:57 UTC): PyPI Admin staff sees the comments in chat, begins investigation follow up
09:20 EDT (13:20 UTC): Available PyPI Admins (volunteer and staff) & other PSF parties meet to determine next steps.
10:22 EDT (14:22 UTC): PyPI Admins post an initial report to the PyPI blog, and share it on social media.
10:44 EDT (14:44 UTC): PyPI Admins post a notice to pypi-announce mailing list, and a similar is posted to the more general security-announce mailing list.
11:37 EDT (15:37 UTC): A new feature is added to PyPI to detect and warn users about phishing domains, which is deployed to production.
11:59 EDT (15:59 UTC): A threat hunter posts on Twitter about a finding in num2words 0.5.15
12:01 EDT (16:01 UTC): Another PyPI Admin submits another abuse report to Cloudflare (report #3), with more context and details - requests, headers, IP address, and more.
12:05 EDT (16:05 UTC): Cloudflare response to initial abuse complaint from Saturday (report #2) as "invalid".
12:18 EDT (16:18 UTC): PyPI Admins observe that Cloudflare placed a "Suspected Phishing" warning when visiting the phishing domain, reducing the probability for users to fall for the attack, despite declining the abuse reports.
12:20 EDT (16:20 UTC): NameSilo places the phishing domain under administrative ClientHold status.
12:23 EDT (16:23 UTC): Cloudflare responds to second abuse report (report #3) as "invalid".
12:38 EDT (16:38 UTC): num2words project owner responds on Twitter confirming removal of 0.5.15
12:54 EDT (16:54 UTC): num2words project owner responds on Twitter confirming removal of 0.5.16 as well as suspicious API Token

After the domain registrar NameSilo placed the domain name under clientHold status, new DNS resolutions failed, as there are no name servers. Host records for a client to resolve the domain name to an IP address will then fail. As DNS caches expired, users no longer were able to resolve the domain name, and thus unable to access the phishing site.

Incident is considered resolved, PyPI Admins continue to monitor the situation, and analysis of the attack continues.

Impact Analysis

The phishing attack was targeted at PyPI users, and since we were able to obtain at least one confirmed IP address of the hosting server, we have found 4 such successful phishing attacks, and have taken action on them.

A single account appears to have further activity beyond credentials being compromised, and the attacker uploaded releases to PyPI.org via a newly-provisioned API Token. num2words versions 0.5.15 and 0.5.16 were uploaded to PyPI.org, which included malware, and removed within hours of being uploaded by the owner of the account.

The impacted user posted about the activity on Twitter:

Thanks for the heads up! There was a phishing attack on pypi this morning. The compromised version of num2words v 0.5.15 have been removed.

and later:

I found a weird token in our pypi account, probably the attacker had created it. I removed the token and deleted the malicious version again (0.5.16). I also created new backup TOTP codes for MFA. Will keep an eye on it but hopefully they won't be able to reupload the malware.

An advisory has been published PYSEC-2025-72 to help end user and tooling to detect the malicious versions.

Takeaways

Anti-impersonation Email Prevention

PyPI has settings for Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting & Conformance (DMARC) to help prevent phishing attacks by verifying the authenticity of emails sent from PyPI.org.

However, each mail server that receives an email from PyPI.org is responsible for checking these values, and taking action based on the results of those checks. If the receiving mail server does not check these headers, or does not take action based on the results, then the email may still be delivered to the user's inbox. In this case, it appears that the phishing email was delivered to some users' inboxes, despite the presence of these headers.

In other cases, the receiving mail server may have checked the headers, and presented the user with a "Looks like Spam" warning, leaving it up to the user to decide whether to trust the email or not. This is a common practice, as many email providers do not block emails outright, but instead mark them as spam or suspicious, allowing users to make the final decision.

Ultimately, it is up to the user to be vigilant and cautious when clicking links in emails, especially when the email is unexpected or from an unknown sender.

Abuse Reporting & Responses

We were surprised that our reports to Cloudflare were rejected due to them being unable to confirm phishing, which lead to a longer-than-expected period of the phishing domain being online. We don't have additional visibility into why these reports were initially considered invalid by Cloudflare or why they did eventually result in a takedown, but we will review and determine if future reports could be made more actionable.

Alternate spelling domain names

The PSF is exploring the transfer of domain names used in this attack and other similar domains to have them registered to the PSF, and prevent future abuse. This effort has significant costs associated with it, so the outcome is not guaranteed.

If successful, this would allow the PSF to take control of the domain names, and possibly redirect them to either a warning page, or to the official PyPI.org website, preventing future phishing attacks using these domain names.

Call to action

Some things you can do to help prevent this kind of attack in the future:

If you have a dormant PyPI account, consider removing it if you do not need it. This will help reduce the number of potential targets for attackers.
If you have an older PyPI account, and have not logged in since 2FA has been required, consider logging in and enabling 2FA on your account. This will help protect your account from future phishing attacks.
Use WebAuthn via browser or hardware security keys for 2FA on your PyPI account. This will help protect your account from phishing attacks, as the attacker would need access to the second factor to complete the login process.

Security is a never-ending process, and we are always looking for ways to improve our security posture. If you have specific ideas or suggestions for improving PyPI security, and are willing to help implement them, consider checking our Issue Tracker or if you have something more sensitive, you can email security@pypi.org.

This work would not be possible without generous donations, please consider supporting the PSF to ensure this kind of work can continue to serve the worldwide Python community.

Indicators of Compromise

Analysis exposed some indicators of compromise (IoCs) that may be useful for detecting this attack, and similar attacks in the future.

Domain name: pypj.org
IP address: 45.9.148.108 - the phishing email sending server
IP address: 45.9.148.85 - the phishing domain hosting server
Domain name: modirosa.com - used by attackers to establish accounts on PyPI.org
Domain name: necub.com - used by attackers to establish accounts on PyPI.org
PyPI Package: num2words - versions 0.5.15 and 0.5.16

CAPEC-94 - Adversary in the Middle (AiTM) Attack
CAPEC-98 - Phishing

PyPI Users Email Phishing Attack

Mike Fiedler — Mon, 28 Jul 2025 06:09:00 +0000

Read the follow-up post: Phishing Attack Follow-Up

~~(Ongoing, preliminary report)~~

PyPI has not been hacked, but users are being targeted by a phishing attack that attempts to trick them into logging in to a fake PyPI site.

Over the past few days, users who have published projects on PyPI with their email in package metadata may have received an email titled:

[PyPI] Email verification

from the email address noreply@pypj.org.

Note the lowercase j in the domain name, which is not the official PyPI domain, pypi.org.

This is not a security breach of PyPI itself, but rather a phishing attempt that exploits the trust users have in PyPI.

The email instructs users to follow a link to verify their email address, which leads to a phishing site that looks like PyPI but is not the official site.

The user is prompted to log in, and the requests are passed back to PyPI, which may lead to the user believing they have logged in to PyPI, but in reality, they have provided their credentials to the phishing site.

PyPI Admins are looking into a few methods of handling this attack, and want to make sure users are aware of the phishing attempt while we investigate different options.

There is currently a banner on the PyPI homepage to warn users about this phishing attempt.

Always inspect the URL in the browser before logging in.

We are also waiting for CDN providers and name registrars to respond to the trademark and abuse notifications we have sent them regarding the phishing site.

If you have received this email, do not click on any links or provide any information. Instead, delete the email immediately.

If you have already clicked on the link and provided your credentials, we recommend changing your password on PyPI immediately. Inspect your account's Security History for anything unexpected.

inbox.ru Domain Prohibition Follow-up

Mike Fiedler — Fri, 25 Jul 2025 06:09:00 +0000

A follow-up to the previous post.

We have since learned that the campaign was orchestrated by the company that owns the inbox.ru email domain, and not by a malicious third party as we initially suspected.

Following the previous post, a representative of the parent company for inbox.ru reached out to PyPI Admins to discuss the situation. They expressed their desire to resolve the issue, and reinstate the ability for their users to register for PyPI accounts with email addresses from the inbox.ru domain.

They confirmed that the user account registrations on PyPI originated from an internal security team, "to prevent possible abuse of external libraries for attacks on our systems".

They also confirmed that they have held staff meetings and have decided to abandon this practice, and develop alternate methods for detection and prevention of abuse, and have apologized for the incident.

As such, we have re-enabled the ability for users to register accounts using the inbox.ru email domain, and to add inbox.ru email addresses to existing accounts.

We will continue to monitor the situation, and if we see any further abuse from this domain or others, we will take appropriate action to protect PyPI users and resources.

Prohibiting inbox.ru email domain registrations

Mike Fiedler — Tue, 15 Jul 2025 06:09:00 +0000

A recent spam campaign against PyPI has prompted an administrative action, preventing using the inbox.ru email domain. This includes new registrations as well as adding as additional addresses.

The campaign created over 250 new user accounts, publishing over 1,500 new projects on PyPI, leading to end-user confusion, abuse of resources, and potential security issues.

All relevant projects have been removed from PyPI, and accounts have been disabled.

Background

Users are welcome to use any valid email address to register a new account, however this delegates some of the responsibility of account security to the email provider.

PyPI uses the disposable-email-domains list to prevent new registrations using disposable email addresses, and PyPI maintains its own internal block list, updated by PyPI Admins in response to discovering abuse.

See a previous post for a previous case of prohibiting a popular email domain provider.

Timeline

Here's a timeline of the events I was able to put together

2025-06-09 first user account created, verified, 2FA set up, API Token provisioned
2025-06-11 46 more user accounts created over the course of 3 hours
2025-06-24 207 more user accounts created over the course of 4 hours
2025-06-29 New projects are created a file uploads start

Here's a table showing how many projects were published on each date:

Date	Number of Projects
2025-06-26	9
2025-06-27	295
2025-06-28	39
2025-06-29	119
2025-06-30	740
2025-07-01	249
2025-07-02	46
2025-07-10	16
2025-07-11	12

Total: 1,525

Details

The projects were created with a variety of names with no code inside, so this wasn't a case of malware, but possibly using popular projects' entrypoints (often a command line execution interface), as those are not required to be the same as the project name on PyPI.

This pattern seems to be consistent with setting up a large number of accounts, confirming access, and then executing a large-scale "attack". This may have proven to be a "dry run" for a future attack, depending on the success of this campaign.

PyPI Admins were alerted to this condition initially on 2025-07-08 from a user telling us that they were working with a Large Language Model (Sonnet 4) recommending installing a project that did not exist - aka "slopsquatting". This is a good reminder that users should always verify the project names they are installing, and not copy & paste the name of a project suggested by a third party, such as an AI model or random person on the internet.

Thanks again to users who are vigilant and report issues to us!

Hopefully we can reverse this decision at some point in the future when we have more confidence in this email provider's ability to prevent abuse. If you work at this provider, please email us at security@pypi.org to discuss this decision.

Incident Report: Organizations Team privileges

Ee Durbin — Mon, 14 Apr 2025 06:09:00 +0000

On April 14, 2025 security@pypi.org was notified of a potential security concern relating to privileges granted to a PyPI User via Organization Teams membership persisting after the User was removed from the PyPI Organization the Team belongs to.

We validated the report as a true finding, identified all cases where this scenario had occurred, notified impacted parties, and released a fix. A full audit determined that all instances were accounted for, with no unauthorized actions taken as a result of the issue.

Timeline of events

2025-04-14 16:37 UTC A PyPI User who has been testing out our Organizations features noticed the issue and reported it according to our Security Policy to security@pypi.org.
2025-04-14 17:02 UTC PyPI Security acknowledges receipt.
2025-04-14 17:22 UTC PyPI Security validates the report as a true finding.
2025-04-14 17:58 UTC PyPI Security validating test and hot fix prepared for internal review.
2025-04-14 18:30 UTC PyPI Security removes invalid Team Membership and notifies the owners of the only other actively impacted Organization. public PR opened with fix.
2025-04-14 18:33 UTC Hot fix is merged.
2025-04-14 18:39 UTC Hot fix deployed and live on PyPI.
2025-04-14 19:06 UTC Security audit complete, validating that only two instances of this had occurred, with no unauthorized actions taken as a result of the persisted privileges.

Details

PyPI Organizations have been a feature on PyPI since they were first enabled on April 20, 2023. This issue was introduced in the initial development of Organizations features, and was mitigated April 14, 2025.

PyPI Organizations are quickly seeing more use as we (finally) exit our public beta period. In the last month we have gone from 70 Community Organization beta testers to 1,935 active Organizations¹, so it is of little surprise that we are surfacing a few more issues as a result.

Thanks to PyPI's strong test coverage identifying and validating the issue was rather trivial, and getting a fix prepared and out the door was straight forward.

In total, this incident was resolved in 2 hours and 2 minutes from the time of report.

Response

Given that this is an otherwise straightforward bug, I thought I would take a moment to share how the issue was validated as well as how we audited. I've replaced the specific organization, team, and user strings below, but otherwise all of this is copied and pasted from the terminal session used as I worked this report.

I spun up a local development environment of pypi/warehouse from the current main branch locally and followed the reporter's steps to reproduce:

The basic reproduce steps were:

Add a user to an organization as a member

Add that member to a organization team

Remove the member from the organization

Noting that indeed, the User's team role persisted, and they could continue to act with those privileges on PyPI.

At that point the reporter and PyPI Administrators team were notified that we had a finding, and that review would be needed shortly to get a fix merged and deployed.

From there, I added a failing test which further validated the issue, and got to work creating a patch which turned the test green.

Now, with time to wait while a volunteer PyPI Admin returned I focused on assessing if this was actively impacting any other organizations:

warehouse=> select o.name as organization, t.name as team_name, u.username as user, tr. role_name as team_role, ors. role_name as organization role from team_roles tr join teams t on t.id=tr.team_id join organizations o on t.organization_id=o.id join users u on u.id=tr.user_id left outer join organization roles ors on ors.organization_id=t.organization_id and ors.user_id=tr.user_id where ors. role_name is null; organization | team_name | user | team_role | organization_role --------------+-------------+-----------+-----------+------------------- spam | Spam-owners | spamlover | Member | (1 row)

This query showed me that one instance of a User having an Organization Team Role without being a Member of that Organization still existed on PyPI². The reporter made clear that they had already resolved the instance from their testing.

I drafted a notice to the five users with role Owner on the impacted Organization, and took a moment to realize that this was our first time emailing Organization Owners as a group, and that we needed to account for the fact that Users on PyPI do not necessarily already know one-another's email addresses, as it is not required to invite them to a Project or Organization. A quick gut-check in the PyPI Moderators channel validated my plan to Bcc: all the Owners rather than To: them as a group.³

By that point, the volunteer PyPI Administrator was available to review the PR and drafted e-mail. We notified the impacted Organization, and then coordinated to open the PR publicly and approve/merge it hastily before completing a more in-depth audit.

Luckily this audit was straightforward using our internal security records combined with the fact that there has been minimal churn in the Organization membership in the short time that Organizations has been in broader use.

warehouse=> select o.name, time, tag, u.username from organization_events oe join users u on (additional->>'target_user_id')::uuid=u.id join organizations o on oe.source_id=o.id where tag in ('organization:team_role:remove', 'organization:organization_role:remove') order by time; name | time | tag | username ------------+----------------------------+---------------------------------------+------------------- lumberjack | 2023-05-02 03:01:18.935901 | organization:organization_role:remove | sirrobin holygrail | 2023-07-06 12:55:43.261593 | organization:organization_role:remove | blackknight ni | 2023-09-18 12:07:17.389244 | organization:organization_role:remove | shrubbery parrot | 2024-02-04 19:23:25.354344 | organization:organization_role:remove | exparrot spam | 2024-08-24 01:40:22.405746 | organization:organization_role:remove | spamlover spam | 2025-02-09 18:14:13.891224 | organization:team_role:remove | eggandspam albatross | 2025-03-07 06:55:29.446617 | organization:organization_role:remove | nudge albatross | 2025-03-07 06:55:37.271176 | organization:organization_role:remove | wink cheese | 2025-03-13 18:25:54.650905 | organization:team_role:remove | gorgonzola cheese | 2025-03-13 18:26:02.525162 | organization:team_role:remove | camembert ministry | 2025-03-20 07:53:45.616404 | organization:organization_role:remove | sillywalks argument | 2025-03-31 15:52:18.186223 | organization:organization_role:remove | contradiction fishslap | 2025-04-14 15:12:14.023183 | organization:organization_role:remove | danceking fishslap | 2025-04-14 15:24:54.208641 | organization:organization_role:remove | danceking fishslap | 2025-04-14 15:27:22.954624 | organization:team_role:remove | danceking

Here, we see the spamlover user being removed from the spam Organization on 2024-08-24, without being removed from the team, confirming our finding from the earlier query.

We also see the User danceking from the fishslap Organization being removed from the Organization multiple times, before the reporter removed them from their assigned Team.

This allowed us to confirm that beyond the already identified incidents, no other Organizations had found this problem before without letting us know.

Thanks

First and foremost, thanks to our reporters, Matthew Treinish and Jake Lishman of IBM Quantum for finding and reporting this issue.

We are grateful for the entire community of security researchers and users who find and report security issues to PyPI in accordance with our Security Policy. PyPI relies on the efforts of our community to help us find and resolve issues like these before they become critical issues. Cooperation between all parties helps to improve the security of open source, and none of us could do it alone.

The tools and capabilities we've evolved in PyPI over the past six years have really come to be an asset in situations like these. I'm grateful to all the contributors and admins who have helped us to build them 💜.

Ee Durbin is the Director of Infrastructure at the Python Software Foundation. They have been contributing to keeping PyPI online, available, and secure since 2013.

As of writing, there are 6,682 remaining Organization Requests to review. ↩
It also showed me that our modeling could certainly be improved. In general all the joins are fine, but the fact that a TeamRole is directly related to a User rather than to their OrganizationRole allowed for this disconnect in the first place. ↩
Another thing to work on moving forward. We recently added some "in-app" messaging for PyPI Admins and Support to contact users regarding Organization Requests, which could be useful for group communication with Organization Owners. ↩

Introducing our new Terms of Service

Ee Durbin — Tue, 25 Feb 2025 06:09:00 +0000

We're introducing a new Terms of Service to formalize our relationship to users and enable us to move forward with providing new features and services, specifically Organization Accounts.

PyPI has had some form of Terms of Use document for users since it began accepting uploads in 2005 and has only been updated twice¹ since. These terms have primarily served to protect PyPI and the Python Software Foundation (PSF) who operates it.

Over time we have introduced additional policies to protect our users and community such as our Code of Conduct Privacy Notice and Acceptable Use Policy.

Our new Terms of Service formalizes our relationship to PyPI users, makes protections for the PSF and PyPI users more explicit, and establishes terms we need to provide Organization Accounts to paid Corporate Organizations.

We have worked with our legal team to retain compatibility with the superseded Terms of Use while adding as permissive a set of new terms as possible to ensure that PyPI users and the PSF are protected.

You will notice a banner on login reminding you of these updated terms, as well as an email notification to your primary email address if it has been verified. These terms will take effect for existing users March 27, 2025 and your continued use of PyPI after that date constitutes agreement to these new terms.

See these commits for substantive changes since the Terms of Use was introduced: 2009-11-29 and 2016-12-16. ↩

PyPI Now Supports Project Archival

Facundo Tuesca — Thu, 30 Jan 2025 06:09:00 +0000

Support for marking projects as archived has landed on PyPI. Maintainers can now archive a project to let users know that the project is not expected to receive any more updates.

This allows users to make better decisions about which packages they depend on, especially regarding supply-chain security, since archived projects clearly signal that no future security fixes or maintenance should be expected.

Project archival is not deletion: archiving a project does not remove it from the index, and does not prevent users from installing it. Archival is purely a user-controlled marker that gives project owners the ability to signal a project’s status; PyPI has no plans to delete or prune archived distributions.

Support for archival is built on top of the project quarantine feature. Read more about that feature in PyPI’s December 2024 blog post. You can also find more details about the project archival’s implementation on the Trail of Bits blog.

Archiving a project

Owners of a project can archive it by navigating to the project’s settings page and scrolling down near the end to the following section:

As described in the warning message, archiving prevents new uploads to the project. After archiving the project, users will see the following notice in the project’s main PyPI page:

Maintainers are encouraged to make a final release before archiving, updating the project’s description with more context about the archival.

Finally, the project owners can always unarchive a project if needed.

Stay tuned

Project archival is the first step in a larger project, aimed at improving the lifecycle of projects on PyPI. That project includes evaluating additional project statuses (things like “deprecated” and “unmaintained”), as well as changes to PyPI’s public APIs that will enable clients to retrieve and act on project status information. You can track our progress on these fronts by following along with warehouse#16844!

Acknowledgements

This feature was developed by Trail of Bits. We would like to thank the PyPI admins and maintainers, including Mike Fiedler and Dustin Ingram, for their time and consideration throughout the design and development process.

The funding for this feature’s development comes from Alpha-Omega. Alpha-Omega’s mission is to protect society by catalyzing sustainable security improvements to the most critical open-source software projects and ecosystems.

Project Quarantine

Mike Fiedler — Mon, 30 Dec 2024 06:09:00 +0000

Earlier this year, I wrote briefly about new functionality added to PyPI, the ability to quarantine projects. This feature allows PyPI administrators to mark a project as potentially harmful, and prevent it from being easily installed by users to prevent further harm.

In this post I'll discuss the implementation, and further improvements to come.

Background

Malware on PyPI is a persistent problem.

PyPI has concepts of Projects, Releases, and Files¹. These are all discrete data models², and behave slightly differently based on their characteristics. A Project may have 0 or more Releases, a Release may have 1 or more Files.

Researchers will often report a given Project as malware, and will link to a specific location in a File for a given Release, per the PyPI Security process.

PyPI will receive malware reports³ that are often relevant to an entire Project. Simply put: a Project, along with all of its Releases (usually 1) and Files (usually 1-2) are all part of a similar campaign, and should be removed from PyPI to protect end users. This is not universally true, as malware has been added to established, mature Projects via a new Release after some sort of account access takeover, so there may be a need to consider reporting malware for a given Release/File - something not yet fully implemented via Observations or the beta Malware API.

When reviewing and acting on malware reports, PyPI Admins had one main tool at their disposal: complete removal of the Project from the PyPI database. This is often coupled with prohibiting the Project name from being reused. PyPI has functionality irrespective of malware to prevent File name reuse.

The impact of these removals can be disruptive, and removals are pretty much irrevocable - it's the same mechanism PyPI warns project owners about when they elect to remove their project from the index⁴.

Further, the longer a malicious Project remains publicly available, the greater the potential for end users to install and become victims of said malware. With the current full-time security staff for PyPI == 1, there is potential for malware to remain installable by users for longer periods of time, and asking volunteer PyPI Admins for extra hours of work is not sustainable.

Reducing the time window when a malicious Project/Release/File is available for end users to become victims is an improvement, and further reduces the incentive for malicious actors to use PyPI as their distribution method.

Implementation

The implementation of Project Quarantine shape as I learned more about the possible states a project could be in. I jotted down some basic requirements for the feature:

Project exists on PyPI that has Releases and Files
Project is not installable (hidden from simple index) while in quarantine
Project is not modifiable by the project owner while in quarantine
Project state is visible to Project Owners, security researchers, and PyPI Administrators
Project state can be reverted by a PyPI Administrator to restore general visibility
Project can be removed/deleted by a PyPI Administrator

With those in mind, I set out to implement the feature.

Take a page from the book of Yank

Prior to this change, an existing feature was "Yank", per PEP 592.

A Project with no Releases will be listed in the Simple Repository API⁵, but the resulting detail page will not have any links, making it effectively uninstallable⁶. One idea was when quarantining a Project, we could mark it as having no Releases, and thus excluding it from the index.

The difference from "yank" is that a yanked Release is still installable by clients, and quarantined items should not be installable - so we'd have to explore where to make the change and how that would impact clients. Yank is also applied to a Release (and all of its Files), not a Project. We could apply a change to every Release for a Project, instead of Project-wide, and thus set ourselves up for quarantining individual Releases.

This ends up more complex, trying to account for a rare edge case where a mature Project has a new Release that needs to be quarantined, and would prevent disruption of existing users of prior Releases.

We accept that this might happen, and track very closely if and when it does, and defer implementation until that time.

Create an Observer-only visibility API

I had previously built a new beta API infrastructure to allow Observers to report malicious Projects. One idea was to add a new authenticated API endpoint to allow querying the current list of quarantined Projects, and supply links to their Releases and Files for consumption.

Thus, a researcher could download the artifacts in question, but not via pip install ...

I ended up not pursuing this approach, as the beta authenticated APIs are still being developed, and I didn't want to add more functionality before we swing back and figure out some critical authentication and authorization issues needed for the future of management API endpoints.

Lifecycle Status

The exploration to remove items from the Simple Repository API paid off, and pointed me in the direction that turned into LifecycleStatus, which is a new status applied to a Project.

A state diagram to illustrate the flow of the Project through the states:

stateDiagram-v2 [*] --> None : default Project state None --> QuarantineEnter : Project quarantined, no longer in Simple API QuarantineEnter --> QuarantineExit : Admin clears Project, for general visibility QuarantineExit --> QuarantineEnter : Project re-quarantined (rare)

Adding LifecycleStatus state to the Project model helps other functions in the code make a single-point decisions, and allows for a more complex state machine to be implemented in the future. Potential states could include "Archived", "Deprecated", and others.

Admin Interface

Since the point of the implementation is to allow PyPI Admins to manage the state, and oftentimes during nights, weekends, and holidays, and from a phone web browser, I wanted to make the interface as simple as possible.

When developing the Admin interface, I recorded a video to share with the team, so they could see the changes in action and provide feedback.

Admin Interface for Quarantine 👩‍💻 - Watch Video

Note: Some of the UIs in the video may have changed since the recording, almost all data is mocked.

As we use the admin interface more, we'll likely find areas to improve, and iterate to make the process more efficient.

Usage

Since August, the Quarantine feature has been in use, with PyPI Admins marking ~140 reported projects as Quarantined.

Of these, only a single project has exited Quarantine, others have been removed.

The one project cleared was a project containing obfuscated code, in violation of the PyPI Acceptable Use Policy. The project owner corrected the violation after being contacted by PyPI Admins. I've created some outreach templates to help with this process, and have reached out to 20+ project owners to inform them of their violation, and to provide guidance on how to correct it.

Future Improvement - Automation

The next step in the Quarantine feature is to add the ability to automatically place a Project in Quarantine when "enough credible reports" are received. That's in quotes because we're still working on defining what "enough" and "credible" mean - and how to automate the process without causing undue harm to legitimate projects.

To date, we've onboarded a number of security researchers, internally known as "Observers" to use a beta API endpoint to submit malware reports. We also allow any authenticated PyPI user to submit a malware report via a web form on a Project's page (technically a Release... but that's a different story). To prevent abuse of the quarantine system, we could place a minimum requirement of Observers reporting a given Project, as well as only consider a single non-Observer report in the calculation.

For example, these combinations of reports for a Project would result in a quarantined project:

2+ Observer reports
1 Observer + 1 non-Observer report

This is only one idea so far - we could explore other combinations as they surface.

The idea behind Auto-Quarantine is to support the concept of receiving multiple reports for the same Project during nights and weekends, and reduce the Project's time alive on PyPI, while preserving the ability to revert the state in a non-destructive manner in the event of a false-positive.

This will likely also pair with the need to add a "notify admins" feature. Probably a webhook to our Slack channel, so we can be notified in real-time when a Project is quarantined, and can take action as needed, as well as adding more visibility to quarantined projects in the Admin interface.

There's plenty of chewy bits to work on, and I'm excited to see how LifecycleStatus evolves, and share more about it in the future.

See https://pypi.org/help/#packages for more ↩
See https://github.com/pypi/warehouse/blob/main/warehouse/packaging/models.py for more ↩
Referred to internally as Observations(kind="is_malware") ↩
Yes, it's true, some of the database objects can be reconstructed, but it is time-consuming and tricky, used only in severe catastrophe situations. ↩
See Simple repository API - Python Packaging User Guide for more ↩
Roughly 3% of Projects in the simple index have 0 releases. Excluding these would save ~1 MB of the ~29 MB main index HTML response. ↩

The Python Package Index Blog

PyPI has completed its second audit

Findings

Details

TOB-PYPI26-1: OIDC JTI anti-replay lock expires before JWT leeway window closes

TOB-PYPI26-6: IP ban bypass via macaroon API token authentication

TOB-PYPI26-8: Organization members can invite new owners due to a missing manage permission check

TOB-PYPI26-10: Wheel METADATA is served to installers without validation against upload metadata

TOB-PYPI26-13: Organization-scoped project associations persist after project transfer or removal

Summary

Incident Report: LiteLLM/Telnyx supply-chain attacks, with guidance

What happened with LiteLLM and telnyx?

Why is this malware different?

What is PyPI doing to mitigate malware?

Protecting yourself as a developer

Dependency Cooldowns

Locking Dependencies

Protecting your project as an open source maintainer

Securing release workflows

Trusted Publishers over API tokens

Adding 2FA to open source development accounts

How can you support this kind of work?

Dispatch from PyPI Land: A Year (and a Half!) as the Inaugural PyPI Support Specialist

PyPI in 2025: A Year in Review

Security First, Security Always

Enhanced Two-Factor Authentication (2FA) for Phishing Resistance

Trusted Publishing and Attestations

Proactive Security Measures

Transparency and Incident Response

Safety and Support Requests

Malware Response

Support Requests

Organizations Growth

A Better PyPI for Everyone

Looking Ahead to 2026

Acknowledgements

PyPI and Shai-Hulud: Staying Secure Amid Emerging Threats

How does this relate to PyPI?

What can I do to protect my PyPI account?

References

New Login Verification for TOTP-based Logins

What's Changing?

Why This Change?

What You Need To Do

Trusted Publishing is popular, now for GitLab Self-Managed and Organizations

Growing Adoption and Impact

Expansion of Trusted Publishing to GitLab Self-Managed Beta

Pending Trusted Publishers for Organizations Feature

What's next?

Phishing attacks with new domains likely to continue

What is PyPI doing to protect users?

What can you do as a maintainer?

Token Exfiltration Campaign via GitHub Actions Workflows

Summary

Timeline and Response

What You Can Do

Acknowledgements

Preventing Domain Resurrection Attacks

Summary

Background

Domain Expiration Timeframe

PyPI Actions

Recommendations for end users

That's all for now, folks

Related reading

PyPI now serves project status markers in API responses

Summary

Background

The status quo before status markers

Project status markers

Consuming status markers

Conclusion

Acknowledgements

Preventing ZIP parser confusion attacks on Python package installers

Summary

Wheels are ZIPs, and ZIPs are complicated

What is PyPI doing to prevent ZIP confusion attacks?

RECORD and ZIP issues in top Python packages

What actions should I take?

Acknowledgements

`RECORD` and ZIP issues in top Python packages