The Python Package Index Blog

Incident Report: File Hosting Errors

Mike Fiedler — Tue, 08 Sep 2026 06:09:00 +0000

Executive summary

For about two weeks in August 2026, some PyPI users hit intermittent 502 and 503 errors downloading files from files.pythonhosted.org, triggering failures during installation from PyPI. Thanks to our users filing reports in the support tracker; one report in particular narrowed the problem to a single cache node.

Two separate problems were uncovered. A canary deployment inside Fastly's network had triggered a misconfiguration at one cache node, causing Fastly's routing layer to return 502 responses for traffic reaching the affected cache node. Separately, I found and fixed several bugs in our own Fastly configuration around origin fallback and range request behavior. Those had been there for a while, and only surfaced while digging into these reports.

Both intermittent problems are now fixed, and downloads are back to full function since August 28.

Background: How PyPI's file hosting cache works ¹

Most people run pip install (or your installer of choice) and it just works: a request goes out, the desired file comes back. Behind the scenes, files.pythonhosted.org is a Fastly CDN service in front of three origins (aka 'backends').

When a file is uploaded, PyPI writes it to Amazon S3 first as the main, durable copy. A background job syncs it to Backblaze B2, because Fastly and Backblaze have a zero-cost egress agreement: serving files out of B2 through Fastly doesn't cost anything beyond storage fees.

On the reader (installer) path, Fastly tries B2 first. If B2 doesn't answer, or answers with something we don't expect, Fastly falls back to S3. PyPI uses the Amazon S3 Glacier Instant Retrieval storage class to balance storage and retrieval costs. When Fastly calls S3 as a fallback, this costs more than from B2, but will continue to work for consumers as a stop-gap.

Once cached, Fastly no longer has to check B2 or S3 - the file should never change, and the Cache-Control header sets max-age=365000000, immutable, public - about 11.5 years.

A third backend named Conveyor handles everything that isn't a package file request, like predictable URLs, plus a handful of legacy redirects.

flowchart TD Client([Client request]) --> Edge{Fastly edge} Edge -->|package file| B2[(B2: egress-free cache)] Edge -->|everything else| Conveyor[Conveyor] B2 -->|200 or 206| Response([Response to client]) B2 -.->|404, timeout, or 5xx| Archive[(S3: origin, fallback)] Archive --> Response Conveyor --> Response

That fallback path only works if the edge notices B2 has failed. One of the bugs I fixed was that it didn't always notice correctly, which added to the "normal" error noise.

Timeline

August 15

Fastly's report places the start of the problem on this Saturday, at a single Seattle-area cache node. This is corroborated by #11876.

August 17

The first two reports of persistent 502s from files.pythonhosted.org are opened, #11895/#11897.

August 18

#11908 adds a detailed reproduction, showing 88 recorded 502s over six hours, across 32 unrelated packages, including the small .whl.metadata range requests installers use to read PEP 658 metadata. With three open network reports, I go digging in Datadog Logs for the corresponding PyPI Files errors and find nothing of consequence. infra#237 merges, fixing the B2-to-archive failover for the case where B2 doesn't respond at all, rather than responding with an error.

August 19

#11925 isolates the problem to one Fastly cache node, cache-pae2080020: 502 for every request routed to it, for over 19 hours, confirmed by x-served-by headers on the failing responses. Fastly's network operations removes a routing override sending a slice of our traffic to the affected point of presence. infra#238 merges, improving the logging configuration for the file hosting service. infra#239 merges, rejecting HTTP methods that have no business hitting a file host.

August 20

Fastly observes recovery at the affected point of presence, and later confirms the elevated error rate has stopped.

August 21

infra#241 merges, exempting suffix and multi-range requests from segmented caching, after a morning spike traced to a single client sending logically invalid ranges.

August 24

infra#243 merges, after two broken parallel downloaders generated 41,315 more of the same class of error in a single day.

August 28

Fastly patches the underlying canary configuration bug on their side, and excludes all PSF traffic, including PyPI, from their canary cohort. infra#245 merges, fixing a URL-normalization ordering bug that let a bad segmented-caching response get cached and served to every subsequent request for the same file.

Contributing factors

POP goes the canary ²

