On July 14, 2026, at 07:10 UTC, three packages from the AsyncAPI generator monorepo went out on npm carrying a self-spreading worm. They weren’t uploaded from some attacker’s laptop. They were published through the project’s own GitHub Actions release workflow, and each one shipped with a valid npm provenance attestation. The green checkmark that’s supposed to prove a package is trustworthy? The malware had it.
If your business runs on open source software, and every VoIP stack we know does, this one deserves ten minutes of your attention.
What Actually Happened in July
Two incidents landed within days of each other, and together they tell an uncomfortable story.
On July 11, packages belonging to Jscrambler were compromised after attackers got hold of npm publishing credentials. The poisoned versions hid native binaries that executed the moment you installed the package. One release dropped a Rust-based infostealer. Later versions got smarter. They moved the payload into an import-time self-executing function, which means the classic defense of installing with the ignore-scripts flag did nothing. The code ran the first time your application imported the module.
Then came July 14 and the AsyncAPI incident. An attacker gained push access to the project’s next branch. From there, they didn’t need to steal any npm tokens at all. They simply let the project’s own legitimate release automation do the publishing for them. The workflow signed the packages, generated provenance attestations, and pushed them to the registry exactly as designed. The pipeline worked perfectly. That was the problem.
The payload was a variant of the Miasma worm, the same family that hit 32 packages under the redhat-cloud-services npm scope back on June 1. Miasma spreads on its own. Once it lands on a developer machine or build server with npm credentials, it publishes itself into whatever packages those credentials can touch. Each infection creates new publishers.
Why Provenance Didn’t Save Anyone
npm provenance attestations were built to answer one question: did this package really come from this repository’s build pipeline? On July 14, the honest answer was yes. The malware genuinely came from the AsyncAPI project’s pipeline. Provenance proved exactly what it promised to prove, and the proof was worthless because the pipeline itself had been fed poisoned source.
This is the lesson we think too many teams will miss. Provenance tells you where a package was built. It says nothing about whether the code inside it is safe. Treating a provenance badge as a safety certificate is like trusting a letter because the envelope has the right postmark.
The scale here isn’t small either. Sonatype’s research puts more than 99 percent of all open source malware on npm. The JavaScript registry is where this war is being fought, and JavaScript is everywhere, including places VoIP engineers don’t always think about.
What This Has to Do With Your VoIP Stack
Fair question. Your softswitch is C code. Asterisk and FreeSWITCH don’t install npm packages. So why should a telecom team lose sleep over JavaScript registry malware?
Because the switch is never the whole system. Look at any modern open source VoIP deployment and you’ll find Node.js and npm sitting right next to the media server:
Admin portals and customer self-service panels are usually Node or heavy JavaScript frontends built from hundreds of npm dependencies.
Provisioning and billing glue code, the scripts that create tenants and push configs, often runs on Node.
WebRTC gateways and click-to-call widgets pull in JavaScript SDKs by the dozen.
Your CI/CD pipeline itself, the thing that builds and deploys all of the above, typically runs npm install on every commit.
Here’s the part that should bother you. An infostealer landing on the build server that deploys your PBX admin panel doesn’t just steal npm tokens. It can grab SSH keys, database credentials, and API secrets for the same infrastructure that carries your customers’ calls. The worm doesn’t care that it landed in a telecom shop. Your credentials spend just the same.
We wrote earlier this year about hardening open source VoIP against SIP-layer attacks. Supply-chain attacks are the other flank, and they arrive through the front door with valid signatures.
for more detail visit --> https://ictinnovations.com/npm-supply-chain-worm-open-source-voip-2026/
Top comments (0)