cve.bz

CAPEC-640

Inclusion of Code in Existing Process

High severityLow likelihoodDetailed pattern

The adversary takes advantage of a bug in an application failing to verify the integrity of the running process to execute arbitrary code in the address space of a separate live process. The adversary could use running code in the context of another process to try to access process's memory, system/network resources, etc. The goal of this attack is to evade detection defenses and escalate privileges by masking the malicious code under an existing legitimate process. Examples of approaches include but not limited to: dynamic-link library (DLL) injection, portable executable injection, thread execution hijacking, ptrace system calls, VDSO hijacking, function hooking, reflective code loading, and more.

On this page

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-640: Inclusion of Code in Existing Process: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/640.html and https://cve.bz/cve/capec/640?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 target process] The adversary determines a process with sufficient privileges that they wish to include code into.

      2 techniques
      • On Windows, use the process explorer's security tab to see if a process is running with administror privileges.
      • On Linux, use the ps command to view running processes and pipe the output to a search for a particular user, or the root user.

  2. Experiment

    They probe what they found.

    1. [Attempt to include simple code with known output] The adversary attempts to include very simple code into the existing process to determine if the code inclusion worked. The code will differ based on the approach used to include code into an existing process.

  3. Exploit

    They carry out the attack.

    1. [Include arbitrary code into existing process] Once an adversary has determined that including code into the existing process is possible, they will include code for a targeted purpose, such as accessing that process's memory.

Prerequisites

  • The targeted application fails to verify the integrity of the running process that allows an adversary to execute arbitrary code.

Skills required

  • High skill

    Knowledge of how to load malicious code into the memory space of a running process, as well as the ability to have the running process execute this code. For example, with DLL injection, the adversary must know how to load a DLL into the memory space of another running process, and cause this process to execute the code inside of the DLL.

Consequences

What a successful attack can lead to
ImpactAffectsNote
Execute Unauthorized Commands, Read DataIntegrity, Confidentiality

Mitigations

  • Prevent unknown or malicious software from loading through using an allowlist policy.

  • Properly restrict the location of the software being used.

  • Leverage security kernel modules providing advanced access control and process restrictions like SELinux.

  • Monitor API calls like CreateRemoteThread, SuspendThread/SetThreadContext/ResumeThread, QueueUserAPC, and similar for Windows.

  • Monitor API calls like ptrace system call, use of LD_PRELOAD environment variable, dlfcn dynamic linking API calls, and similar for Linux.

  • Monitor API calls like SetWindowsHookEx and SetWinEventHook which install hook procedures for Windows.

  • Monitor processes and command-line arguments for unknown behavior related to code injection.

Weaknesses it exploits

  • CWE-114 Process Control
  • CWE-829 Inclusion of Functionality from Untrusted Control Sphere

Recent CVEs with these weaknesses

  1. 4.4CVE-2026-123858

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

  2. 5.5CVE-2026-123854

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

  3. 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

  4. 7.0CVE-2026-123849

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

  5. 3.3CVE-2026-123843

    In JetBrains IntelliJ IDEA before 2026.3 untrusted projects could trigger changes to GPG agent configuration

  6. 7.8CVE-2026-123838

    In JetBrains IntelliJ IDEA before 2026.3 code execution was possible in Safe Mode via UI Designer form file

  7. 3.6CVE-2026-123833

    In JetBrains IntelliJ IDEA before 2026.3 database connections could be established in untrusted projects

  8. 9.6CVE-2026-123832

    In JetBrains CLion before 2026.2 code execution was possible in Safe Mode via JSON compilation database

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

Part of

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