Fastly runs a canary cohort, a subset of their fleet running caching and routing software ahead of a full rollout. PyPI's traffic had been part of that cohort for a number of years, helping Fastly engineering validate changes.

A partial rollback during a canary deployment left the caching configuration on one Seattle point of presence (POP) reverted while the routing configuration in front of it was not. The mismatch caused that routing layer to return 502s.

Fastly has since removed all PSF traffic, including PyPI, from the canary program. We'd like to get back to participating eventually, once clearer controls and notifications exist around this traffic. It's a reasonable way to help Fastly validate infrastructure changes before they hit everyone, and it hasn't cost us much before now.

Bugs at home

While that was going on, I found unrelated bugs in our own configuration that produced the same symptom: elevated 502s, and in a few cases 501s that looked like 502s from outside.

The archive fallback in the diagram above only ran when B2 answered with an error status. If B2 didn't answer at all (a timeout, a refused connection, a TLS failure), Fastly synthesized its own 503 and skipped straight past the code that would have tried the archive. Package files are immutable, so there was never a "try the archive" path for that case until infra#237 added one.

Separately, we use segmented caching to avoid pulling a full gigabyte-sized wheel into cache only to serve a Range request for partial content. That feature has narrower support for range syntax than HTTP does in general: it can't answer a suffix range (bytes=-1024, read the last N bytes) or a request with the start of the range past the end, and returns a synthetic 501 for either. Some installers use exactly this kind of suffix range to read wheel metadata without downloading the whole file, so those reads were failing outright until I started exempting them:

flowchart LR subgraph Before["Before infra#241 and infra#243"] direction TB C1([Client: suffix or inverted range]) --> E1{Fastly edge} E1 --> S1[Segmented caching] S1 --> R1([501 Not Implemented]) end subgraph After["After"] direction TB C2([Client: suffix or inverted range]) --> E2{Fastly edge} E2 -->|range shape not supported| N2[Segmented caching skipped] N2 --> R2([Normal range handling: 206 or 416]) end Before ~~~ After

A 501 for a malformed client request is the wrong status class. I've opened a support ticket with Fastly about the segmented-caching range handling. Once fixed, my handling code can probably be reverted.

Another bug: an existing segmented caching exemption check ran before the request URL was normalized, so a .metadata request with a query string still on it didn't match, kept segmented caching enabled, and got a 501 back from the archive backend for what should have been a normal fetch:

flowchart LR subgraph Before["Before infra#245"] direction TB C3([Client: <code>GET name.whl.metadata<b>?token=x</b></code>]) --> E3{Fastly edge} E3 -->|exemption checked before URL is normalized| S3[Segmented caching stays on] S3 --> B23[(B2)] B23 -->|501 for the 1MiB segment, cached at the edge| R3([Every later request: 501]) end subgraph After2["After"] direction TB C4([Client: <code>GET name.whl.metadata<b>?token=x</b></code>]) --> E4{Fastly edge} E4 -->|URL normalized first| X4[Exemption matches: segmented caching off] X4 --> B24[(B2)] B24 --> R4([Normal response, cached correctly]) end Before ~~~ After2

infra#245 moved the exemption check after URL normalization to close that hole.

None of these were new bugs. They'd been in the configuration already, and it took real traffic on large files with range requests to trigger investigation and resolution.

5xx volume over time

Fastly's own real-time analytics for the file hosting service show B2 errors (blue) climbing from August 15 onward while the S3 archive backend (pink) stays flat at zero, because the fallback that should have been routing failures there wasn't firing yet:

Our own Datadog metric shows a fuller story, from before the incident to past the end of it:

Note the log scale. The baseline was already noisy before any of this started, thousands to tens of thousands of 5xx responses, which is why the increase starting August 15 is easy to miss. The August 21 spike is the one that isn't: a single client sending logically invalid ranges, pushing the count to close to a million.

The cliff immediately after it is infra#241. Traffic past that point sits two to three orders of magnitude below the pre-incident baseline, tens to hundreds of errors rather than thousands. Some of what we'd been treating as background noise was this bug running the whole time.

Going forward

The Python Software Foundation is hiring an infrastructure engineer to add to the engineering staff of four. Part of their remit will be PyPI, which should help us catch conditions like this earlier and prevent rather than react. The continued financial support from our community - individuals and companies alike - makes that possible.

