Security researchers tracking open-source supply chain risk have identified a resurgent and quietly effective attack vector: npm package hijacking through expired maintainer domains. The technique is not new, but its scale is growing as domain registrars report a steady rise in lapsed corporate and personal domains that were once tied to active npm publisher accounts. When a maintainer's email domain expires, anyone can re-register it, intercept the "forgot password" flow on the npm registry, and seize control of a package that may be pulled by thousands of downstream projects every day. Unlike phishing-based takeovers or leaked-token attacks, this method requires no interaction with the victim at all — just a few dollars and a domain marketplace.
The pattern has drawn renewed attention from the security community over the past year as researchers systematically scanned public npm metadata for maintainer emails tied to domains in expired, pending-delete, or auction status. The findings are consistent across multiple independent studies: a meaningful percentage of actively-depended-upon packages list contact emails on domains that no longer belong to the original maintainer or their employer. For an ecosystem where a single popular package can sit transitively beneath tens of thousands of applications, that is a structural weakness that traditional vulnerability scanning does not catch.
How the Attack Works
The mechanics are almost embarrassingly simple, which is part of what makes this vector so persistent:
- Identify a target package. Attackers query the npm registry API or public metadata dumps for maintainer email addresses, cross-referencing them against WHOIS records and expired-domain marketplaces.
- Acquire the lapsed domain. Many maintainer emails are tied to personal domains, defunct startups, or company domains abandoned after an acquisition, rebrand, or shutdown. These are often available for purchase at standard registration prices.
- Stand up mail service. Once the domain is under attacker control, they configure MX records and a basic mail server — or a domain-parking mail relay — capable of receiving inbound messages.
- Trigger account recovery. The attacker initiates a password reset on npmjs.com (or, in some cases, on GitHub or GitLab accounts that gate npm publishing via SSO) using the now-attacker-controlled email address.
- Publish a malicious version. With account access restored, the attacker ships a new version of the package — frequently a patch-level bump to avoid drawing attention — containing an info-stealer, a cryptominer, a backdoor, or a dependency-confusion loader that pulls a second-stage payload at install or runtime.
Because the compromised account is the legitimate, historically trusted publisher, the malicious release inherits every signal that downstream consumers use to judge trust: existing download counts, version history, and in many cases an unbroken chain of prior releases with no red flags. Automated dependency bots and lockfile-based CI pipelines will happily pull the poisoned version on the next npm install or npm update.
Why This Slips Past Traditional Defenses
Most software composition analysis (SCA) tooling is built to match package versions against known-vulnerability databases — it answers "is this version associated with a disclosed CVE?" A domain-hijacked release is, by definition, brand new and has no CVE yet. Signature- and CVE-based scanning is structurally blind to a first-seen malicious publish, and the detection lag between a hijacked release going live and a CVE or GHSA advisory being filed has historically ranged from days to several weeks — an eternity in CI/CD terms, where the package may already be baked into dozens of downstream builds.
Maintainer identity and account hygiene have also historically fallen outside the scope of both SCA and cloud security posture tools. Domain expiration monitoring lives in IT or brand-protection teams' remit, not application security's, so the signal that would flag the risk — "this maintainer's contact domain is expiring in 30 days" — rarely reaches the people evaluating open-source risk. npm's own two-factor authentication requirements for high-download packages have reduced but not eliminated the exposure, since 2FA recovery flows themselves can, in some configurations, fall back to email.
The Scale of the Exposure
Independent research scanning public npm registry metadata against domain-expiration and auction databases has repeatedly found thousands of packages whose listed maintainer contact sits on a domain that is expired, unregistered, or in a redemption/pending-delete window at the time of the scan. Even a conservative reading of that data — accounting for maintainers who have simply moved to new emails without malicious intent — leaves a nontrivial population of packages where the only thing standing between a legitimate publish and a hostile one is whoever can win an auction on a domain marketplace. Given that a substantial share of the npm dependency graph is transitive — pulled in by other packages rather than declared directly by application developers — most engineering organizations have no visibility into how many of their build artifacts ultimately trace back to a maintainer identity resting on this kind of fragile foundation.
The economics make this an attractive vector for financially motivated groups as well as more targeted actors. Domain acquisition costs a fraction of what it takes to develop a zero-day, requires no code execution exploit, and the resulting payload distribution model — legitimate package, legitimate registry, legitimate download path — is far stealthier than standing up a typosquat package from scratch. Security teams that have spent the last several years hardening around typosquatting and dependency confusion are, in effect, facing a variant of account takeover that borrows the trust of an entirely legitimate artifact.
What Security Teams Should Do Now
A few practical steps reduce exposure meaningfully:
- Pin and verify, don't just lock. Lockfiles prevent unintended drift but do not stop a deliberate, attacker-initiated version bump from being pulled on the next dependency refresh cycle. Combine lockfiles with provenance verification where the registry supports it.
- Monitor for anomalous publish behavior. A sudden release from a package that has been dormant for a year, a version bump with no corresponding GitHub commit history, or a new maintainer email on a package's npm metadata are all worth automated alerting.
- Track your own maintainer exposure. If your organization publishes internal or open-source packages, audit the domains behind every maintainer email and renew or transfer them well before expiration — including domains tied to acquired companies or rebranded products.
- Prioritize reachability over inventory. Not every transitively included package with a shaky maintainer domain is equally urgent; the packages whose code paths are actually invoked at runtime deserve first attention.
How Safeguard Helps
Safeguard is built to close exactly this kind of blind spot between "known CVE" and "actual runtime risk." Our reachability analysis engine determines whether a hijack-vulnerable or newly suspicious package version's code paths are actually exercised by your application, so security teams can triage domain-takeover and account-compromise risk by real exposure rather than raw dependency count. Griffin AI continuously watches for anomalous publish patterns — unexpected maintainer changes, dormant packages suddenly shipping new versions, and metadata shifts consistent with account takeover — surfacing them long before a CVE or advisory is ever filed. Safeguard's SBOM generation and ingest capabilities give teams a live, queryable map of every transitive dependency and its maintainer provenance, so an expired-domain exposure discovered anywhere in the ecosystem can be instantly checked against your own build graph. And when a hijacked or malicious version is confirmed, Safeguard's auto-fix pull requests roll affected projects back to the last known-good version automatically, cutting remediation time from days to minutes.