A repository rename attack is a supply chain attack that abuses the fact that software dependencies may refer to a repository by name or path. An attacker renames a project or creates a lookalike repository so package metadata, badges, or automation can point at the wrong source, confusing trust checks and build pipelines.
How repository rename attacks work
A repository rename attack exploits a naming assumption, not a code flaw. If dependency metadata, badges, scripts, or automation trust a repository path or display name too much, an attacker can move the target identity and make tools resolve the wrong source.
The abuse often looks mundane. A package registry entry, build manifest, README badge, CI configuration, or documentation link may continue to reference a familiar repository name even after that name is reassigned, mirrored, or made to point elsewhere.
Why this breaks supply chain trust
Repository names are often treated as a proxy for provenance. When that proxy is unstable, developers and automation can lose the ability to tell whether a dependency, maintainer page, or source tree still maps to the same project they previously reviewed.
The risk is strongest where human review and automation both rely on the same visible identifier. A rename can preserve appearances while changing the actual source behind the link, which creates room for typosquatting, lookalike projects, or quietly diverted trust.
This is why supply chain controls need to treat repository identity as something to verify, not something to assume. Build systems should validate the actual source location and ownership signals rather than trusting a name alone.
Where exposure usually appears
Exposure tends to show up in dependency metadata, package registration fields, documentation badges, automation rules, and pinned source references. Any workflow that resolves source by path, slug, or repository label can be affected if that label is later changed or reused.
Organisations are most vulnerable when they lack complete asset inventory for repositories and dependencies, or when repository links are copied into multiple systems without a canonical source-of-truth process. The more places a name is reused, the harder it becomes to spot silent drift.
Source review should therefore include the repository itself, its owner, its history, and the surrounding ecosystem of package metadata and CI/CD references. When a project is external, vendor advisories and upstream release notes should be checked alongside internal inventory.
Detection and remediation
Detection depends on comparing what a pipeline thinks it is building with what it actually fetched. That means watching for source URL changes, unexpected ownership changes, package metadata edits, badge target changes, and new repositories that claim an established project name.
After a rename event, teams should review whether any build, signing, or release process still trusts the old repository reference. If compromise is suspected, treat the issue as a supply chain integrity incident and review artifacts already produced from the affected source.
Where trust may have been redirected, rotate or reissue any credentials, tokens, keys, or deployment secrets that were exposed to the wrong build path or repository automation. If the attack influenced CI/CD access, session material and service credentials can be part of the blast radius.
For threat monitoring and incident context around supply chain abuse, The State of NHI & AI Agent Breach Report 2026 is useful background on how attackers abuse trusted automation and secrets once they gain a foothold.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Provenance and build integrity | Repository renames can subvert source provenance in build pipelines. |
| Recommendation — Verify source provenance before build and release to prevent name-based source diversion. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Repository rename attacks target software supply chain and release integrity. |
| Recommendation — Harden software sourcing and release processes to detect unexpected repository identity changes. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | This attack manipulates supplier/source identity in the software chain. |
| CM-8 — System Component Inventory | Repository rename risk is reduced by knowing which repositories and dependencies exist. | |
| IA-5 — Authenticator Management | When rename abuse affects CI/CD access or source-linked secrets, credentials may need rotation. | |
| Recommendation — Validate supplier and source integrity before accepting code, metadata, or releases. Maintain accurate inventory of repositories, dependencies, and source references. Rotate credentials and secrets that may have been exposed through compromised repository workflows. | ||
Practitioner Guidance
Governance implication: Treat repository identity as a controlled asset, not a cosmetic label. Ownership, canonical URLs, and rename handling should be explicit in engineering and release processes so that provenance does not depend on memory or informal convention.
What to watch for: A rename becomes dangerous when downstream systems still trust the old name, or when a new repository inherits an established reputation. In practice, the strongest defense is to verify source lineage at the point of ingestion and again before release.
Practitioner takeaway: If a pipeline can be fooled by a name change, it has not really established source trust yet.
Related resources from NHI Mgmt Group
- Attack Surface Management
- Who should own containment when a dependency attack exposes cloud and repository credentials?
- Why do Git based applications create unusual attack paths when they mix repository metadata with the underlying filesystem?
- What is the difference between repository-based discovery and external attack surface discovery for DAST programs?