6mile

Turns out that naming matters and when Imperva named this bug "Node2Shell" they did us a disservice. This bug affects Python via two packges: brotli and brotlicffi. All versions are vulnerable except the latest.

DPRK has created a new leaner technique to obfuscate its C2 payloads with NullReceiver. The NPM packages call the Ethereum blockchain directly to find hidden addresses in the destination.

Because the Go and Packagist registries don't require additional publishing credentials like NPM and PyPI North Korean threat actors have been able to compromise legitimate packages via their PolinRider campaign.

NPM attack targeting Mastro targets browser extensions other than crypto wallets.

- Credential managers and MFA authenticators from LastPass, Bitwarden, 1Password, Deloitte, Dashlane, ExpressVPN, KeePass, Proton, Kaspersky, passbolt, NordPass, Zoho, etc. - Zapier browser extension. Assuming this is to gain access to platforms the victim has integrated with Zapier

Signs point to the Miasma worm, but this is unconfirmed yet.

The same threat actor that compromised Axios published three additional NPM packages within 18 hours. Unfortunately, these packages are still alive on NPM and compromising victims.

If you are a Kubernetes shop, you will want to check whether you are using the Antrea project. Nothing malicious has been deployed yet, as we caught this one early, but the threat actors compromised the Jenkins build servers, so we expect new malicious releases soon.

TeamPCP claims another victim and this time they call it "Shai-Hulud: The Third Coming"

We have helped several orgs with incident response and this is the playbook that we used.

The bash script for checking for infection? is that what you are talking about?

Hi, I'm one of the researchers that identified this threat and I blogged about it back in November (https://opensourcemalware.com/blog/contagious-interview-vsco...)

First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.

The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:

1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.

2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about: "presentation": { "reveal": "never", "echo": false, "focus": false, "close": true, "panel": "dedicated", "showReuseMessage": false}

3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.

Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).

Just search github and you'll see what I mean: https://github.com/search?q=path%3Atasks.json+vercel.app&ref...

There are dozens and dozens of bad guys using this technique right now. Microsoft needs to step up. End of story.

This malware is a full-featured RAT that uses Telegram for C2 and is only 143 lines of code. It's "RAT-as-a-library" design means that we are already seeing criminals build more complext, customized malware on top of Scopper.

The undelete package lets you recover NPM packages that have been removed and are no longer in the NPM registry. Works for both the tarballs and metadata. I use it for malware research, but you can use it for whatever you want!

That domain (npmjs[.]help) has been taken down. Looks like it was purchased and started hosting on September 5th, 2025.

I wrote this blog article to address several misconceptions I hear when I talk to engineering or infosec teams. The problem of malicious software packages isn't really well understood, so I thought I would try and tackle some misconceptions head on. I hope you enjoy it!

Thanks! Lots of tooling out there, but not much uptake. I mean, npm itself has better, more secure alternatives, but is still the most popular registry on the planet. Like, wtf?!

Transitive dependencies, yeah, but top-level dependencies that you are installing with npm i or via your manifest file are areas that you do control and can manage.

Correct.

It's not a smoking gun. It is just one of a number of signals you look for when identifying potentially malicious packages. Other things you look for are number of collaborators, how long it existed, domains it talks to, and artifacts it pulls in.

Yeah, I agree the incentive structure is broken for bug bounty hunters. Until the BB platforms themselves create some rules for their customers and researchers, we are gonna continue to have the sh*t show that we do now. The reality is that bug bounty hunters are deploying a significant percentage of the total malicious NPM packages each month.

GitHax is a labour of love right now and is in heavy development. I'm going to create a small beta testing group soon. Hit me up if you want to be in that group. Contact deets are in my GH profile.

There has been a lot of noise about software supply chain attacks over the last few years. These threats are often novel, and have colorful names like dependency confusion, repo-jacking, and commit spoofing.

Unfortunately, there is no common, agreed upon definition for what is in the software supply chain. When asked, most people I talked to would say "Uh, its your open-source libraries, right?" This is a problem, as there is a lot more that goes into building modern applications than just some open-source components. To me, the software supply chain should be all those things that are needed to build a working application. This would include things like the software engineers themselves, and the CI/CD components used. The third-parity APIs and cloud resources that the application uses should also be included. We can't hope to know how to secure the software supply chain if we don't know what's in it, or how broad its scope is.

I decided to build a project that would help the software engineering community create a common definition, and lexicon, for the software supply chain. This GitHub repository is the first version of that project.

I am looking for feedback, input, and hopefully some collaboration to help make this a viable, and lasting project. I hope you enjoy it!