A lot of the traffic hitting files.pythonhosted.org is CI jobs installing the same dependencies they installed last run, and a large share of that can be traced back to GitHub Actions runs. If you're not already caching those downloads, it's worth turning on: setup-python's pip, pipenv, and poetry caching is opt-in via the cache input, off by default, and setup-uv's caching defaults to on for most GitHub-hosted runner events, but is worth checking. An unchanged dependency that's cached doesn't touch us on the next run at all, which means fewer requests for us to serve, and one less thing that can break your build if we or Fastly have a rough day.

Thanks

Thanks to everyone who took the time to file an issue and capture the details instead of just working around the problem.

If you run into file-hosting issues in the future, pypi/support is still the right place, and the more detail you can include (especially x-served-by headers and timestamps), the faster we can act on it.

This work would not be possible without generous donations, please consider supporting the PSF to keep this kind of infrastructure running. Thanks to Alpha-Omega, which sponsors my role.

or, how it's supposed to work ↩
while not perfectly accurate, I couldn't resist. ↩

Metadata requests no longer tracked in PyPI download counts

Mike Fiedler — Mon, 31 Aug 2026 06:09:00 +0000

On 2026-08-24 I shipped a change to the configuration that emits PyPI's download logs so that only requests for actual distribution artifacts are counted. A request has to end in .whl, .tar.gz, or .zip to produce a download record.

The counts are more accurate now, and existing systems based on PyPI's BigQuery dataset, like pypistats.org will display a different shape going forward.

If you maintain something that reads these numbers from the public dataset, the discontinuity at 2026-08-24 is expected and permanent.

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

Background

The logs are generated by Fastly's Edge, shipped to an AWS S3 bucket, parsed and anonymized by our linehaul functions in Google Cloud, and published to a Google-managed public BigQuery dataset.

Other objects

Everything PyPI serves for a release lives under the same /packages/<xx>/<yy>/<hash>/ prefix. Matching on that prefix alone counted a fetch of any part of a release as a download of the distribution itself.

PEP 658 .metadata sidecars. (estimated at 40%) Installers may fetch these to read a wheel's metadata without downloading the wheel. Every metadata fetch was being logged as a distribution download.
.asc GPG signatures. PyPI stopped accepting these in 2023, but the ones uploaded before then are still served, and no longer counted.
.egg uploads were separately deprecated in 2023. All of these remain downloadable, and none of them are counted.
Formats frozen for upload since 2016 under PEP 527, such as .exe, .msi, and .rpm, are about 0.2% of the files on PyPI, and are no longer counted.

The correction

Daily download quantity across all of PyPI, 60-day window ending 2026-08-31, from pypistats.org.

Before the change, daily totals cycled between roughly 4.5 billion on weekends and a little over 7 billion midweek. The curve steps down after 2026-08-24. The last few days of that window were still settling when the chart was captured, so read the shape of the change rather than the final data point.

Impact on existing data

If you compare download counts across 2026-08-24, the numbers will not line up. The counts after that date are lower and more accurate. Nothing was lost from the historical record - the older rows in BigQuery are unchanged, they were just measuring something broader than "someone downloaded this package" - they measured "someone downloaded a given file from PyPI". Most consumers of this dataset today do not filter specific to filename extensions, leading to inflated download counts for a given package.

However, if you wanted to query the dataset yourself, you can write your own SQL queries to be able to distinguish a single project's distribution file downloads from others with a BigQuery statement that looks a bit like this:

SELECT  DATE(timestamp) AS download_date,  COUNT(*) AS all_objects,  COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)$')) AS distributions_only,  COUNT(*) - COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)$')) AS others,  ROUND(100 * (COUNT(*) - COUNTIF(REGEXP_CONTAINS(file.filename, r'\.(whl|tar\.gz|zip)$'))) / COUNT(*), 1) AS others_pct FROM `bigquery-public-data.pypi.file_downloads` WHERE project = 'urllib3'  AND timestamp >= TIMESTAMP('2026-08-18')  AND timestamp < TIMESTAMP('2026-08-26') GROUP BY download_date ORDER BY download_date

