CWE-829 is the inclusion of executable functionality, such as a library, from a source outside the intended control sphere. The product imports, requires or includes code that someone else controls.
MITRE marks it as not language specific. It reaches far beyond one stack: PHP includes, plugin loaders, dynamic imports, script tags, and the package dependencies that modern software is built from.
How it happens
Code gets pulled in at build time or run time from a location the product does not govern. If an attacker can influence where it comes from, or can put something at that location, the attacker's code runs with your product's privileges.
Patterns include:
- A file include path built from user input, or from a configuration variable that can be overwritten.
- Downloading and executing code from a remote host.
- A dependency name or registry source that an attacker can substitute for the real one.
MITRE's observed examples include CVE-2004-0285, CVE-2004-0030 and CVE-2004-0068, where modification of an assumed-immutable configuration variable in an include file allowed file inclusion through a direct request.
<?php
// Vulnerable: the include path comes from the request
include($_GET['page'] . '.php');
<?php
// Fixed: map known keys to fixed files, reject everything else
$pages = ['home' => 'home.php', 'about' => 'about.php'];
$key = $_GET['page'] ?? 'home';
if (!isset($pages[$key])) { http_response_code(404); exit; }
include $pages[$key];
What an attacker gains
MITRE says an attacker could insert malicious functionality by causing the program to download code placed in the untrusted control sphere, such as a malicious web site. The impact is the full triad, confidentiality, integrity and availability, with execution of unauthorized code or commands.
How to find it
MITRE's detection notes for this entry mention several partial coverage options: bytecode and binary weakness analysis, binary or bytecode disassembly with manual analysis, and dynamic analysis with manual interpretation of results.
In practical terms, two checks cover most cases.
- Search the code for dynamic includes, requires, imports, eval-style loading and downloads that execute. Trace each path argument back to its origin.
- Inventory your dependencies. Know every package, its source registry and its version. The free in-browser dependency scan needs no login, keeps your file on your machine, and covers up to 100 dependencies. Reachability analysis helps you see whether your code calls the vulnerable function once something is flagged.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE lists these mitigations.
- Use a vetted library or framework that does not allow this weakness, or makes it easier to avoid.
- Use enforcement by conversion. When acceptable objects such as filenames or URLs form a limited, known set, map fixed input values, such as numeric IDs, to the real names and reject everything else. For example, ID 1 maps to "inbox.txt" and ID 2 to "profile.txt". The PHP example above does the same with keys.
- Repeat client side checks on the server. Attackers can modify values after checks run, or change the client to remove them.
- Run the code in a sandbox or jail that enforces strict boundaries between the process and the operating system, such as chroot, AppArmor or SELinux. MITRE notes this limits impact on the operating system, not the rest of the application.
Add to that, from general practice: pin dependency versions, pull from registries you control, and review what a new dependency can do before you add it.
Quick check
Is a trusted third party enough to make inclusion safe?
Not by itself. If that source is compromised, or the code is altered in transit, your product runs the attacker's code. Control and verify what you include.
What does enforcement by conversion mean here?
You never accept a name or path from outside. You accept a small ID, look it up in a fixed table, and reject IDs that are not in the table.
