GitHub and the Python Package Index have both concluded that the fastest way to stop the next poisoned package is not to catch it faster. It is to make it wait.
The Two-Hour Window
In September 2025, an attacker who had phished npm maintainer credentials pushed malicious versions of chalk, debug, and roughly a dozen other packages that together see about 2 billion downloads a week, according to GitHub’s account of the incident. The poisoned code rewrote cryptocurrency wallet addresses in transactions passing through infected applications. It was live for about two hours before the community caught it and pulled it down, a window short enough that most defenses never got a chance to react, but long enough for automated build pipelines to have already pulled it in.
That gap, not any single breach, is what GitHub says pushed it toward a structural fix rather than another detection tool.
What Changed
Dependabot’s Three-Day Brake
GitHub has made a three-day cooldown the default setting for Dependabot version updates, the company said in a July 23 post on the GitHub blog. When a new version of a dependency is published, Dependabot now waits at least three days before opening a pull request to adopt it, giving the community time to flag a compromised release before it spreads into downstream projects. The cooldown applies only to routine version bumps. Security updates, the patches that fix a publicly disclosed vulnerability, still go out immediately, since delaying those would trade one risk for a worse one. Maintainers can adjust the cooldown window through the existing cooldown option in a project’s dependabot.yml file if three days is not the right fit.
GitHub’s justification leans on its own advisory data: the GitHub Advisory Database logged more than 6,500 npm malware advisories in the year ending May 2026, close to 18 newly cataloged malicious packages a day. A review of 21 major supply-chain incidents between 2018 and 2026 found that malicious versions are typically caught within hours of publication, not minutes, which means any automation that adopts a new version immediately on release is adopting it before the ecosystem has had a chance to notice something is wrong.
PyPI Closes the Post-Release Upload Window
The Python Package Index made a parallel move. As of a July 22 post on the PyPI blog, releases now reject any new file uploaded more than 14 days after the release was first published. The rule targets a specific failure mode: a project that has been stable for months or years, with valid, trusted releases already in wide use, whose maintainer’s publishing token or CI workflow is compromised later. Under the old rules, an attacker with that access could attach a malicious file to an old, trusted release and let its existing reputation carry the payload downstream. PyPI has also built a non-destructive quarantine status it can apply to a suspect project, freezing it from ordinary installation while it is investigated, rather than only ever choosing between leaving it live or deleting it outright.
Why Time Beats Detection
Neither change tries to identify malicious code before it ships. Both bet that the community, researchers, and automated scanners will catch a bad release faster than an attacker can exploit a brand-new one, if given a few days of runway. That is a different security model than the one most of the last decade of supply-chain tooling has chased: better static analysis, more aggressive package scanning, faster malware signatures. Those tools still matter, but the chalk and debug incident showed that even a two-hour exposure window can be enough when the target is 2 billion weekly downloads. A delay does not need to be long to be useful. It only needs to be longer than the time it typically takes the ecosystem to notice.
It is also a trade concentrated on the automation layer, not the human one. Most version bumps are never reviewed by a person before they merge, they are consumed by CI pipelines and dependency bots on a schedule. That is precisely the surface a two-hour poisoning window is built to exploit, and precisely the surface where a mandatory pause changes the economics without adding friction for a developer who is manually vetting an update anyway.
What This Means for the Security Leader
For a CISO or platform security lead, this is a policy decision now baked into the tools most engineering teams already run, rather than a new control to procure and roll out. That has upside and a blind spot. The upside: teams using Dependabot or PyPI-hosted dependencies inherit a meaningful default improvement without doing anything, which is rare in supply-chain security. The blind spot: a three-day cooldown and a 14-day upload window are defaults, not guarantees, and organizations that have configured shorter cooldowns, disabled Dependabot cooldowns to chase faster patching, or that pull dependencies through mirrors and internal registries that do not inherit PyPI’s upload rule, get none of the protection.
It is also worth registering what this does not fix. A compromised package published for the first time, with no track record and no reputation, is not slowed down by a 14-day rule that only governs uploads to existing releases. And a three-day Dependabot cooldown does nothing for teams that pin dependencies manually, use lockfiles updated by a script outside Dependabot, or run a private registry that mirrors upstream without the same delay logic. This is a floor raised under the automated update path specifically, following a wave of npm and Go package hijacks CyberTech has tracked this year, including campaigns that used VS Code autorun tasks and blockchain dead drops to move infostealers through hijacked packages, not a ceiling on the problem.
What to Do Now
Security teams should confirm, rather than assume, how their own pipelines are configured. Check whether Dependabot cooldown settings have been shortened or disabled anywhere in the organization to chase faster patch adoption, and if so, whether that tradeoff was made deliberately. Audit whether internal package mirrors and registries inherit PyPI’s 14-day upload restriction or bypass it entirely. Treat the new defaults as a baseline to verify, not a control to check off, and keep pinning, lockfile review, and package provenance checks in place for the first-publish risk that a cooldown window cannot touch.
Source: GitHub