Results:

download_date	all_objects	distributions_only	others	others_pct
2026-08-18	77477790	47268787	30209003	39.0
2026-08-19	74742551	45808710	28933841	38.7
2026-08-20	73495894	45011207	28484687	38.8
2026-08-21	69652309	42467783	27184526	39.0
2026-08-22	49665300	30080582	19584718	39.4
2026-08-23	50965479	30344490	20620989	40.5
2026-08-24	64241532	44012651	20228881	31.5
2026-08-25	46619401	46619401	0	0.0

For this particular query and time range, ~39% of the download counts are not the actual distribution files.

Downloads are not a popularity metric

Download counts are tricky to get right, and should not be used as a proxy for criticality or popularity. Volumes are often driven by misconfiguration of proxies or caches, CI systems running wild, or any variety of problems that occur with software. There's even folks out there who drive these numbers up artificially.

This change removes one source of potential confusion and misinterpretation, but does not mean download counts are an accurate measure of how many people use a package.

Future work: range requests

An HTTP response code 206 Partial Content counts exactly the same as a 200 OK right now. Reading two bytes out of a wheel to inspect its ZIP central directory is recorded as a download of the whole wheel, alongside a client that pulled all 30 MB.

We want to record the request type and the bytes actually transferred, so that analysis can distinguish bytes served from downloads counted. That work is not scheduled yet. Follow https://github.com/pypi/linehaul-cloud-function/issues/232 and https://github.com/pypi/linehaul-cloud-function/issues/252 for that.

How AWS Powers PyPI and the PSF

Jacob Coffee — Fri, 14 Aug 2026 06:09:00 +0000

Working on infrastructure at the Python Software Foundation (PSF) as the Director of Engineering is a broad job with many hats. Python turns up everywhere. It's in healthcare systems and government agencies, in research labs and classrooms, in one-person side projects and in infrastructure at companies with six-figure headcounts. Somebody is using it to analyze a genome right now and somebody else is using it to automate a spreadsheet they hate arranging by hand. That range has always been the interesting part of the PSF's work, and it's only broadened in the last couple of years as AI continues to pull people from many disciplines into writing Python.

At the PSF we support and maintain the infrastructure behind PyPI, Python.org, PyCon US, CPython, and a growing number of community services. The majority of the PSF's infrastructure runs on AWS, and nearly all of that bill is covered by credits from the AWS Open Source Credits Program.

The shape of it

PyPI takes over six billion requests a day and about thirteen billion counting file downloads. Package egress runs around 10 petabytes a day.

Almost none of that reaches AWS. Fastly serves it at the edge through their Fast Forward program at a hit ratio just under 99%, so only about one request in seventy makes it to origin. That caching is the core reason our AWS bill is not measured in the millions of dollars a year.

What does reach us is the part that is not cached, including things like user uploads, logins, and account management. That work runs on:

Amazon EC2 for the application fleet, almost entirely Graviton at this point. We're huge fans of Arm-based hardware at the PSF!
Amazon RDS for the Postgres database behind Warehouse, which is the application you're looking at when you're on pypi.org.
Amazon OpenSearch Service for project search.
Amazon S3 holds ~100 TB of package archives, plus the release history (that nobody ever wants to need).
Amazon EKS, newly stood up, as the target for migrating the whole fleet.

What changed this year

Our AWS spend is up about 69% comparing July 2026 to July 2025, and 40% across the trailing twelve months. That's new.

For context on how new: last October, Ee Durbin, our former Director of Infrastructure, noted that PSF's AWS credit usage had grown 25% over eight years while daily requests went from millions to billions. Eight years of holding that line. 2026 is the first year it broke.

Some of it is simply more of everything. Compute, search, and load balancing all climbed from 30% to 80%, which is the profile of more people and machines using the service. There are certainly more of both. A lot more Python being written, a lot more agents installing packages on someone's behalf, and a lot more CI runs from all the projects those people and agents are creating. Package repositories were designed around the assumption that a human decides to run pip install some number of times a day. That assumption is well past its expiration.

What we do about it

At the PSF, we take the credits seriously, which means spending real engineering time on utilizing what we have in an optimal way so our usage doesn't increase. Being frugal with the credits entrusted to us is vital.

