cve.bz

CAPEC-538

Open-Source Library Manipulation

High severityLow likelihoodDetailed pattern

Adversaries implant malicious code in open source software (OSS) libraries to have it widely distributed, as OSS is commonly downloaded by developers and other users to incorporate into software development projects. The adversary can have a particular system in mind to target, or the implantation can be the first stage of follow-on attacks on many systems.

On this page

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-538: Open-Source Library Manipulation: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/538.html and https://cve.bz/cve/capec/538?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Determine the relevant open-source code project to target] The adversary will make the selection based on various criteria:

      • The open-source code currently in use on a selected target system.
      • The depth in the dependency graph of the open source code in relationship to other code bases in use on the target system. Choosing an OSS lower in the graph decreases the probability of discovery, but also decreases the scope of its use within the target system.
      • The programming language in which the open source code is implemented. Different languages present different opportunities for using known software weaknesses.
      • The quality of processes in place to make a contribution. For instance, some contribution sites use static and dynamic analysis tools, which could increase the probability of discovery.
      • The security requirements necessary to make a contribution. For instance, is the ownership lax allowing unsigned commits or anonymous users.

  2. Experiment

    They probe what they found.

    1. [Develop a plan for malicious contribution] The adversary develops a plan to contribute malicious code, taking the following into consideration:

      • The adversary will probably avoid easy-to-find software weaknesses, especially ones that static and dynamic analysis tools are likely to discover.
      • Common coding errors or missing edge cases of the algorithm, which can be explained away as being accidental, if discovered, will be preferred by the adversary.
      • Sometimes no identity is required to make a contribution. Other options are to steal an existing identity or create one. When creating a new identity, strike a balance between too little or too much detail. Using an stolen identity could cause a notification to be sent to the actual user.

  3. Exploit

    They carry out the attack.

    1. [Execute the plan for malicious contribution] Write the code to be contributed based on the plan and then submit the contribution. Multiple commits, possibly using multiple identities, will help obscure the attack. Monitor the contribution site to try to determine if the code has been uploaded to the target system.

Prerequisites

  • Access to the open source code base being used by the manufacturer in a system being developed or currently deployed at a victim location.

Skills required

  • High skill

    Advanced knowledge about the inclusion and specific usage of an open source code project within system being targeted for infiltration.

Weaknesses it exploits

  • CWE-494 Download of Code Without Integrity Check
  • CWE-829 Inclusion of Functionality from Untrusted Control Sphere

Recent CVEs with these weaknesses

  1. 7.2CVE-2026-118791

    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-112170

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

  3. 9.2CVE-2026-118462

    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-123508

    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. 4.4CVE-2026-123858

    In JetBrains PhpStorm before 2026.3 project files could be automatically uploaded to a deployment server from untrusted projects

  6. 5.5CVE-2026-123854

    In JetBrains PyCharm before 2026.3 code execution was possible in Safe Mode via a crafted Jupyter notebook widget module

  7. 7.8CVE-2026-123853

    In JetBrains IntelliJ IDEA before 2026.3, 2026.2.2 code execution was possible in Safe Mode via project-controlled JVM options of the build process

  8. 7.0CVE-2026-123849

    In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in untrusted projects via the Terraform File Watchers

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

Part of

Examples

An adversary with access to an open source code project introduces a hard-to-find bug in the software that al…

An adversary with access to an open source code project introduces a hard-to-find bug in the software that allows under very specific conditions for encryption to be disabled on data streams. The adversary commits the change to the code which is picked up by a manufacturer who develops VPN software. It is eventually deployed at the victim's location where the very specific conditions are met giving the adversary the ability to sniff plaintext traffic thought to be encrypted. This can provide to the adversary access to sensitive data of the victim.

MITRE's words, unchanged: CAPEC-538 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.