Bad news for developers. Github is being besieged by millions of malicious repositories in an ongoing attack:
Similar to dependency confusion attacks, malicious actors get their target to download their malicious version instead of the real one. But dependency confusion attacks take advantage of how package managers work, while repo confusion attacks simply rely on humans to mistakenly pick the malicious version over the real one, sometimes employing social engineering techniques as well.
In this case, in order to maximize the chances of infection, the malicious actor is flooding GitHub with malicious repos, following these steps:
- Cloning existing repos (for example: TwitterFollowBot, WhatsappBOT, discord-boost-tool, Twitch-Follow-Bot, and hundreds more).
- Infecting them with malware loaders.
- Uploading them back to GitHub with identical names.
- Automatically forking each thousands of times.
- Covertly promoting them across the web via forums, discord, etc.
And:
Once unsuspecting developers use any of the malicious repos, the hidden payload unpacks seven layers of obfuscation, which also involves pulling malicious Python code and later a binary executable. The malicious code (largely a modified version of BlackCap-Grabber) would then collect login credentials from different apps, browser passwords and cookies, and other confidential data. It then sends it back to the malicious actors’ C&C (command-and-control) server and performs a long series of additional malicious activities.
Ken Westin, Field CISO, Panther Labs had this to say:
We at Panther have seen an increase in software supply chain attacks, where developers, code and cloud infrastructure are increasingly becoming a target. We have seen this with APT groups such as Lazarus out of North Korea, as well as financially motivated cybercrime groups. The goal of the attacks are often to infect code upstream to then target customers downstream, or in this case to steal credentials and authentication cookies with the hopes of gaining privileged access applications, code and secrets. Many organizations do not consider monitoring data sources such as Github in their SIEM and often do not have visibility into potential security compromises of code or developers’ workstations and infrastructure.
The report from Apiiro has a lot of detail in terms of the attack and indicators of compromise, along with steps in terms of protection. Developers should read this and act accordingly .
GitHub and PyPI both just closed the gap attackers rely on for supply chain attack
Posted in Commentary with tags GitHub, GPyPI on July 27, 2026 by itnerdGitHub and PyPI both introduced new policies this week aimed at slowing down how fast malicious code can spread through the software supply chain. GitHub’s Dependabot will now wait at least three days before opening a pull request for a new package release, and PyPI is blocking new file uploads to any release older than 14 days, both closing the same window attackers have relied on: the gap between a malicious release going out and anyone noticing.
SecurityWeek has more:
To prevent the fast delivery of malicious code through the immediate fetching of brand-new releases, GitHub has introduced a Dependabot cooldown, where the automation tool waits for at least three days after a release has been published before opening a pull request.
“Waiting a few days before adopting a new release gives maintainers, security researchers, and automated scanners time to spot a malicious version and get it pulled before it ever reaches your pull requests,” GitHub explains.
The three-day cooldown only applies to non-security version bumps, and the behavior can be modified through the configuration option in the dependabot.yml.
“Three days as the default balances two goals: it pushes you past the window where most of these attacks live, and it doesn’t hold your dependencies back longer than necessary,” GitHub notes.
PyPI, on the other hand, is preventing the poisoning of releases older than 14 days by blocking the upload of new files to them.
“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,” PyPI says.
The behavior will be enforced once ‘Upload 2.0 API’ and ‘Staged Previews’ have been standardized by PEP 694 and will affect only a small fraction of projects that still publish new files to older releases.
Maggie McDaniel, Global Head of Intelligence, iCOUNTER had this to say:
“This is exactly the kind of outcome effective public-private intelligence sharing is supposed to produce. Security researchers and the community kept surfacing the same pattern, a maintainer account gets compromised, a malicious release goes out, and automated tooling propagates it into thousands of projects before anyone has a chance to catch it, and instead of that staying a research finding, it became a platform-level policy change. A three-day cooldown on Dependabot and a 14-day lock on new uploads to existing PyPI releases won’t stop every attack, but they close the exact window that made this class of attack so effective: the gap between publication and detection. What I’d want to know now is whether other package ecosystems are watching this and building the same kind of delay into their own automation, because the ecosystems that don’t will be the ones attackers target next.”
This is a positive move. But it needs to be backed by knowing what goes into your applications without fail. Otherwise we will have a different version of the same problem.
Leave a comment »