When a widely used GitHub Action makes requests it doesn't need to make, fixing the Action beats anything we can do on our side. A popular Action can quietly turn a cache hit into a fresh download from PyPI on every run, and that adds up fast across thousands of CI pipelines. astral-sh/setup-uv shipped exactly that kind of fix.

On the PSF side, the EKS migration is the big one. Once we're there, autoscaling lets capacity track demand instead of sitting provisioned for peak at 3 AM (San Francisco time) on a Sunday.

There's just one little (read: major) constraint: Ee left the PSF earlier this year, and I'm currently the only person here working full time on infrastructure. Every item on that list is real and every one is slower than it should be. The PSF is hiring, and that hiring is possible in part because we aren't spending the same money on servers.

That said, hiring has a ceiling set by funding, and the growing gap between the demand placed on PyPI relative to staff operating and securing the service represents a risk to Python packaging. There is a very large amount of the software industry that sits on top of our services. Feature development, a rising volume of security reports, and day to day maintenance are currently being carried by one and a half full-time employees and one full-time employee on PyPI support requests. If your company installs from PyPI, ask internally about what your organization would be willing to fund. That question can be worth much more coming from inside a company than from the PSF. If you are interested in securing a service agreement with PyPI, please fill out our survey.

What the funding actually bought

AWS has backed PyPI two different ways, and both are worth outlining.

A very exciting investment was made in 2023, when AWS became PyPI's inaugural Security Sponsor, putting $144,000 into creating the PyPI Safety & Security Engineer role. That role is now funded by Alpha-Omega, and it's the reason malware comes down off PyPI in hours instead of whenever a volunteer has a spare moment. This investment also followed a pattern AWS had already established, having helped fund the rewrite, internationalization, and 2FA support for PyPI.

The credits do something quieter. They hold the infrastructure bill near zero, which means the PSF's general fund goes to employees, PyCon US, and other operational costs instead of servers. That's what pays for support staff handling the account recovery and project ownership requests that arrive every single day, and what makes it possible to ship things like Trusted Publishing, digital attestations, and organization accounts--instead of just keeping the lights on.

PyPI is free to use and will stay free to use at reasonable levels. Core publishing and installing stay free, permanently. What we are doing is building out real benefits for Organization accounts, and looking at sensible rate limits for the heaviest consumers at the top of the curve.

Which is exactly why in-kind support isn't just a line item to us. A sponsor choosing not to renew would mean an emergency migration or tens of thousands of dollars a month, either of which comes straight out of the work above. AWS has renewed every year since 2018, and the predictability of that is worth as much as the amount. The same goes for Fastly, Google Cloud, Datadog, Sentry, Depot, and PagerDuty, who carry other parts of this mountain of infrastructure.

How you can help

Four things, in order of how much they matter:

Cache your installs. If your CI pulls from PyPI on every run with a cold cache, you're a meaningful part of the graph. The PSF uses Docker cache mounts and pip's cache on our own builds, and npm and apt caching too, because it's faster for us and cheaper for everyone. Free package repositories aren't a limitless resource, and the fix is usually about six lines of config.

Sign up for a PyPI Organization if your company publishes to PyPI. Recurring revenue from Organizations is the most sustainable funding base we have, and Community organizations remain free. Look forward to announcements about future features for PyPI organization accounts soon.

Interested in a PyPI service agreement? Enhanced options like annual bulk seat purchases, higher project size limits, and prioritized support are available. The revenue helps fund the broader PyPI ecosystem while giving your organization benefits at scale. Fill out our service agreement interest survey and we'll follow up.

Ask your infrastructure vendors for multi-year commitments with open source foundations. Annual renewal cycles carry real risk for projects like ours. The five-year agreement the PSF signed with Fastly in 2024 is a sustainable model, and we'd like more of them.

The open letter the PSF co-signed last year called this a critical inflection point rather than a crisis. A year on, with our first real break in eight years of flat infrastructure costs, that still reads about right.

A big thanks to Mila Zhou and the AWS Open Source team, who have made the credits process about as painless as an annual funding renewal can be, and to everyone at AWS who's kept this program going for so long. PyPI would look very different without it.

This blog was recently edited to more accurately reflect numbers presented and work done.

