CAPEC-692

Version Control Systems are widely used by developers to host, track, and manage source code files in an easy and synchronous manner. These systems are often leveraged to host open-source software that other developers can incorporate into their own applications or use as standalone applications. To prevent downloading vulnerable and/or malicious code, developers will often check the metadata of VCS repository commits to determine the repository's overall pedigree. This may include a variety of information, such as the following:

• Owner of the repository
• Author(s) of commits
• Frequency of commits
• Date/Time of commits
• Repository activity graphs

These precursory checks can assist developers in determining whether a trusted individual/organization is providing the source code, how often the code is updated, and the relative popularity of the software. However, an adversary can spoof this metadata to make a repository containing malicious code appear as originating from a trusted source, being frequently maintained, and being commonly used by other developers. Without performing additional security activities, unassuming developers may be duped by this spoofed metadata and include the malicious code within their systems/applications. The adversary is then ultimately able to achieve numerous negative technical impacts, while the victim remains unaware of any malicious activity.

How the attack unfolds

1. Explore

   The attacker looks for a way in.

   1. [Identify target] The adversary must first identify a target repository for them to spoof. Typically, this will be a popular and widely used repository, as to increase the amount of victims a successful attack will exploit.

2. Experiment

   They probe what they found.

   2. [Create malicious repository] The adversary must create a malicious repository that imitates the legitimate repository being spoofed. This may include creating a username that closely matches the legitimate repository owner; creating a repository name that closely matches the legitimate repository name; uploading the legitimate source code; and more.

   3. [Spoof commit metadata] Once the malicious repository has been created, the adversary must then spoof the commit metadata to make the repository appear to be frequently maintained and originating from trusted sources.

      2 techniques

      • Git Commit Timestamps: The adversary generates numerous fake commits while setting the "GIT_AUTHOR_DATE" and "GIT_COMMITTER_DATE" environment variables to a date which is to be spoofed.
      • Git Commit Contributors: The adversary obtains a legitimate and trusted user's email address and then sets this information via the "git config" command. The adversary can then commit changes leveraging this username.

3. Exploit

   They carry out the attack.

   4. [Exploit victims] The adversary infiltrates software and/or system environments with the goal of conducting additional attacks.

      2 techniques

      • Active: The adversary attempts to trick victims into downloading the malicious software by means such as phishing and social engineering.
      • Passive: The adversary waits for victims to download and leverage malicious software.

Prerequisites

• Identification of a popular open-source repository whose metadata is to be spoofed.

Skills required

• Medium skill

  Ability to spoof a variety of repository metadata to convince victims the source is trusted.

Consequences

Mitigations

• Before downloading open-source software, perform precursory metadata checks to determine the author(s), frequency of updates, when the software was last updated, and if the software is widely leveraged.

• Reference vulnerability databases to determine if the software contains known vulnerabilities.

• Only download open-source software from reputable hosting sites or package managers.

• Only download open-source software that has been adequately signed by the developer(s). For repository commits/tags, look for the "Verified" status and for developers leveraging "Vigilant Mode" (GitHub) or similar modes.

• After downloading open-source software, ensure integrity values have not changed.

• Before executing or incorporating the software, leverage automated testing techniques (e.g., static and dynamic analysis) to determine if the software behaves maliciously.

Weaknesses it exploits

• CWE-494 Download of Code Without Integrity Check

Recent CVEs with these weaknesses

1. 7.2CVE-2026-1187912026-11-09

   The application implements software update functionality without adequate authenticity and integrity validation, allowing update packages to be accepted without sufficient cryptographic verification.

2. 6.3CVE-2026-1121702026-11-09

   The software downloads upgrade files without performing integrity checks, allowing the installation of tampered updates.

3. 9.2CVE-2026-1184622026-11-09

   Update components download and execute code without proper authenticity verification, relying on ignored hashes or forgeable checksums. Some update paths also permit archive traversal or script execution.

4. 2.0CVE-2026-1235082026-11-08

   Vikunja before 2.7.1 contains a supply chain vulnerability in its mage release targets that fetch the xgo module and Docker image by mutable latest references. Attackers who compromise the upstream xgo module, image, or registry can inject…

5. 7.5CVE-2026-1046572026-11-06

   Missing integrity verification in the Progress Software Fiddler Download and Setup Skill on Linux, macOS, and Windows which allows an attacker to compromise or influence a release component and execute attacker-controlled code when a user …

6. 2.1CVE-2026-1217502026-11-04

   Node Version Manager (nvm) is a POSIX-compliant shell function for managing multiple node.js versions. In versions 0.40.5 through 0.40.8, `nvm_download_artifact` downloads a release archive directly to its final path in `$NVM_DIR/.cache` a…

7. 8.6CVE-2026-1100222026-11-04

   The PFI plugin framework deploys executable assemblies (DLLs) from a signed plugin package into the local plugin repository and loads them via reflection, but the deployment routine processes archive entries that were never covered by the …

8. 7.4CVE-2026-920922026-10-29

   A flaw was found in openshift-ansible. The installer container's `run` script downloads and executes remote inventory and dynamic scripts without integrity verification. A remote attacker, by performing a Man-in-the-Middle (MITM) attack or…

The newest records naming one of them. Each weakness's page lists them all.

Related attack patterns

Part of

• CAPEC-691 Spoof Open-Source Software Metadata

Examples

MITRE's words, unchanged: CAPEC-692 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.