Cybersecurity glossary
What is Package Hijacking?
Learn what package hijacking is, how attackers abuse maintainer accounts or registry permissions, and which controls reduce the blast radius of compromised trusted packages.
Definition
Package hijacking is a software supply-chain compromise where an attacker gains control over an existing trusted package, maintainer account, or publishing workflow and releases unauthorized versions under that package's legitimate name.
Why package hijacking matters
Open-source ecosystems run on delegated trust. Once a package is widely adopted, build systems tend to treat its releases as routine maintenance rather than fresh third-party code.
Package hijacking abuses that trust by taking over the publishing path of a package people already depend on. Unlike a brand-new malicious package, the attacker inherits reputation, download volume, dependency graphs, and automated update behavior.
Common hijacking paths
Maintainer account takeover
Password reuse, phishing, or weak MFA gives attackers publish access to a real project.
Leaked publish token
A registry token exposed in CI logs, source code, or developer machines authorizes a bad release.
Compromised pipeline
Attackers alter release automation so the package is built or published from poisoned inputs.
Abandoned ownership
Inactive maintainers, weak transfer processes, or orphaned packages create takeover opportunities.
How a hijacked release spreads
Trusted package exists
Applications and libraries already depend on a package with a legitimate reputation.
Publisher control is stolen
The attacker obtains credentials, tokens, maintainer rights, or CI release permissions.
Unauthorized version ships
A new release is published under the real package name, often with subtle or obfuscated changes.
Consumers update
Automated dependency bots, floating ranges, or fresh installs pull the hijacked version.
Payload executes
Install hooks, post-build steps, or runtime imports steal secrets, alter artifacts, or create persistence.
Cleanup races propagation
Maintainers and registries remove or replace the version while consumers rebuild and rotate credentials.
Package hijacking controls compared
| Control | Reduces | Remaining gap |
|---|---|---|
| Phishing-resistant MFA | Maintainer account takeover | Does not protect leaked long-lived publish tokens |
| Trusted publishing / OIDC | Static token theft from CI | Pipeline compromise can still publish bad inputs |
| Release signing | Unsigned or out-of-band artifacts | Compromised signing authority can sign malicious releases |
| Pinned versions and review | Automatic uptake of a hijacked version | Review must catch subtle malicious changes |
Package hijacking defense checklist
- Require MFA for all maintainer and registry accounts with publish rights.
- Prefer short-lived trusted publishing over long-lived package registry tokens.
- Store release credentials outside source control and developer laptops.
- Limit who can publish and require review for ownership or maintainer changes.
- Sign release artifacts and verify signatures in downstream installation workflows.
- Pin dependencies and treat sudden new versions of critical packages as review events.
- Monitor for new install scripts, obfuscated diffs, and release metadata that diverges from source.
- Maintain an incident playbook for revocation, clean re-release, disclosure, and consumer guidance.
The practical takeaway
Package hijacking is about control of a trusted distribution channel. The package name is real, the history is real, and that is exactly why the attack works.
Protect maintainer identities, remove static publishing secrets, verify releases, and slow down automatic adoption of sensitive dependency updates. Trustworthy packages still need trustworthy publishing.
Related security terms
Malicious Package
Harmful package content that may be published after hijacking succeeds.
Package Repository
The registry platform whose accounts, tokens, and publishing controls are targeted.
Code Signing
A way to verify that releases came from an expected publisher identity.
Artifact Signing
Signing packages and images so downstream systems can enforce integrity policy.
Software Supply Chain Attack
The wider attack class that includes compromised package distribution.
Frequently asked questions
What is package hijacking in simple terms?
An attacker takes over a real package's publishing path and ships a bad version that users trust because the name and history are legitimate.
How is package hijacking different from a malicious package?
A malicious package describes harmful content. Package hijacking describes how harmful content gets published under an already trusted package through account, token, maintainer, or workflow compromise.
How do attackers hijack packages?
Common paths include stolen maintainer credentials, leaked publish tokens, weak recovery processes, abandoned packages, compromised CI jobs, and social engineering of project owners.
Why is package hijacking so dangerous?
Consumers often auto-update trusted packages, so a single unauthorized release can reach many applications before scanners or maintainers notice.
Can dependency pinning stop package hijacking?
Pinning limits surprise upgrades, but it does not protect teams that deliberately update to the hijacked version or install during a compromised release window.
What should maintainers do after a hijack?
Revoke tokens, reset credentials, remove malicious releases if the registry allows it, publish a clean fixed version, disclose impact, and help consumers rotate exposed secrets.
What should consumers monitor?
Watch for unexpected maintainer changes, new install scripts, sudden obfuscated code, unusual release timing, and package versions that do not match upstream source history.
References
Explore authoritative guidance and frameworks related to package hijacking.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.