Skip to content

2026-02-05 — NPM optimizer-cpu malware (GHSA-x66r-5jww-pf82)

Source: https://github.com/advisories/GHSA-x66r-5jww-pf82
Published: 2026-02-05
Type: Malware / supply-chain compromise

What happened

The NPM package optimizer-cpu was flagged as malicious. GitHub’s advisory text states that any machine that installed or ran it should be treated as fully compromised.

Why this matters (durable guidance)

Supply-chain malware incidents are increasingly common, and the response playbook is broadly reusable: - Assume credential theft (env vars, SSH keys, cloud creds, tokens, browser cookies, CI secrets). - Assume persistence (cron/systemd launch agents, shell profile modifications, new binaries). - Assume lateral movement if the machine had network access to sensitive systems.

What to do now (triage)

If you suspect this package was installed or executed:

  1. Isolate the host

  2. Remove from network (or at least block egress) to stop further exfiltration.

  3. Rotate secrets from a clean machine

  4. Rotate all credentials that were accessible from the affected host (GitHub tokens, NPM tokens, cloud keys, SSH keys, DB creds, etc.).

  5. Rebuild rather than “clean”

  6. Prefer re-imaging/rebuilding the machine (and CI runners) over attempting removal.

  7. Hunt for additional exposure

  8. Identify where the host authenticated: GitHub orgs, cloud accounts, package registries, VPNs.

  9. Review logs for suspicious authentication and outbound connections.

  10. Pin/verify dependencies going forward

  11. Use lockfiles, private registries/allowlists, provenance (where available), and dependency review gates.

September 23 follow-up: Perl Crypt::SelfCertificate — payload hiding patterns worth memorizing

GHSA-9ppr-x3mg-6jg2 / CVE-2026-95831 (high): Crypt::SelfCertificate 1.01–1.05 for Perl ships a Python dropper saved as a certificate file — lib/Crypt/SelfCertificate/sample/validate.p12 (1.01) and lib/Crypt/SelfCertificate/sample/cert7.pem (1.05) — whose generate_certificate path fetches code from a hardcoded base64-obfuscated http URL and executes the response body directly, with no dropped script on disk. Durable axes for both hunters and implant-triage:

  • Extension camouflage in sample/ and data directories. Payloads hide behind .p12/.pem/.key names inside packages whose stated job is certificates — a reviewer skimming for .py/.sh misses them. Hunt rule for any registry package: file(1) every non-source data file (magic bytes, not extension) in share/, sample/, data/, test/ directories; a "certificate" that starts with #!/usr/bin/env python is the finding.
  • Missing test scripts and build hooks in an otherwise-normal package is a signal, not sloppiness. The advisory notes the releases carry no tests or build hooks — a package published straight from a working tree with zero QA scaffolding is anomalous for anything with dependents.
  • No-drop execution (urllib → exec) means disk-image hunting fails. Triage evidence lives in process trees, egress logs to base64-decodable destinations, and the package tarball itself — the advisory helpfully publishes SHA-256s of both dropper files for sweep queries (search EDR/file-integrity for the validate.p12/cert7.pem digests before decoding anything).
  • Copy-forward pattern for authorized red-team tooling reviews and for registry-sweep hunting: obfuscate-the-c2-URL + trusted-extension filename + trigger-on-normal-API-call is the standard low-visibility CPAN/PyPI/npm implant shape; treat any package that executes its own data files as suspect.

References

  • GitHub Advisory: https://github.com/advisories/GHSA-x66r-5jww-pf82
  • Related checklist: /checklists/malicious-package-response.md
  • Related best practice: /best-practices/supply-chain-malware-triage.md