A repo confusion attack uses a fake or cloned source repository that looks like a trusted project, but contains malicious code. The goal is to trick developers into cloning, forking, or building from the wrong source, turning ordinary repository selection into a software supply chain compromise.
Expanded Definition
Repo confusion attack is a deceptive supply chain pattern in which an attacker creates or clones a repository that closely resembles a trusted project, then publishes malicious code, poisoned setup steps, or misleading build artifacts. The security issue is not just code tampering; it is trust substitution, where the developer selects the wrong source because naming, branding, forks, stars, or search placement create a false sense of legitimacy. In NHI and agentic AI environments, the risk expands because build systems, CI runners, and automation agents may clone repositories non-interactively and inherit whatever trust the pipeline assumes. Guidance varies across vendors on whether this is best classified as a repository impersonation issue, a dependency confusion variant, or a broader source provenance failure, but the operational control objective is consistent: verify origin, maintain signed provenance, and restrict what automation can build from. This aligns with supply chain controls discussed in MITRE ATT&CK Enterprise Matrix and with repository integrity expectations reinforced by the OWASP NHI Top 10. The most common misapplication is treating a cloned repository as trustworthy because the name and README appear familiar, which occurs when teams skip provenance checks and source pinning during cloning or CI intake.
Examples and Use Cases
Implementing strong repository verification often introduces friction for developers and automation, requiring organisations to balance faster onboarding against higher confidence in source provenance.
- A developer copies a GitHub search result into a build, not noticing that the repository is a typo-squatted clone with a malicious post-install script.
- A CI pipeline fetches code from a mirrored repo because a platform variable points to the wrong remote, then builds and signs the attacker’s payload.
- An AI coding agent clones a public project that looks authoritative, but the repo contains subtle prompt injection or build-time exfiltration logic.
- A third-party integration vendor points customers to a lookalike repository, creating a software supply chain foothold through trust in branding rather than provenance.
- A security team reviews the 52 NHI Breaches Analysis alongside CISA cyber threat advisories to understand how misdirection and credential exposure combine in real-world compromise chains.
Repository confusion also appears in agentic workflows where tool-using systems are allowed to fetch code autonomously. In those cases, the attacker does not need to breach the pipeline directly; they only need to make the wrong repository appear more trustworthy than the right one.
Why It Matters in NHI Security
Repo confusion attacks matter because they exploit the same trust assumptions that govern service accounts, CI/CD tokens, and AI agent execution authority. Once a malicious repository is cloned or built, the attacker can inherit secrets, tokens, signing contexts, and deployment permissions already present in the pipeline. That makes the issue especially dangerous in environments where NHIs are overprivileged or poorly inventoried. NHIMG research shows that 97% of NHIs carry excessive privileges and 96% of organisations store secrets outside secrets managers in vulnerable locations, which means a single mistaken clone can become a broad compromise pathway. The problem is not limited to developers; it touches build systems, package managers, and autonomous agents that act on behalf of software teams. Practical guidance from the Ultimate Guide to NHIs — Key Challenges and Risks and the Ultimate Guide to NHIs — Why NHI Security Matters Now shows why provenance, rotation, and least privilege must be treated as a single control set. Organisations typically encounter the operational impact only after a malicious build, poisoned release, or unexpected credential use, at which point repo confusion becomes unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Repository trust failures often lead to secret exposure and poisoned automation paths. |
| OWASP Agentic AI Top 10 | A-03 | Agentic systems can autonomously select or clone the wrong repository. |
| NIST CSF 2.0 | PR.DS-6 | Data integrity controls apply when build inputs or source repositories are tampered with. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust principles require verifying every source before it enters the pipeline. |
| NIST AI RMF | AI systems need governance for external artifacts and contaminated training or build inputs. |
Constrain agent repo access to allowlisted sources and require provenance checks before execution.
Related resources from NHI Mgmt Group
- How should security teams detect and contain repo confusion attacks in software supply chains?
- Why does Agentic AI make NHI attack surface expand so significantly?
- What is the difference between attack surface management and NHI governance?
- Why do NHIs create a larger attack surface than human users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
