Trusted npm Package Compromised – Developer & Cloud Credentials at Risk

Today’s briefing has a strong theme. Some of the most important security failures aren’t happening inside the application anymore; they’re happening in the systems we trust around them. This morning, we have a software supply chain compromise that makes that very clear.

Hi, I’m Dustin Gray. I’ve been building production software and keeping our clients’ assets safe online for 25 years. These are the five website and application security stories I think actually matter today.

Let’s start with the software supply chain, because yesterday a legitimate npm package appears to have turned malicious. StepSecurity detected suspicious code inside version 5.8.3, and it’s part of the SubQuery ecosystem. But here’s where this gets serious.

The malicious code doesn’t just run when the package is installed. StepSecurity says it can also start when the package is imported. Once running, it looks for credentials on developer machines and CI environments, including GitHub Actions and accessible cloud services, and it also provides remote shell capability.

So think about the trust boundary here. The developer isn’t downloading malware; they’re installing a trusted software dependency. And that dependency inherits whatever access their development environment has.

That’s the blast radius: source code, development credentials, cloud credentials, CI/CD secrets and potentially production. If your organisation uses SubQuery, check whether credentials were accessible, because those credentials may now need rotating. This is a confirmed malicious package, not merely a theoretical vulnerability.

Next up, Citrix NetScaler, and if that sounds familiar, it should. We’ve already covered the recent NetScaler vulnerabilities, but this is a genuinely new development. Another vulnerability, 88779, has now been exploited against NetScaler systems.

Here’s the unusual part. Some administrators initially noticed fully patched appliances rebooting unexpectedly. Citrix says the new vulnerability is a memory overflow issue affecting NetScaler ADC and NetScaler Gateway when configured as a SAML service provider or identity provider.

Citrix has observed targeted attacks, but there’s an important condition. This does not affect every NetScaler deployment, because the SAML configuration matters. Despite early speculation around remote code execution, watchTowr reproduced the vulnerability and says this particular flaw appears capable of crashing systems, not executing code.

CISA has nevertheless added it to the Known Exploited Vulnerabilities catalogue. So today’s action isn’t simply “we patched Citrix last week”. Check whether your NetScaler uses the affected SAML configuration, check the version again, apply the new remediation, and investigate unexplained crashes rather than assuming they were reliability problems.

That’s the security lesson here. A control being patched yesterday doesn’t mean the asset is safe today.

Next up, a help desk application, and this one demonstrates why blast radius matters. CISA has added two Zammad vulnerabilities to its Known Exploited Vulnerabilities catalogue following real-world exploitation. Zammad is a web-based customer support and ticketing platform, and the two vulnerabilities can be chained.

The first can allow unauthenticated remote code execution and session theft. The second can escalate access on the underlying system to root. Those flaws were already known from the compromise of the Dutch Institute for Vulnerability Disclosure; the material development now is CISA’s exploited vulnerability action.

Look at the security boundary. A vulnerability in a customer support application doesn’t necessarily stop at the help desk. If the attacker reaches root on the underlying server, the question becomes: what can that server reach next? Credentials, internal services, customer communications and other systems.

Zammad users should identify their deployed version immediately and follow the vendor’s upgrade guidance. If you are running an affected internet-facing instance, don’t treat upgrading as the end of the incident. Review sessions, logs, accounts and activity for evidence of earlier compromise, because patching closes the door, but it doesn’t tell you whether somebody already walked through it.

Now, let’s move from vulnerabilities to a security control failure. Cloudflare reported an incident yesterday affecting API Shield, specifically JWT validation for customers using symmetric key material. That’s worth paying attention to, because JWT validation can sit directly on an application’s trust boundary.

Your application receives a token. The security layer decides whether that token should be trusted, and the application then makes decisions based on that answer. Cloudflare identified the issue and began implementing a fix.

This is not evidence that attackers exploited the problem, and I’m not going to imply that authentication was broadly bypassed. But if you’re using API Shield JWT validation with symmetric keys, check Cloudflare’s incident history against your configuration and review relevant application and authentication logs for the affected period.

The larger lesson is simple. When we outsource a security control, we outsource its operation. We don’t outsource our responsibility for the risk.

And finally this morning, WordPress, but this isn’t really a WordPress plugin story. Researchers have demonstrated a path where a malicious HEIC image upload can ultimately reach native image processing code used by a WordPress server. The important component here is libheif, which handles formats including HEIC, HEIF and AVIF.

When WordPress hands an uploaded image to ImageMagick for processing, a specially crafted image can reach the vulnerable decoder. Researchers demonstrated a chain that can end in code execution inside the PHP-FPM process.

Here’s the teachable part. Your application might correctly decide this user is allowed to upload an image. That is an authorisation decision, but it doesn’t mean the image itself is safe.

The input then passes through WordPress, ImageMagick, native libraries and eventually the operating system. That’s defence in depth. If your WordPress environment accepts image uploads, especially from untrusted users, check the image processing stack underneath WordPress, not just the WordPress version and plugins.

Review your versions of ImageMagick and the underlying HEIC and HEIF libraries, and restrict upload capability to the users who genuinely require it. Sometimes the vulnerable component is several layers below the software you think you’re securing.

And that’s today’s briefing. There’s a common thread running through all five stories today. We trust an npm dependency, we trust an identity gateway, we trust a help desk application, we trust a JWT validation service, and we trust an image because the application says it’s an image.

But the correct mindset asks a different question. What happens when that trust is wrong? What asset becomes reachable, how far can the compromise travel, and would we know that it happened?

That’s the difference between something that works and something that's genuinely production ready. So here’s the question I’d take back to your organisation today: which part of your application stack are you trusting without independently limiting what it can reach?