Weekly Threat Intel: 30 September 2026 — npm Malware, Typosquat Waves and Autumn CVEs

TL;DR: What happened in threat intel this week (30 September 2026)

The week’s npm malware weekly threat intel picture is dominated by a fresh wave of malicious npm packages using post-install scripts to fetch second-stage loaders, a coordinated typosquat campaign against high-download utility packages, and several CVEs newly listed on CISA’s Known Exploited Vulnerabilities (KEV) catalog — putting dependency hygiene and rapid patching back at the top of every blue team’s priority list.

One editorial note before we dig in: in fast-moving weeks like this, package takedowns and KEV entries shift daily. Everything below is framed with confidence levels, and we tell you exactly where to re-verify before you act — because acting on stale or wrong intel is its own incident.

npm malware: this week’s supply chain campaigns

The dominant pattern this week should feel depressingly familiar: threat actors publish packages whose names closely resemble legitimate libraries, stuff them with plausible-looking README documentation, and embed a postinstall script that executes immediately on npm install. The script typically collects environment variables, CI tokens and .npmrc files, exfiltrates them to a command-and-control endpoint, and — in the more aggressive variants — drops a persistent loader into a user crontab or a systemd user unit.

The critical distinction to internalize: the malware doesn’t exploit npm the registry. It exploits npm the trust network. Your developers’ muscle memory — npm install <thing> — is the attack surface. OWASP’s work on software supply chain risks in the OWASP Top 10 and its supply chain guidance frames this precisely: the vulnerability lives in the dependency resolution and trust process, not in a memory corruption bug.

Removal guidance, in order of urgency:

• Identify every build host and developer machine where the package was installed — post-install scripts run at install time, so a clean rebuild of a container image doesn’t clear compromised hosts.
• Rotate every secret that could plausibly have been in scope: npm tokens, cloud credentials in CI variables, SSH keys, database connection strings.
• Audit npm accounts and revoke all active access tokens, then reissue with minimal scope.
• Search CI logs for outbound requests to the exfiltration endpoints observed in the campaign.

Typosquat waves: which brands and packages were targeted

The typosquat pattern this week followed three recognizable shapes:

• Transposition attacks — swapped adjacent characters in popular utility package names, preying on fast typing and autocomplete blindness.
• Homoglyph and plural attacks — adding or dropping a trailing “s”, or substituting visually similar characters, against widely depended-upon helper libraries.
• Scoped-name abuse — publishing unscoped versions of names that developers associate with popular scoped packages, a confusion vector documented in depth in academic work on dependency confusion such as Ohm et al., “Backstabber’s Knife Collection”.

The giveaway in this wave was publish metadata: squatted packages showed brand-new maintainer accounts, zero download history prior to the campaign window, and near-identical README text scraped from the legitimate project. Registry package pages — publish date, maintainer history, repository link validity — remain your fastest triage surface. Check the metadata directly on the npm registry rather than trusting any third-party dashboard’s cached copy.

How was it discovered? The same way most of these campaigns die: a researcher noticed the download spike anomaly, published the package names, and the registry moved to remove them. That lag between publish, discovery and takedown — often measured in days — is the entire business model. Detection before install is the only defense that operates on your timeline, not the attacker’s.

Loader shifts: what changed in malware delivery this week

Two delivery trends stand out against previous weeks:

• Staged, multi-hop payload retrieval. Post-install scripts increasingly fetch only a small stager; the substantive loader arrives from a second, rotating infrastructure layer. This frustrates static IOC-based blocking, because the first-stage endpoint burns quickly while the real distribution infrastructure lives longer.
• Heavier obfuscation. We’re seeing base64-layered payloads with runtime evaluation, plus legitimate JavaScript obfuscation tooling repurposed to make post-install code resistant to casual review. The calculation is simple: most developers never read package.json scripts, and obfuscation defeats the minority who do.

The strategic read: attackers are optimizing for survival-per-hour rather than infection-per-install. Your detections need to key on behavior — unexpected network connections from package managers and build tooling — rather than file hashes.

Newly exploited CVEs added to KEV and vendor advisories

The Real KEV Additions This Week

The catalog moved twice in the digest window — the NetScaler zero-days are the headline event:

Context worth internalizing: over 50,000 NetScaler instances were internet-exposed when the zero-days landed, and Citrix shipped eight NetScaler vulnerabilities that same day — triage by exposure, not by CVE count. Sources: CISA alert (27 Sep), CISA alert (30 Sep).

Autumn patch cycles reliably produce a cluster of KEV additions, and this week is no exception. As of 30 September 2026, the operational guidance is unchanged: prioritize anything on CISA’s KEV catalog that is internet-facing, then work inward. BOD 22-01 makes KEV compliance mandatory for U.S. federal civilian agencies on defined timelines — and it remains the single best free prioritization signal in the industry.

Important caveat, and we mean it: specific CVE IDs and CVSS scores move fast and get revised. Before you schedule emergency patching, verify each ID directly against CISA’s KEV catalog and the relevant vendor advisory — vendor advisories from Microsoft, Apple, Google, Adobe and the network appliance vendors (Fortinet, Cisco, Ivanti, Palo Alto) are the canonical source for exploitation status and affected versions. Don’t patch from a tweet, and don’t patch from us either — patch from the source.

The persistent pattern worth flagging: edge devices and VPN appliances continue to absorb the majority of KEV additions. Internet-facing appliance CVEs get exploited faster than workstation software CVEs because exploitation scales — one pre-auth RCE against a firewall is a botnet-enrollment button.

Hands-on: hunting npm malware in your dependency tree

Four practical techniques, in increasing order of sophistication:

• npm audit — baseline hygiene. It catches known-vulnerable versions, not malware, but it’s free and fast. Run it in CI on every build and fail on high findings.
• Lockfile diffing. Review package-lock.json changes in every pull request. A transitive dependency silently swapping versions or gaining a new resolved URL is one of the highest-signal anomalies available to you. Treat lockfile diffs like you’d treat a diff to your auth middleware.
• Package provenance checks. npm provenance attestations cryptographically link a published package to its build context. Verify provenance for packages you don’t recognize, and treat absent provenance on a “new” high-download package as a yellow flag.
• Post-install script review. Script a pre-install hook that greps package.json for preinstall, postinstall and prepare scripts and blocks any that invoke network tools or evaluators. It’s crude. It works.

For hunting at scale, a minimal YARA-style rule targeting suspicious post-install behavior in extracted package archives might look like:

rule npm_suspicious_postinstall {
  meta:
    description = "Flags package.json with network or eval in install scripts"
  strings:
    $postinstall = /"(pre)?install"s*:/ nocase
    $curl   = "curl " ascii
    $wget   = "wget " ascii
    $eval   = "eval(" ascii
    $node_e = "node -e" ascii
  condition:
    $postinstall and 1 of ($curl, $wget, $eval, $node_e)
}

Supplement it with runtime hunting: query EDR telemetry for processes where node, npm or sh spawns under a package manager and immediately makes outbound HTTPS connections. That parent-child chain is the campaign signature.

Blue-team detection ideas: log sources and sigma-style rules

Three detection layers worth building this week, expressed as sigma-style logic:

• Post-install script execution: alert on process events where parent is npm/yarn/pnpm and the child spawns curl, wget, python or a reverse-shell-capable binary. False positives exist (some legitimate packages compile native modules), so baseline your build fleet first.
• Suspicious DNS from build hosts: build agents should resolve a known, finite set of domains — your registry mirror, package hosts, your artifact store. Any NXDOMAIN burst or newly observed domain from a CI runner deserves a page. DNS telemetry from your resolver is the cheapest high-fidelity log source you own.
• CVE exploitation attempts: for each newly KEV-listed CVE, write a targeted web/app-layer rule from the vendor’s disclosure details — exploit paths are almost always documented well enough for a request-pattern match. If the vendor provides Suricata/Snort rules, deploy them rather than reinventing them.

Correlate all three in your SIEM. A post-install anomaly plus a novel DNS resolution from the same build runner inside ten minutes is not a coincidence — it’s an incident.

What this means for CI/CD and developer security

Immediate mitigations, ranked by effort-to-impact ratio:

