What happens when malicious packages are removed from the npm registry but reappear under a new account?

Why Reuploaded Malicious npm Packages Remain Dangerous

When a malicious package is removed from npm but then reappears under a new account, the underlying threat usually survives the takedown. The package name changes, but the code can stay the same or be slightly modified, which means defenders need to treat registry removal as a containment step, not a resolution. The real question becomes whether the payload, install behavior, and external dependencies still match the original campaign.

That persistence matters because package ecosystems reward speed and reuse. If attackers preserve the same installer logic, postinstall actions, network callbacks, or credential harvesting routines, the second upload can be operationally identical even when the publisher identity is not. For this reason, investigations should focus on behavioral fingerprints rather than only the current package name.

What Changes, and What Does Not, When the Account Changes

A new registry account can break simple reputation checks, but it does not erase the artifact history. The package may still reference the same URLs, deliver the same obfuscated loader, contact the same command-and-control infrastructure, or attempt the same environment discovery steps. That is why a name-based blocklist is often too narrow for this class of abuse.

Attackers also benefit from the false sense of closure that follows a takedown. Users who watched the original package disappear may assume the issue is over, then install the reuploaded copy because it looks unfamiliar enough to evade superficial detection. Tracking code similarity, dependency drift, download timing, and outbound network patterns closes that gap better than chasing package aliases alone.

In practice, defenders should correlate the reuploaded package to the original by its observable behavior, not by registry metadata. If the package produces the same execution path, writes the same files, or tries to reach the same endpoints, it should be treated as part of the same campaign even if the account name, version string, or package title has changed.

How to Detect the Same Campaign Across New Package Names

Effective detection depends on moving beyond static naming and into content and runtime analysis. Compare package hashes where possible, inspect install scripts, unpack archives for repeated code blocks, and flag identical network destinations, domain patterns, or embedded secrets. Those indicators are more durable than the publisher account and are much harder for attackers to fully rotate.

For defenders, the highest-value control is to watch for reuse at the technique level. If a removed package later reappears with the same obfuscation style, the same post-install execution, or the same exfiltration behavior, that is strong evidence of a reupload or closely related variant. Response should then cover the whole family of artifacts, not just the most recent name.

Supply-chain controls also help here. Provenance review, package integrity checks, and allowlisting of trusted sources reduce exposure to rapid reappearance attacks. Even when a malicious package is removed quickly, downstream environments may already have cached it, mirrored it, or pulled it into build pipelines, so removal from the registry does not automatically remove it from the organisation’s software supply chain.

Risk and Threat Considerations

Reuploads create a repeatable trust abuse pattern: the attacker loses one account but retains the payload, so the same malicious code can regain distribution through a fresh identity. This is especially effective in ecosystems where users equate a new publisher handle with a new artifact and where automated tooling focuses on package name rather than behavior.

Failure mechanism: The original takedown interrupts only one distribution path, while the attacker reintroduces the same code under a different registry identity, often with similar install-time execution and outbound communication. If defenders rely on package name, publisher account, or a single removal event, they can miss the same threat re-entering the ecosystem.

Impact: Reinfected builds, repeated secret exposure, and continued compromise of developer workstations or CI pipelines can follow, because the malicious functionality was never removed, only re-licensed under a new account. The practical effect is prolonged exposure until detections are tied to code and behavior instead of identity alone.

Practitioner Guidance

What to verify: Confirm whether the reuploaded package shares installer logic, embedded endpoints, obfuscation patterns, or postinstall actions with the removed version. If those match, treat it as the same incident family even if the registry metadata does not.

What to prioritize: Build detection around artifact similarity and runtime behavior first, then use registry identity as supporting context. Name-based suppression is useful, but it should never be the primary control for a known malicious package pattern.

What good looks like: Your alerting can connect a removed package to later aliases, and your response playbook can quarantine all related versions, not just the exact package name first seen.

Practitioner takeaway: In package-registry abuse, takedown is only a temporary boundary unless your controls can follow the code, not the account.

Related resources from NHI Mgmt Group

• What do teams get wrong about checking for malicious npm packages after the registry has replaced them with a security placeholder?
• What happens when a malicious package is removed after it has already been published to a public registry?
• What happens when build systems install packages automatically without checking whether a registry item is malicious?
• What should organisations do after malicious packages are removed from a public registry?