The same malware family that compromised npm earlier this year has now turned up inside Java packages on Maven Central. This is a serious supply-chain warning for any organisation that relies on Java builds.
The short version
Attackers pushed trojanised packages containing Shai-Hulud v2, an updated infostealer. It targets developer machines, CI runners, and build servers. It steals tokens, SSH keys, and credentials. It also opens the door for wider compromise of your development pipeline.
If your teams still assume “Maven packages are safe by default”, that assumption is wrong.
What actually happened
Security researchers found that:
- Newly uploaded Maven packages were cloned from legitimate projects but with malicious code injected.
- The payload was triggered on build or install, similar to the earlier npm campaign.
- The malware beacons out, downloads a secondary payload, and steals authentication material from local dev environments.
- Package names and structure were crafted to look genuine and pass casual review.
- The attacker reused infrastructure and TTPs from the npm Shai-Hulud incident, confirming the link.
This is an abuse of the ecosystem, not a flaw in Maven Central itself. The weak link is the assumption that open repositories enforce trust. They do not.
Why this matters
A hit on your developer workstation or CI pipeline is often enough to breach the company. That is why supply-chain attacks are trending up and why attackers keep shifting to package ecosystems.
Shai-Hulud v2 is specifically designed to:
- Capture GitHub, GitLab, Bitbucket, and cloud tokens
- Steal SSH keys and known_hosts
- Steal npm, PyPI, and Maven credentials
- Collect system info that helps build tailored follow-on attacks
- Inject itself quietly into build processes
If a developer installs one compromised dependency, you get a pivot point into the rest of your estate.
What this reveals about the current ecosystem
Three uncomfortable truths:
- Most organisations treat dependency trust as a “given”. They rarely pin versions or verify provenance.
- Open ecosystems are easy to poison. Typosquatting, star-jacking, and clone-and-inject attacks are cheap.
- Developer machines are often the least-protected part of the corporate estate. They hold credentials, tokens, and access keys that matter.
This is exactly why attackers are repeating the same playbook across npm, PyPI, RubyGems, and now Maven.
What to do now
If you use Java, Maven, or mixed-language pipelines, take action quickly.
- Audit your dependency tree: Run a full inventory across all Java builds. Identify any packages published recently by unknown maintainers. Flag unusual version bumps.
- Check developer endpoints for indicators: Look for unexpected outbound traffic from dev laptops and CI runners. Rotate tokens if you see anything suspicious.
- Enforce signed and verified packages: Adopt Sigstore, Maven’s new signature validation, or an internal repository manager that enforces provenance.
- Pull dependency management inside your boundary: Use Artifactory, Nexus, or GitHub Packages. Mirror known-good packages internally and block direct external pulls.
- Harden CI/CD: Run builds in isolated runners with short-lived credentials. Rotate secrets often. Block outbound internet where possible.
- Train developers to spot typosquatting: The attack surface lives where the developers work. If they can’t recognise suspicious dependencies, tooling must do it for them.
What this means for 2025
The attack is a sign that package-level intrusions are now normal, not rare. Attackers reuse the same infrastructure and malware families across ecosystems because it keeps working.
Expect more campaigns that:
- Clone legitimate repos
- Inject small, hidden payloads
- Target development environments rather than production servers
- Spread across multiple ecosystems
The defensive gap is not technical. It is cultural. Most teams still trust packages too much and verify too little.
Final view
Shai-Hulud v2 in Maven is not an isolated incident. It is the same actor, the same strategy, and the same objective. If your supply chain still depends on blind trust in public repositories, you are exposed.
A few hours of dependency auditing and CI hardening now is cheaper than incident response later.