Malware News Hackers have compromised dozens of popular open source packages in an ongoing supply-chain attack

[Brownie2019]

Content source

https://techcrunch.com/2026/05/19/hackers-have-compromised-dozens-of-popular-open-source-packages-in-an-ongoing-supply-chain-attack/

In an ongoing cyberattack, hackers have compromised several popular open source projects that software developers all over the world rely on.

On Tuesday, cybersecurity firms StepSecurity and SafeDep warned of the latest wave of supply-chain attacks, which aim to compromise developers of popular open source projects and use that access to plant malicious updates that are pushed to users downstream.

According to SafeDep, hackers took over the account of one developer and released over 630 malicious versions across 317 packages in about 20 minutes. The goal of the attack is to steal credentials for various services, including password managers, as a way to steal data and continue spreading the malware.

Among the packages that the hackers compromised is Antv, a library made by Alibaba. In some cases, the hackers published malicious updates on GitHub, according to JFrog Security.

This latest wave of attacks is part of a wider campaign targeting open source projects and the developers who use the code for their own projects. Researchers have dubbed the hacks “Mini Shai-Hulud,” after the attack followed a previous, more expansive hacking campaign.

Last week, in another wave of attacks as part of the Mini Shai-Hulud attacks, hackers compromised the computers of two OpenAI employees after hacking the open source library TanStack. OpenAI was just one of several victims.

 

[Bot]

This is a serious supply-chain incident, but the practical risk depends on whether a developer or organization actually pulled one of the affected package versions into their build environment.

What this means

Supply-chain attacks against open source packages are especially dangerous because they abuse trust in widely used dependencies.

If the reporting is accurate, the main concern is not just a broken package, but malicious code being delivered through normal update channels to:

• Developer workstations
• CI/CD pipelines
• Build servers
• Production applications

That can lead to:

• Credential theft
• Token or API key leakage
• Compromise of internal repositories
• Further lateral movement into other projects or services

Important caution

I cannot independently verify every claim in the quoted text, including the exact number of affected packages or all named victims, without checking the original vendor and researcher reports.

So the safest approach is to treat this as a credible warning and rely on:

• Official advisories from the affected projects
• GitHub security notices
• Registry/package manager advisories
• Research posts from firms such as StepSecurity, SafeDep, or JFrog

Why attacks like this matter so much

Open source itself is not the problem. The issue is that modern software often depends on large dependency trees, and one compromised maintainer account or package publish token can affect many downstream users very quickly.

In practice, many organizations are exposed because they:

• Auto-update dependencies
• Allow install scripts during package installation
• Store secrets on developer machines or in CI environments
• Do not pin versions tightly enough
• Lack software bill of materials visibility

Reasonable defensive steps

If someone is developing with JavaScript or other package ecosystems, the standard response should be:

• Identify whether any affected package names and versions were installed
• Check lockfiles, CI logs, and artifact histories
• Review recent dependency updates, especially very recent patch/minor releases
• Rotate exposed secrets if suspicious packages were executed
• Inspect developer endpoints and CI runners for credential theft activity
• Pin to known-good versions
• Temporarily disable automatic dependency bumps for affected packages
• Watch for official revocation or clean-version guidance from maintainers

If compromise is suspected

A careful incident-response approach is better than guessing:

• Assume any credentials present in the affected environment may be exposed
• Rotate tokens, API keys, and session credentials
• Review npm/GitHub/cloud access logs
• Rebuild from a known-clean state
• Scan endpoints with reputable security tools
• Preserve logs before cleanup if this is an enterprise environment

Bottom line

The quoted report describes the kind of attack that defenders should take very seriously, especially developers and organizations that consume open source packages automatically. The safest conclusion is not “all users are infected,” but “anyone who installed the affected versions should verify exposure immediately and follow official advisories.”