When developers evaluate a package, they often check its GitHub repository. A package backed by a repository with thousands of stars, hundreds of forks, and active maintenance appears trustworthy. Starjacking exploits this heuristic by linking a malicious package to a popular, legitimate repository that the attacker does not control.
The attack is remarkably simple. Most package registries allow package authors to set a repository URL in the package metadata. This URL is not verified -- there is no check that the package author owns or contributes to the linked repository. An attacker can publish a malicious package and set the repository URL to any popular GitHub repository.
How Starjacking Works
Step 1: Choose a target. The attacker identifies a popular GitHub repository that either does not have an official package on the target registry or has a package under a different name than the repository.
Step 2: Create a malicious package. The attacker creates a package with a name that sounds related to the target repository. The package may contain functional code (copied from the repository or a wrapper around the legitimate package) plus malicious additions.
Step 3: Set the repository URL. The attacker sets the package's repository URL to the popular GitHub repository. On the registry's package page, this creates a link to the repository, and the registry may display the repository's star count, contributors, and activity.
Step 4: Wait for adoption. Developers who find the package on the registry see the impressive star count and active repository. They assume the package is legitimate and install it.
Why This Works
Developers use repository metadata as a trust signal for good reason -- most of the time, a well-starred repository indicates a quality package. But this heuristic fails when the link between the package and the repository is not verified.
The specific trust signals that starjacking exploits include star count (thousands of stars implies community trust), contributor count (many contributors implies thorough review), recent activity (active maintenance implies responsiveness to security issues), and license and documentation (well-documented repositories imply professionalism).
None of these signals say anything about the package itself. They describe the repository that the package claims to be associated with. The gap between "this repository is legitimate" and "this package comes from this repository" is exactly what starjacking exploits.
Registry Behavior
Different registries handle repository links differently:
npm. The repository field in package.json is displayed on the npmjs.com package page. npm does not verify ownership of the linked repository. Star counts are not directly displayed, but the repository link provides credibility.
PyPI. The project_urls field in package metadata can link to a GitHub repository. PyPI does not verify the link. The repository URL is prominently displayed on the package page.
RubyGems. The homepage and source_code_uri fields can point to any URL. No verification is performed.
Crates.io. The repository field in Cargo.toml is displayed on the crate page. No ownership verification is performed.
Detection
Verify package-repository alignment. Check that the package's code matches the repository's code. Differences indicate either a fork (which may be legitimate) or starjacking (which is not).
Check publication history. If a package claiming association with a popular repository was published recently by a new account, it deserves scrutiny. Legitimate packages associated with popular repositories typically have established publication histories.
Compare maintainer identity. Check whether the package maintainer is a contributor to the linked repository. If the maintainer has no association with the repository, the link may be fraudulent.
Analyze download patterns. A package linking to a repository with 10,000 stars but showing only 50 downloads is suspicious. Legitimate packages from popular projects typically have download counts proportional to their repository's popularity.
Check for multiple packages linking to the same repository. If several packages all link to the same popular repository, most of them are likely starjacking. The legitimate one (if it exists) is typically the one with the longest publication history and most downloads.
Prevention
For package authors: Claim your package names on all major registries, even if you do not plan to publish there. This prevents attackers from claiming your project name.
For registry maintainers: Implement repository ownership verification. GitHub's API can verify whether a user is a contributor to a repository. PyPI's Trusted Publishers feature links package publications to GitHub Actions, providing implicit ownership verification.
For developers: Do not rely solely on repository links when evaluating packages. Verify that the package code matches the repository code. Check the package maintainer's identity. Look at the package's own publication history, not just the linked repository's metrics.
For organizations: Include starjacking checks in your package approval process. When a developer requests a new dependency, verify the package-repository link before approval.
The Broader Trust Problem
Starjacking is one instance of a broader problem: package registries rely on metadata that the package author controls and that the registry does not verify. Beyond repository URLs, package authors can set arbitrary descriptions, logos, license declarations, and author information. Each unverified metadata field is a potential vector for social engineering.
The solution is not to distrust all metadata but to verify claims that are used for trust decisions. Repository ownership verification, publisher verification, and cryptographic provenance (like Sigstore) address different aspects of this trust gap.
How Safeguard.sh Helps
Safeguard.sh evaluates package provenance beyond what registry metadata provides. The platform verifies package-repository alignment, checks maintainer credibility, and flags packages with suspicious metadata patterns. By incorporating starjacking detection into its dependency analysis, Safeguard.sh helps teams make informed decisions about package trust based on verified facts rather than manipulable metadata.