The Whispering JAR: Java Security Lessons Hidden in a Fantasy Tale

It’s December 29th, 1865, and a woman is walking down Salzstraße in the city of Freiburg in the Duchy of Baden. She has a green cloak on, and her face is not very visible in the thick fog. She enters a small alley and knocks. A man walks to the door and asks, “What’s in the jar?” The woman replies, “Java beans.”

The door opens, and a man with a red fedora hat and dark brown eyes welcomes her inside. “Come in, Gord,” he says. “I have been expecting you.”
“Good to see you, Rothütle,” she replies.

They enter the room, and the woman sees a pile of newspapers on the table.

“Coffee?” the man asks. “Yes, please,” Gord replies.

“I’m about to run out of beans, so I bought a new batch from the market,” the man says, grinding the beans and brewing a fresh cup.

Gord stares at the jar of coffee on the table for a moment, as if something is off.

Threats from the Past

Rothütle’s obsession with old newspapers was not nostalgia—it was vigilance. Some threats never truly die.

In the story, the warrior woman named Gord is meeting with her new acquaintance Rothütle, who is a tinkerer and technologist. The man is going through old archives and newspapers, because threats from the past can still be relevant today.

Many entered the realm of supply chain security because of the Log4Shell vulnerability, which was a critical security flaw in the widely used Java logging library Log4j. The vulnerability was discovered in late 2021 and allowed attackers to execute arbitrary code on affected systems by sending specially crafted log messages. This incident shook the software industry and highlighted the importance of securing the software supply chain, as Log4j was a dependency in countless applications and services.

Let’s explain a few technical terms here:

• CVE or Common Vulnerabilities and Exposures, is a system that provides a reference method for publicly known information security vulnerabilities and exposures. Each vulnerability is assigned a unique identifier, known as a CVE ID, which allows security professionals to easily reference and discuss specific vulnerabilities.
• Log4Shell is a critical security vulnerability (CVE-2021-44228) in the Log4j library. You can look up the details of this vulnerability in the CVE database at cve.mitre.org.
• CVSS or Common Vulnerability Scoring System, is a standardized framework for rating the severity of security vulnerabilities. It provides a numerical score (ranging from 0 to 10) that reflects the potential impact of a vulnerability, with higher scores indicating more severe vulnerabilities. Log4Shell had a CVSS score of 10, which is the highest possible score, indicating that it was an extremely critical vulnerability.

Research from 2025 shows that many years after the Log4Shell incident, approximately 13% of all Log4j downloads are of vulnerable versions. The number varies across countries, and for example, it’s 11% in Germany and 29% in India. This means that even years after the vulnerability was disclosed, a significant portion of applications are still using vulnerable versions of Log4j, exposing them to potential attacks. [¹] [²]

That’s why we need to know about the threats from the past.

---

Tip of the day. Fix your vulnerable dependencies, as soon as possible. CVEs are known to security professionals and attackers alike.

---

You can find vulnerable dependencies in your applications by using tools like Snyk, Dependabot, or Renovate. If you have a Docker image, you can use tools like Trivy or Docker Scout to scan for vulnerabilities in the image layers. Once you identify vulnerable dependencies, you should update them to the latest secure versions and rebuild your images to ensure that the fixes are applied.

To check your Java applications for Log4Shell vulnerabilities, you can use the following command with Trivy:

$ trivy fs --severity CRITICAL --ignore-unfixed --pkg-types os,library <path-to-your-java-app>

To use Docker Scout, you can run:

$ docker scout cves --only-severity CRITICAL --only-fixed <image>

The Fishy JAR

As Rothütle is making coffee, Gord notices that the jar of coffee beans is whispering.
She sits down and listens carefully. Then she puts her cloak on over the jar, and sees a pair of eyes staring at her from the darkness.

“Angra’s malice is poured into the jar,” Gord says. “Where did you get it?”
“I bought it right in front of the door,” Rothütle replies. “The merchant just left the customs and was selling it on the street for a better price.”

---

Tip of the day. Beware of untrusted sources and social engineering.

---

In the story, Gord and Rothütle are on high alert because they have been targeted by attackers before. The software security scene of 2026 is no different. Let’s take a look at the supply chain attack in the last 4 months of 2025.

The NPM Supply Chain Attack

