CWE-94: Improper Control of Generation of Code ('Code Injection')

This weakness occurs when a product incorporates externally influenced data from an upstream component into a code segment without adequately controlling special characters or structures in that data. An attacker may alter the syntax, control flow, or operations performed by the generated code rather than supplying ordinary data. Because the generated code may execute with the product's privileges, the impact depends on context and can extend beyond the original input-processing operation.

The defining characteristic is the flow of externally influenced data into code generation while special elements that can change syntax or control flow are not correctly neutralized. The weakness commonly appears when code is generated dynamically or when input reaches code evaluation and execution mechanisms. The record lists interpreted languages as a sometimes applicable platform and AI/ML as an applicable technology with undetermined prevalence.

Potential consequences include bypassing authentication or other access control protections when injected code controls authentication, gaining privileges or assuming another identity, and accessing resources that should be unavailable to the attacker. Injected code can execute unauthorized code or commands and affect confidentiality, integrity, and availability; the record notes that integrity loss can commonly result because injected control-plane data is incidental to data retrieval or writing. Actions performed by injected control code may also be unlogged, enabling concealment of activity and affecting non-repudiation.

• Avoid dynamic code generation: Refactor the program during architecture and design so that it does not need to generate code dynamically.
• Constrain execution: Run the code in a jail or comparable sandbox with strict process to operating system boundaries. Examples in the record include Unix chroot and AppArmor. This can restrict executable code and limit operating system impact, but may be infeasible, does not prevent compromise of the rest of the application, and must be designed carefully to avoid jail-related weaknesses such as CWE-243.
• Validate against strict allowlists: Treat all input as malicious and accept only values that strictly conform to the specification, including length, type, ranges, syntax, required or extra fields, consistency, and business rules. For dynamically generated calls, checking that input is alphanumeric alone is insufficient because an attacker might still select an unintended dangerous function such as system, exec, or exit. Denylists should not be the sole defense, although they can help identify likely attacks or inputs that should be rejected.
• Test diverse inputs: During testing, use fuzzing, robustness testing, and fault injection with large and varied input suites. The product should not become unstable, crash, or produce incorrect results.
• Use taint-aware execution environments: During operation, use an environment that automatically propagates taint and blocks command execution involving tainted variables, such as Perl's -T switch. Inputs must still be validated correctly because dangerous data can be mistakenly marked untainted; the record points to CWE-183 and CWE-184 for related concerns.
• Python-specific caution: ast.literal_eval is often encouraged instead of eval because it is designed not to execute code. However, the record discourages treating it as a general solution for untrusted data because deeply nested structures can still cause excessive memory or stack consumption.

Automated static analysis, commonly called Static Application Security Testing (SAST), can identify some instances by analyzing source or compiled code without execution. It typically models data flow and control flow, then searches for potentially vulnerable paths from input sources to sinks where data interacts with external components or lower layers such as the operating system; the record rates this approach as high effectiveness, but it does not claim complete coverage.

The following are representative examples, not an exhaustive list of vulnerabilities in this weakness. The record includes these groups:

• CVE-2023-29374, CVE-2024-5565, and CVE-2024-4181: LLM frameworks or libraries place user-influenced input or a crafted provider response into Python expressions or code and pass it to exec or eval, including prompt injection variants.
• CVE-2022-2054, CVE-2007-1253, and CVE-2005-3302: malicious strings are executed through eval in Python software or a Python compiler.
• CVE-2021-22204: a chain beginning with regex handling that fails to determine a string boundary correctly leads to eval injection; the record states that it was exploited in the wild according to CISA KEV.
• CVE-2020-8218: code injection in a VPN product, also recorded as exploited in the wild according to CISA KEV.
• CVE-2008-5071, CVE-2005-1921, CVE-2005-2498, CVE-2005-1876, CVE-2005-1894, and CVE-2003-0395: code injection or eval injection in PHP programs, statements, or supporting files.
• CVE-2008-5305, CVE-2002-1750, CVE-2002-1752, CVE-2002-1753, CVE-2005-1527, CVE-2005-2837, and CVE-2002-0495: code injection or eval injection in Perl programs, eval functions, or library files.
• CVE-2001-1471: a weakness chain in which an invalid value affects variable initialization, after which an attacker can modify variables that are later inserted into a PHP eval statement.