• Pin dependencies. Exact versions in package.json and committed lockfiles everywhere. Ranges are an open door.
• Registry allowlists and a private proxy. Route all installs through an internal registry proxy with an allowlist. New packages enter via a review request, not by default.
• Scoped, short-lived tokens. CI publishes with fine-grained, time-limited tokens. Never store a maintainer’s long-lived token in pipeline variables.
• Provenance attestation requirements. Require signed provenance (Sigstore-style attestation) for packages your proxy admits. Guidance in the SLSA framework and the OpenSSF security insights tooling gives you a concrete maturity ladder.
• Disable lifecycle scripts by default for external dependencies where your tooling supports it — modern package managers increasingly offer exactly this switch.

None of this is exotic. All of it is boring. Boring is what wins against campaigns that depend on default-trust developer workflows.

CTF and learner takeaways from this week’s campaigns

If you’re building skills rather than defenses, this week’s intel maps to three excellent practice areas:

• Dependency confusion labs. Set up a private registry and a public one, misconfigure a resolver, and watch a “higher-version” public package win. Once you’ve exploited it in a lab, the mitigation set writes itself.
• Typosquat detection exercises. Write a string-similarity scorer (Levenshtein distance plus homoglyph normalization) over a registry package list and rank the squattable names in your own dependency tree.
• CVE replication in an isolated environment. Reproducing KEV-listed CVEs against intentionally vulnerable labs — never production — teaches exploit mechanics and, more importantly, teaches you exactly what the detection rule should match.

The meta-skill this week is IOC skepticism: every indicator has a shelf life, and the practitioners who last are the ones who verify against primary sources before acting.

IOC summary and weekly wrap-up

Consolidated indicators, with confidence levels — treat these as starting points for your own hunting, not gospel:

• Malicious npm package names: rotating; verify current takedown lists on the npm registry and vendor research blogs before blocking. Confidence: high for the campaign pattern, medium for any specific name older than 48 hours.
• Behavioral indicators: post-install scripts invoking curl/wget/eval; CI runners resolving previously unseen domains; base64-layered payloads in install scripts. Confidence: high.
• KEV entries: verify current catalog contents directly at cisa.gov. Confidence: authoritative at time of your check.

Next week’s watchlist: whether the npm typosquat wave migrates to other ecosystems (PyPI and RubyGems historically follow npm campaigns within weeks), a second wave of appliance CVE KEV additions as vendors complete investigations, and whether registry-side controls on lifecycle scripts tighten in response. We’ll be watching all three.

Frequently Asked Questions

How do I check if an npm package I use is malicious?

Check the publish date and maintainer history on the registry package page, verify the linked repository actually contains the code, review download history for anomalies, and run npm audit plus a lockfile diff to see exactly what entered your tree. Inspect any postinstall scripts manually before installing unfamiliar packages.

What is a typosquatting attack in package registries?

Typosquatting is registering package names that closely resemble popular ones — via typos, plurals, homoglyphs or transposed characters — to trick developers and build systems into installing malware instead of the intended library. The attack exploits typing speed and autocomplete habits, not software vulnerabilities.

Which CVEs should I patch first this week?

Prioritize CVEs on CISA’s KEV catalog that have public exploits and internet-facing exposure — edge devices and VPN appliances first. Verify each ID against the KEV catalog and the vendor advisory, since affected versions and exploitation status change as vendor investigations conclude.

How can I protect my CI/CD pipeline from npm malware?

Pin dependencies to exact versions with committed lockfiles, require provenance attestations, restrict or disable post-install lifecycle scripts, use short-lived scoped publish tokens, and route all installs through a private registry proxy with an allowlist so unknown packages can’t enter builds by default.

Where can I verify this week’s threat intel claims?

Cross-check vendor advisories directly, review CISA’s KEV catalog at cisa.gov, and inspect registry package metadata — publish dates, maintainers, provenance — on npm itself rather than relying on cached third-party dashboards or social media summaries.

Related reading

• Evilginx3 Lab: Build a Safe AiTM Phishing Lab to Understand Session Cookie Theft (and Why FIDO2 Stops It)
• MFA Fatigue and Push Bombing: How Attackers Wear Down Your Users

Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

Learning Paths · About Hmmnm · Editorial policy