The world’s largest NPM supply chain attack happened in September 2025. Attackers started a phishing campaign by registering the domain npmjs.help and sending out emails to the maintainers of the top 1% of NPM packages. The attackers also used a real-time proxy to bypass the two-factor authentication (2FA) and gain access to the maintainers’ accounts. Some maintainers fell for the scam, and within hours the attackers took control of popular packages like chalk and debug.

The attackers published malicious updates to these packages, which contained a crypto-drainer that swapped wallet addresses during cryptocurrency transactions in web browsers. The attack was active for about two hours before it was mitigated, but it had the potential to affect millions of users who installed or updated these packages during that time. [³] [⁴]

Shai Hulud Attack, All the Way from Arrakis

On September 15th, 2025, a week after the initial NPM attack, a second, more sophisticated threat emerged: the Shai Hulud worm. Named after the colossal sandworms of Frank Herbert’s Dune, this malware was not designed for simple theft; it was designed for total ecosystem dominance. Ironically, the name “Shai Hulud” means “the immortal thing” in Arabic, and this worm lived up to its name by being nearly impossible to eradicate.

The worm represented a terrifying evolution in supply chain attacks: it was self-replicating.

Infection Cycle:

1. Entry: A developer installs a compromised package (e.g., @ctrl/tinycolor or ngx-bootstrap).
2. Harvesting: The malicious script (setup_bun.js, often utilizing the Bun runtime for speed and obfuscation) scans the developer’s local environment. It targets:
   • ~/.npmrc (NPM authentication tokens).
   • ~/.ssh/id_rsa (SSH keys).
   • ~/.aws/credentials (Cloud access keys).
   • GitHub Personal Access Tokens (PATs). [⁵]
3. Propagation: Using the stolen NPM tokens, the worm authenticates to the NPM registry as the victim. It then:
   • Enumerates all packages maintained by the victim.
   • Injects itself into the preinstall or postinstall scripts of those packages.
   • Publishes a new patch version (e.g., v1.0.1 -> v1.0.2) to the registry.
4. Exfiltration: Stolen credentials were not merely sent to a Command and Control (C2) server. In a display of brazen arrogance, the worm created public GitHub repositories under the victim’s account, named Shai-Hulud or Shai-Hulud: The Second Coming, and uploaded the credentials there as a file named secrets.txt.

React2Shell

In December 2025, when the industry was still reeling from the Shai Hulud worm, the React2Shell vulnerability (CVE-2025-55182) was disclosed. It was a Critical (CVSS 10.0) vulnerability affecting React Server Components, specifically in React 19.x and Next.js 15.x/16.x. The vulnerability allowed attackers to execute arbitrary shell commands on the server by sending specially crafted requests to vulnerable endpoints. This was particularly dangerous because React Server Components are often used in server-side rendering (SSR) setups, which have direct access to the server’s filesystem and environment.

When the vulnerability was disclosed, a race began between attackers and defenders. Attackers quickly developed proof-of-concept exploits, while defenders scrambled to patch their applications and update their dependencies. In a talk in December 2025, Docker Captain and Co-founder of European container hosting solution Sliplane, Jonas Scholz, revealed that within 72 hours, almost all of the unpatched React applications were being targeted by cryptocurrency miners, which were using the vulnerable servers to mine cryptocurrencies without the knowledge of the server owners. [⁶]

Attack Name	Date	Vector	Primary Target	Mechanism	Impact
NPM Supply Chain	Sept 8, 2025	Social Engineering (Phishing)	Frontend Devs	Malicious npm package update (e.g., chalk)	Crypto-wallet draining (browser-based)
Shai Hulud Worm	Sept 15, 2025	Self-Replicating Worm	CI/CD & Devs	Harvests creds, injects preinstall scripts	Destructive (Wipes $HOME), Credential Exfiltration to GitHub
React2Shell	Dec 3, 2025	Vulnerability (RCE)	Servers (Next.js/React)	Unsafe Deserialization (Flight Protocol)	Full Server Compromise (CVSS 10.0)

The Worm Spreading

Gord pulled out a knife and cut the jar open. A sandworm-like creature emerged from the jar.

“It’s a Shai Hulud,” Rothütle says. “They dwell in the deserts of Arrakis, not sure how it ended up here.”
Gord looks at the creature and says, “Borders are thinner than we think.”

---

Tip of the day. Look into your JARs.

---

Shai Hulud is a Node.js worm. Why would someone in the Java world care about it?

