GitHub Adds a Default Dependabot Cooldown as PyPI Locks Releases After 14 Days

Two package ecosystems added time-based controls within nine days of each other. GitHub made a three-day wait the default for Dependabot version updates, announced in a changelog entry dated July 14, 2026. PyPI announced on July 22 that it no longer accepts new files uploaded to a release once that release is more than 14 days old.

The two measures solve different problems with the same instrument. GitHub is slowing down how fast a fresh release reaches your repository. PyPI is stopping anyone from quietly editing the contents of a release that people already trust.

Neither change blocks a malicious upload at the source. Both shorten the period in which that upload can do damage without anyone looking at it.

The Dependabot cooldown is a minimum age requirement on a release before Dependabot will act on it. Under the new default, Dependabot waits until a version has been available on its registry for at least three days, then opens the version update pull request as usual. Nothing needs to be configured for this to apply.

One distinction carries most of the weight here, and a lot of the coverage has blurred it. The default applies only to version updates, the routine pull requests that keep dependencies current. Security updates, which respond to a published advisory for a package you already use, still open immediately. A delay there would hold back a fix for a flaw that is already public.

Teams that want a different window can set one through the cooldown option in .github/dependabot.yml, including opting out. GitHub says the default covers all supported ecosystems on github.com and will reach GitHub Enterprise Server in version 3.23.

Carlin Cherry, a product manager working on Dependabot at GitHub, laid out the reasoning on July 23, 2026. The anchor case is the September 2025 npm compromise, where an attacker phished one maintainer's credentials and published trojanised versions of chalk, debug and around a dozen other packages that together see more than 2 billion downloads a week. The code rewrote cryptocurrency wallet addresses in any browser app that loaded it, and the poisoned versions were live for roughly two hours.

Two hours is a quick community response. It is also more than enough for update tooling built to grab the newest release on sight.

The pattern repeats. GitHub points to compromised builds of Solana web3.js, Axios and ua-parser-js, each caught within hours, and to a review of 21 reported incidents between 2018 and 2026 showing the same short lifespan. Its own Advisory Database published more than 6,500 npm malware advisories in the year ending May 2026, up from roughly 6,200 the year before, which works out to about 18 new malicious npm packages catalogued per day.

PyPI releases used to be open ended. A maintainer could add a wheel or a source distribution to a published version at any point, years later if they wanted, without changing the version number. That flexibility had a sharp edge: anyone holding a stolen publishing token could drop a malicious file into a release that developers had trusted for months.

Seth Larson, Security Developer-in-Residence at the Python Software Foundation, announced on July 22, 2026 that PyPI now refuses those uploads once a release passes 14 days. He is direct about the status of the threat. As far as PyPI is aware the technique has not been abused, and the only thing that stopped it was that attackers had not realised it was possible.

Larson also flags what the change reduces on the operations side. Compromises no longer leave a release in a confusing half state where only some of its files are poisoned, which cuts the cleanup work for PyPI administrators.

The idea first surfaced during the PEP 740 digital attestations discussion in January 2024, then stalled. The blocker was legitimate: some projects add wheels for newly released Python versions to an existing release rather than cutting a new one, and closing the window would break that habit.

The discussion restarted in March 2026 after the LiteLLM and Telnyx packages were compromised through a mutable reference in their use of the Trivy GitHub Action. To size the disruption, PyPI queried its database for projects publishing files to old releases, then looked specifically at cp314 wheels across the top 15,000 packages. Only 56 of those 15,000 had published a Python 3.14 compatible wheel more than 14 days after the release first appeared.

Mike Fiedler, PyPI Safety and Security Engineer, brought the topic to the Packaging Summit at PyCon US 2026. Attendees reached rough consensus that asking maintainers to bump the version was acceptable. Larson's patch merged on July 8, 2026.

Most teams need to do nothing. The Dependabot default is already live and requires no configuration, and the practical effect is that routine version bumps show up three days later than they used to.

Two groups should check their setup. Teams that already had a cooldown configured in dependabot.yml keep their own value, so it is worth confirming that value is still what you want now that the platform default has moved. Teams running tightly controlled internal registries may reasonably want a shorter window than three days for those sources.

Python maintainers have a real workflow change. If your release process adds wheels for a new interpreter version to an existing release, that will now fail after two weeks and you need to publish a new version instead. PyPI is explicit that nothing should be built on top of this behaviour yet, because there are no defined semantics for a release that stops accepting files and no API to check that state. Both arrive with the Upload 2.0 API and staged previews under PEP 694.

GitHub is unusually clear about the limits of its own control. A cooldown targets one pattern: a malicious version that ships, spreads and gets caught quickly. It does little against a backdoor planted in a release and left dormant, against maintainer sabotage, or against a compromised build system, because in those cases the extra days buy no additional scrutiny.

The recommended layers around it are familiar and worth restating: pin dependencies with lockfiles, disable install scripts in CI where you can, scope the tokens in build pipelines tightly, and review updates before they merge.

Two things are worth watching. Whether other registries follow with defaults rather than opt-in settings, since npm added staged publishing earlier in 2026 and the direction of travel is consistent. And whether PEP 694 lands the formal semantics for closed releases, which is what would let tooling reason about release state instead of guessing.