As likely already posted by others, but still relevant to share regarding the npm package madness:

Potential hardening options for npm which can be configured global and on project level:

npm has an option to ignore scripts: ignore-scripts:
Quote from documentation: ‘not run any pre- or post-scripts’

npm (since cli version 11) has an option to set a minimum release age: min-release-age
Quote from documentation: ‘only versions that were available more than given number of days .. will be installed’

Full official documentation: https://docs.npmjs.com/cli/v11/using-npm/config

Note: I have not tested these options. And keep in mind actors will always adopt to measure taken by defenders.

#npm #DFIR

I created a blog post on the NVISO blog, to share some observations we made in a recent incident dealing with Ivanti Endpoint Manager (EPMM), CVE-2026-1281, CVE-2026-1340 and not so sleepy 'sleeper shells'.
https://blog.nviso.eu/2026/03/13/ivanti-epmm-sleeper-shells-not-so-sleepy/

#BlueTeam #IncidentResponse #SharingIsCaring

I’ve been discussing patch/vulnerability management more often than usual lately. Here’s some food for thought I shared:

Not only recent examples have shown how quickly attackers turn fresh patches into mass exploitation. They’re not waiting 1–2 weeks while we run through test → stage → prod. Even with good reasons to test first, that timeline can be too slow for certain vulnerabilities.
We still need testing - and let’s be honest, the organization isn’t idle or excited about the next change to test - so the process won’t speed up.

The scope of patch/vulnerability management processes needs to expand: It doesn’t end when the patch is successfully applied. It needs to assess for each vulnerability:
 - Is this a trivial remote code execution on an network-edge device?
 - Or a niche, complex bug on an isolated system?

If it looks like the first case, plan for a compromise assessment alongside the patch rollout. Assume attackers may have moved faster than your change window.

And because reality often doesn’t give us perfect intel on day one, include structured follow-up, for example track emerging IOCs, exploit details, and vendor/community guidance post-release. This can tell you what to look for as signs of compromise or exploitation.

Bottom line: Let’s make the decision - whether and how deep to run a compromise assessment, plus the follow-up a formal part of patch/vulnerability management, and adapt the process where needed. For sure it won’t be easy, and it won’t fit every vuln on every asset. But the alternative might be a fully patched, yet compromised device that a simple check might have caught.

#PatchManagement #VulnerabilityManagement