DisasterLab
PlaybooksPackage registry account compromised
Accesscritical45 minutes to prepare

Package registry account compromised

An attacker may be able to publish malicious versions of packages your customers or systems install.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

What do you need right now?

Prepare before it happensRecover from this now

Your preparation

0 of 0 safeguards ready
0%
Continue the prevention checklist
Incident worksheet

Make the next decision with evidence

Stop unauthorized publishing, identify every affected package and consumer, and re-establish trusted releases with new credentials and provenance.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Preserve registry login, token, 2FA, owner, maintainer, package, version, dist-tag, deprecation, and download events.
  • Download suspect archives safely and record cryptographic hashes, metadata, signatures, provenance, install scripts, and file differences.
  • Map publishing tokens, CI jobs, OIDC identities, signing keys, maintainers, organizations, scopes, and recovery contacts.
  • List internal and external consumers by lockfile, SBOM, cache, image, artifact, and deployment digest.

Decisions that change the response

QuestionAct whenAction
Unpublish, deprecate, or supersede?The registry's immutability and dependent-install behavior are understood.Coordinate with the registry. Mark the affected version clearly and publish a verified replacement when safe.
Pause all releases?Publisher identity, CI, signing, source, or organization ownership is not trustworthy.Freeze publishing until a clean path and reviewed artifacts exist.
Notify consumers?A malicious package was downloadable or a legitimate package was altered.Publish exact versions, hashes, dates, indicators, remediation, and a verified communication channel.

Proof that recovery worked

  • Only approved maintainers and short-lived publishing identities remain; old tokens fail.
  • Affected versions, tags, owners, README links, and package metadata match the incident record.
  • A clean source commit produces the replacement archive and expected provenance.
  • Internal deployments and caches no longer contain affected package digests.

Controls to put in place

  • Require secure MFA, two maintainers, and registry-supported trusted publishing with short-lived identity.
  • Separate install, test, sign, and publish jobs; protect release environments with review.
  • Monitor owner, token, tag, version, and download anomalies for critical packages.
  • Generate provenance and SBOMs, then verify the published archive from a fresh consumer.
Tabletop drill

In a private test package, change a dist-tag and add an unauthorized maintainer. Recover ownership, freeze publishing, compare the archive to source, rotate a token, and send a mock consumer advisory.

Escalate when

Contact the registry and incident responders immediately when a malicious public version exists, namespace ownership is lost, signing keys were exposed, or downstream customer systems may have executed the package.

What this means

A compromised npm, PyPI, container, or other registry identity can turn a single account takeover into a software supply-chain incident affecting every downstream installer.

Warning signs

  • An unknown version, tag, owner, token, or automation publisher appears.
  • Downloads or install behavior change after an unexplained release.
  • Registry security alerts or login emails are unfamiliar.
  • Customers report suspicious package behavior.

Recover now

First 15 minutes

  1. Secure a known-good registry owner account and its email.
  2. Revoke publisher tokens and pause automated publishing.
  3. Preserve package metadata, logs, artifacts, hashes, and release times.
  4. Mark or remove malicious releases using the registry’s supported process.

Today

  1. Compare published artifacts with reproducible output from trusted source.
  2. Rotate CI, signing, repository, and registry credentials in scope.
  3. Notify affected users with exact versions, indicators, and safe upgrade or removal steps.
  4. Review connected source and build systems for the initial access path.

Verify recovery

  • Only recognized owners and publishers remain.
  • Compromised tokens and versions can no longer be used.
  • Trusted artifacts match source and expected hashes.
  • Affected users can identify and remove the malicious version.

Prepare now

Access

  • Registry owners use phishing-resistant MFA and separate named accounts.
  • CI publishes with a restricted, short-lived identity where supported.

Backups and evidence

  • Released artifacts, manifests, signatures, and hashes are retained independently.

Contacts and ownership

  • Registry security contacts and package ownership proofs are recorded.

Practice

  • Publishing can be paused and a test token revoked quickly.

Common mistakes

  • Publishing a clean version without warning users about the malicious one.
  • Rotating the registry token but ignoring compromised CI.
  • Deleting evidence before comparing artifacts.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.