Which versions of pino-debugging are malicious?

The following npm versions of pino-debugging are flagged malicious: 1.1.3, 1.1.4. Treat any of these as compromised.

How do I remediate pino-debugging if I installed it?

pino-debugging establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.

I already installed pino-debugging — how do I know if it already compromised me?

If pino-debugging 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 pino-debugging part of a known attack campaign?

Yes — pino-debugging is associated with the IN-MAL-2026-007766, IN-MAL-2026-007765 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 pino-debugging 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 pino-debugging (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging pino-debugging across your stack and pipelines.

Malicious package

pino-debuggingnpm

Malicious code in pino-debugging (npm) Remove it immediately and rotate any exposed credentials.

MAL-2026-6583

Immediate action

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

npm uninstall pino-debugging

What this malware does

Package name impersonates the legitimate pino-debug. The main entry index.js requires a transitive dependency ('loadutils') that pulls a further dependency contacting a hardcoded C2 at https://fundraiser-success.vercel.app and executing a delivered payload in the consumer's Node process. Loading occurs at any require()/import of pino-debugging. index.js additionally mutates require('module').wrap at top level to rewrite require() inside any node_modules/debug module so that consumers of the popular 'debug' package are silently routed through this package's shim, expanding reach across the dependency tree. Shipped files (PUBLISH_GUIDE.md, CHANGELOG.md) openly describe the package as a supply-chain attack chain (pino-debugging -> debug-fnt/loadutils -> debug-glitzs -> C2 at fundraiser-success.vercel.app -> payload execution, including screenshot capture), while the README is copied from pino-debug and additional SECURITY*.md files assert 'Zero Known Vulnerabilities' and 'Production Ready' as cover.

Malicious versions

2 flagged

1.1.31.1.4

Indicators of compromise (SHA-256)

2f34694171d099a29f77430359b02afb82c2333967feb1ec6e0bd845b98244b9

7a1dec01ea37a9f36226fd542dd6dc519bb7e5a398895f29191aec15ac7c9e5f

Detection & response playbook

Backdoor / remote access

Find it
Scan your lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock, etc.) and build artifacts for pino-debugging (2 malicious versions). O3 Security's supply-chain scanner checks every dependency against known-malicious package intelligence at install time and in CI, flagging pino-debugging across your stack and pipelines.
If you installed it — respond
pino-debugging establishes remote access, so treat any host that installed it as fully compromised. Isolate the machine, remove the package, rotate all credentials it could reach, and rebuild from a trusted image rather than cleaning in place — a backdoor may have planted additional persistence.
Did it already run?
If pino-debugging 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 pino-debugging 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. pino-debugging on npm has been identified as a malicious package (versions 1.1.3, 1.1.4 flagged). It should be removed immediately — do not install or keep it in your dependency tree.

Campaign

IN-MAL-2026-007766IN-MAL-2026-007765

References

Credits

Amazon Inspector · finder

Detect & block this

O3 blocks pino-debugging-class packages before install and in CI — and if it already ran, its runtime egress monitoring catches the C2 callback and severs the channel.

Malware detection Runtime egress monitoring