The Bridge Vector. Modern Java development rarely happens in isolation. Developers use tools like WebJars or mvnpm to package JavaScript libraries as JAR files for use in Maven/Gradle builds.

In November 2025, it was discovered that the Shai Hulud worm had crossed into Maven Central. The tool mvnpm (Maven NPM) automatically monitors the NPM registry. When a new version of a package is published on NPM, mvnpm automatically wraps it in a JAR and publishes it to Maven Central. When Shai Hulud compromised posthog-node on NPM, mvnpm inadvertently acted as a bridge, wrapping the malicious setup_bun.js payload into org.mvnpm:posthog-node:4.18.1. [⁷]

The Box of Sand

Rothütle says, “We can’t kill this creature with a mere knife. Let’s contain it for now to prevent it from spreading.”

Gord says, “Let’s put it in this box of sand, where it feels at home. We can keep it there until we find a way to neutralize it.”

---

One way to contain supply chain threats like Shai Hulud is to sandbox the development environment. Shai Hulud bridged the gap between development and production environments. So far, everyone has taken good care of securing their production environments, but the development environments were left exposed.

• Containerized development environments. By running your development environment inside a container, you can reduce the blast radius of a potential compromise. If a malicious package tries to access your credentials or filesystem, it will be contained within the container, preventing it from affecting your host system. Still, if you use volumes to share files between the container and the host, you need to be cautious, as this can potentially allow the malicious code to access sensitive files on your host system.
• Remove development environments. Many solutions, like GitHub Codespaces or Gitpod, provide cloud-based development environments. By using these, you can avoid running potentially vulnerable code on your local machine. However, you need to ensure that the cloud environment is properly secured and that sensitive credentials are not exposed in the cloud.
• Keep your credentials out of reach. Use secret management tools to keep your credentials out of your codebase and filesystem. Make publishing packages more difficult by setting up manual approval processes for package updates, and avoid using tools that automatically publish packages to the registry.
• Hardware keys. Enforce using hardware security keys (e.g., YubiKey) for authenticating to package registries. This adds an extra layer of security, making it harder for attackers to gain access even if they compromise your credentials.

Conclusion

Rothütle spends the next few days researching the creature, trying to find a way to neutralize it. He discovers that the creature is vulnerable to water, which is ironic given that it thrives in the desert. They decide to fill the box with water to contain the creature.

Now, although the worm is neutralized, the source must be identified and eradicated. The attack vector must be closed to prevent future infections. The incident serves as a stark reminder of the evolving nature of supply chain threats and the importance of vigilance in securing the software development lifecycle.

To read more about Gord and Rothütle’s adventures in the Black Forest, check out the book “Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security”, available on DockerSecurity.io.

References

1. Sonatype. Unnecessary Risk: The Persistence of Open Source Vulnerabilities. Sonatype, 2025. https://www.sonatype.com/whitepapers/the-persistence-of-open-source-vulnerabilities ↩︎
2. Phil Muncaster. Log4Shell Downloaded 40 Million Times in 2025. Infosecurity Magazine, December 2025. https://www.infosecurity-magazine.com/news/log4shell-downloaded-40-million/ ↩︎
3. Tom Abai. _NPM Supply Chain Attack: Sophisticated Multi-Chain Cryptocurrency Drainer Infiltrates Popular Packages. Mend.io, September 2025. https://www.mend.io/blog/npm-supply-chain-attack-infiltrates-popular-packages/ ↩︎
4. Mohammad-Ali A’râbi. The Largest NPM Supply Chain Attack Ever and How to Defend Against It. Dev.to, September 2025. https://dev.to/aerabi/the-largest-npm-supply-chain-attack-ever-and-how-to-defend-against-it-9a6 ↩︎
5. CISA. Widespread Supply Chain Compromise Impacting npm Ecosystem. America’s Cybersecurity and Infrastructure Security Agency (CISA), September 2025. https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem ↩︎
6. Jonas Scholz. React2Shell Critical Vulnerability (CVE-2025-55182). Docker Meetup Freiburg, December 2025. https://youtu.be/2v_moJXa1uw?si=rFXIaLMtgi1Un245 ↩︎
7. OPSWAT. Shai-Hulud 2.0: How to Secure Your Software Supply Chain Against the Second Wave. OPSWAT, December 2025. https://www.opswat.com/blog/shai-hulud-2-0-how-to-secure-your-software-supply-chain-against-the-second-wave ↩︎