Dormant Publisher Hijack

A dormant publisher hijack happens when an attacker takes over an abandoned or inactive software publishing account and uses its existing reputation to push malicious updates. The trust comes from history, not current integrity, which makes these accounts especially valuable in package registries and extension marketplaces.

Expanded Definition

Dormant publisher hijack is a supply chain compromise pattern in which the attacker does not create trust from scratch. Instead, they inherit trust by compromising an account that previously published legitimate software but has since gone inactive. That history can include signing keys, package ownership, extension listing control, or release publishing rights. In practice, the hijack matters most where consumers rely on reputation signals such as long-standing publisher names, stable version histories, and marketplace visibility.

The concept sits at the intersection of software supply chain security and identity governance. It is not the same as a simple account takeover, because the security impact comes from abusing residual trust in a publishing identity that the ecosystem still treats as credible. Guidance across marketplaces and registries varies, but the risk is consistent: once an attacker regains control of a dormant publisher account, malicious code can be delivered through otherwise normal update channels. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides control language that maps to this problem through account lifecycle, access enforcement, and auditability.

The most common misapplication is treating dormant publisher hijack as only a hosting-platform issue, which occurs when teams ignore publisher lifecycle controls, ownership review, and release-signing continuity.

Examples and Use Cases

Implementing protections against dormant publisher hijack rigorously often introduces operational friction, requiring organisations to weigh release convenience against stronger ownership verification and revalidation.

• A package maintainer leaves a registry account unused for years; an attacker reclaims access and pushes a malicious update under the original package name.
• An extension marketplace listing remains active even after the vendor stops maintaining it; the abandoned publisher account becomes the path for a fraudulent version release.
• A small open-source project loses its original owner, but the namespace stays valuable because downstream systems auto-trust historic publisher reputation.
• An enterprise internally mirrors third-party packages without checking maintainer activity, allowing a dormant identity compromise to enter build pipelines unnoticed.
• A registry supports account recovery without strong verification, and an attacker uses weak recovery controls to regain a dormant publishing identity.

These scenarios are best assessed alongside supply chain integrity practices such as signed artifacts, namespace monitoring, and publisher verification. The SPIFFE overview is useful here because it illustrates how machine identities should be established and validated continuously rather than trusted indefinitely by history alone.

For software teams, the practical question is not whether an account once belonged to a legitimate publisher, but whether it is still actively governed today. If the answer is no, the account should be treated as a live trust boundary, not a historical record.

Why It Matters for Security Teams

Dormant publisher hijack is dangerous because it weaponises accumulated trust. Security teams often focus on malware detection after a release is published, but the failure usually begins much earlier with weak lifecycle governance, stale ownership records, and absent review of inactive accounts. In that sense, the issue is as much identity management as it is code security: a publishing identity that is no longer monitored can become the strongest attack primitive in the ecosystem.

From a control perspective, the response needs to combine access governance, event logging, and periodic review of privileged or trusted accounts. The account does not need broad system access to cause damage; it only needs the ability to ship updates through a trusted channel. That makes dormant publisher hijack especially relevant in environments that consume packages, plugins, browser extensions, and signed releases from third parties. It also connects to NHI governance when automated publishing identities, service accounts, or release bots are left unmanaged and later become takeover candidates. CISOs and platform owners should align controls with NIST SP 800-53 Rev 5 Security and Privacy Controls and review whether inactive publishers are still implicitly trusted by CI/CD or dependency management systems.

Organisations typically encounter the consequence only after a poisoned update is discovered in production, at which point dormant publisher hijack becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do dormant publisher accounts and old install counts create false trust in extension marketplaces?
• When does dormant access become a material security problem?
• Why do dormant SaaS integrations create so much identity risk?
• How should teams handle unused non-human identities and dormant application access?