The HTML representation of the index API is now frozen

William Woodruff — Tue, 11 Aug 2026 06:09:00 +0000

PyPI has adopted PEP 833, which "freezes" the HTML representation of the index API, which is also sometimes called the "simple API" or the "simple repository API."

New packages and releases will continue to appear in the HTML representation, meaning this has no breaking implications for downstream index consumers.

However, future standardization and development efforts will focus on the JSON representation, and downstreams that consume only the HTML representation are strongly encouraged to transition to the JSON representation to ensure access to the latest and greatest index features.

Background

As the name suggests, PyPI's primary responsibility is serving a package index. Installers (like pip and uv) consume this index as part of resolving and installing dependencies.

For historical reasons, there are two different standard representations of a Python packaging index:

The HTML representation, which predates standardization, and was retroactively standardized with PEP 503.

The HTML index is essentially a bare-bones version of the human-readable index that PyPI once served, back before PyPI was a resource that installers automatically retrieved packages from. It's that old!
The JSON representation, which was standardized with PEP 691.

Unlike the HTML representation, the JSON representation was designed from the ground-up to be useful to machine clients, rather than humans.

The two representations are more or less¹ coextensive in terms of serving the information that installers care about. This is intentional: efforts to extend the simple index over the years have worked hard to put that state into both representations.

Doing so with the HTML representation is often unwieldy, as metadata that naturally fits JSON's object model needs to be shoehorned into nooks and crannies (mainly HTML attributes and new <meta> tags) that won't interfere with pre-existing assumptions about the HTML's shape.

Unfortunately, that shoehorning process is has become harder over time:

Many consumers have made suboptimal, unsound assumptions about the shape of shape of PyPI's HTML representation. More precisely: they go beyond assuming the basic shape of the HTML, and actually make assumptions about semantically irrelevant aspects like whitespace, attribute order, &c.

This makes even "shape preserving" changes to the HTML representation fraught.

By contrast, consumers of the JSON representation don't generally encounter these issues. Some of that is probably a function of the JSON representation being newer, but a large part is likely because, unlike HTML, users don't find themselves open-coding a JSON parser in high-level languages.
Because the fundamental shape of the HTML representation can't be changed, adding new pieces of metadata to it becomes an exercise in creative munging: things that are natural to express as object members in JSON need to be shoehorned into new, flat <meta> tags or HTML attributes in the HTML representation.

PEP 792 is a good example of this. Compare the JSON representation:
```
{  "meta": {  "api-version": "1.4"  },  "project-status": {  "status": "quarantined",  "reason": "the project is haunted"  } } 
```
...to the HTML one:
```
<meta name="pypi:repository-version" content="1.4"> <meta name="pypi:project-status" content="quarantined"> <meta name="pypi:project-status-reason" content="the project is haunted"> 
```
This may not seem so bad in isolation, but keep in mind that this flattening and munging needs to happen for every single new addition to the index.
Even when we do successfully shoehorn features into the HTML representation (on paper, and on PyPI), it often doesn't matter to users: users are bifurcated between adoption of the JSON representation (which doesn't have these issues) and third-party (often private) indices that only implement the absolute bare minimum required in PEP 503.

As a result, even when we do update the HTML representation, users rarely benefit from it.

"Freezing" the HTML representation is our way of acknowledging this situation. It's our way of saying that we can't² deprecate the HTML representation, but that we don't want to keep extending it given how lopsided the tradeoffs are.

Do I have to do anything?

No!

The HTML representation is not going away, and will not go "stale" in terms of content updates. "Freezing" means that Python packaging as a whole has made a policy decision to not continue to munge features into its structure.

In other words: the HTML representation will continue to be served by PyPI for the foreseeable future, but Python packaging as a whole will no longer prioritize attempting to shoe-horn new pieces of metadata into its relatively inflexible HTML structure.

The longer answers:

If you're an "individual" downstream package consumer (e.g., a user who installs packages from PyPI through a tool like pip or uv): this will have no impact on you.

This is for two reasons: first, nothing is actually changing about the HTML representation from your (your tool's) perspective. Second, your tool is probably already preferring the JSON representation: pip has supported the JSON representation since 22.2, and uv has always supported it.
If you're a "bulk" index consumer (e.g., someone who mirrors all of PyPI into a public or private) copy: you also won't be affected by this.

However, we strongly recommend that you consider switching to the JSON representation as your primary consumption format: you can still serve the HTML representation in your mirror by reconstructing it from the JSON representation, plus you'll get access to fields and better structured metadata that the HTML can't offer.

There are some notable gaps. For example, PEP 700 added upload-time to the JSON representation only, under the assumption that it wouldn't be useful to package installers writ large. Years later, it turns out that cooldowns need this field, but that wasn't obvious in 2022! ↩
Yet. ↩

Releases now reject new files after 14 days

Seth Larson — Wed, 22 Jul 2026 12:00:00 +0000

The Python Package Index (PyPI) now rejects new files being uploaded to releases that are older than 14 days. This restriction was put in place to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised. As far as we are aware this has not yet been abused, but there is no technical reason beyond that attackers weren't aware it was possible.

Users should not yet rely on this behavior as there are no defined semantics for "releases no longer accepting new files" or APIs available to confirm the state of the release. Instead, these semantics will be defined once "Upload 2.0 API" and "Staged Previews" have been standardized by PEP 694.

The discussion of this behavior began during PEP 740 (Digital Attestations) back in January 2024. The discussion was restarted in March 2026 after the popular packages LiteLLM and Telnyx were compromised. These packages were compromised due to a "mutable reference" in these projects' usage of the Trivy GitHub Action.

Originally the discussion stalled due to some projects depending on this behavior to add support for new Python versions to already-published releases. To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for projects that have published new files to old releases (bucketed by number of days since the release). Later, specifically cp314 wheels were queried for the top 15,000 packages, revealing that only 56 projects of 15,000 had published a 3.14-compatible wheel more than 14 days after a release was available.

This topic was brought to the Packaging Summit at PyCon US 2026 by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth moved forward with a patch to reject new files on old releases which was merged July 8th, 2026.

This change will protect Python users and reduce the amount of "cleanup" work associated with project compromises for PyPI admins. This restriction also means that compromises don't put releases into an indeterminate and confusing state of both "compromised" and "not compromised", where only a subset of files could be poisoned with malware. Stay tuned for the future where Upload 2.0 API provides semantics for releases that are "closed" instead of "open".

Seth Larson and Mike Fiedler's work at the Python Software Foundation is supported by Alpha-Omega.

Planned Updates to the PyPI User Interface

Nicole Harris — Wed, 22 Jul 2026 06:09:00 +0000

Over the next few months, we will be rolling out changes to the PyPI user interface, improving how we surface security signals and updating the pages where users view package details.

Updates will be staged to TestPyPI and deployed to production in phases. This approach allows our team to thoroughly test the UI with production-like data, while providing the community with an opportunity to share feedback.

The first phase of changes is now staged on TestPyPI and ready for users to review!

Context: UI History, User Research and Attestations Style Guide

The PyPI user interface has remained largely unchanged since its 2018 launch. Over the intervening years, both PyPI and the Python ecosystem have grown significantly, while also attracting a higher volume of malicious activity. As a result, PyPI is taking a more active role in helping users assess and understand package security.

In 2024, PyPI introduced support for digital attestations. Uploaded by project maintainers when making a new release, attestations serve as a signed record of a release's build or publishing provenance, providing a verifiable way for users to see exactly where the release files came from.

While this was a significant milestone, the initial release did not include the necessary UI updates to make those attestations easily understandable or consumable for the average PyPI user.

This isn't a PyPI-specific problem; communicating attestations clearly to end users is a challenge across the open source ecosystem. To address this, the OpenSSF Securing Software Repositories Working Group partnered with Superbloom and Kabu Creative in 2025 to research and develop a standardized style guide for displaying attestations on software repositories. This work included extensive user interviews with package consumers (including PyPI users) to understand how they evaluate package security and trustworthiness.

As a next step, PyPI is adopting the highest-level recommendations from the style guide, becoming the first package repository to do so. Most notably, this involves adding a new "Security" tab and improving PyPI's user documentation.

We are also using this opportunity to deliver incremental improvements to the project detail pages, fine-tuning our 2018 design to improve information hierarchy and utility.

What's Changing?

Key changes to the user interface include:

Dedicated Security Tab: We are introducing a new Security tab to the project page to centralize provenance and attestation metadata, and to provide clear indicators when provenance is missing or has changed.
Navigation Moved to Horizontal Tabs: We are moving internal navigation out of the sidebar and into a horizontal tab structure. This allows us to reserve the sidebar exclusively for project- and release-related metadata.
Metadata Sidebar Moved to the Right: We are shifting the sidebar to the right to place critical content (the package description/readme) on the left, aligning with a natural left-to-right reading pattern and mirroring the structure of other major platforms like GitHub and npm.
Labeling Trust Levels: We are explicitly labeling project data intrinsic to PyPI (like release timestamps) and data provided by a maintainer and verified by PyPI (like upstream source repositories). This will help users weigh the trustworthiness of data according to its source.
Optimized Sidebar Hierarchy: We are reordering sidebar metadata by utility, prioritizing project links and "freshness" signals (like release dates) at the top, while shifting classification data to the bottom.
Clearer Status Labeling: We are introducing bolder colors and improved labels for quarantined, yanked, archived, and pre-release states to help users more easily distinguish between these conditions.

These updates are entirely visual and will not require action from project maintainers; existing and future digital attestations will map to the new UI automatically.

Our Rollout Plan

We are rolling out these changes in four phases. You can follow our progress, view the design prototypes, and participate in the discussion on our main tracking issue (#19950).

Phase 1: Project Details (prototypes and discussion at #19951, now live on TestPyPI) – Main page redesign, including updates to the sidebar order and positioning.
Phase 2: Files and Release History (prototypes and discussion at #20185) – Streamlining the file and release history tabs, adding attestation metadata where appropriate.
Phase 3: Security Tab (prototypes and discussion at #20069) – Building a dedicated space for surfacing provenance and attestation data, raising warnings where appropriate.
Phase 4: Documentation Refresh – Refreshing PyPI's documentation to support the new UI, including adding security guidance.

We Want Your Feedback

We invite you to test these changes on TestPyPI.

If you have feedback, please share it on this GitHub issue.

If you find a bug or defect, please open a ticket on our issue tracker. Please ensure you include browser and device details. This helps our team reproduce and fix the problem quickly.

Acknowledgments

We would like to thank the Open Source Security Foundation for providing the funding for this initiative. We are also deeply grateful to Dustin Ingram, Zach Steindler, and the members of the OpenSSF Securing Software Repos WG for proposing this project for funding, and championing the larger effort to introduce attestations.

We also want to extend a sincere thank you to the members of the Python community who participated in our most recent round of user interviews; your insights were instrumental in shaping the rationale and execution of these designs. Volunteers included:

Maciej Kopeć
Yngve Moe
Nyaosi Mogaka
Joachim Jablon
Samuel Mbote

Finally, thank you to the 777 people who participated in our recent user survey. Your feedback has been invaluable in shaping the design and ordering of the package metadata sidebar.

PyPI has completed its second audit

Mike Fiedler — Thu, 16 Apr 2026 14: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 2 High, 1 Medium, 7 Low, and 4 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 superseded 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.

The Python Package Index Blog

Incident Report: File Hosting Errors

Executive summary

Background: How PyPI's file hosting cache works 1

Timeline

August 15

August 17

August 18

August 19

August 20

August 21

August 24

August 28

Contributing factors

POP goes the canary 2

Bugs at home

5xx volume over time

Going forward

Thanks

Metadata requests no longer tracked in PyPI download counts

Background

Other objects

The correction

Impact on existing data

Downloads are not a popularity metric

Future work: range requests

How AWS Powers PyPI and the PSF

The shape of it

What changed this year

What we do about it

What the funding actually bought

How you can help

The HTML representation of the index API is now frozen

Background

Do I have to do anything?

Releases now reject new files after 14 days

Planned Updates to the PyPI User Interface

Context: UI History, User Research and Attestations Style Guide

What's Changing?

Our Rollout Plan

We Want Your Feedback

Acknowledgments

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?

Background: How PyPI's file hosting cache works ¹

POP goes the canary ²

`RECORD` and ZIP issues in top Python packages