The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
View on MITREThe injected code could access restricted data / files.
Injected code can access resources that the attacker is directly prevented from accessing.
Code injection attacks can lead to loss of data integrity in nearly all cases as the control-plane data injected is always incidental to data recall or writing. Additionally, code injection can often result in the execution of arbitrary code or at least modify what code can be executed.
Often the actions performed by injected control code are unlogged.
If possible, refactor your code so that it does not need to use eval() at all.
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
No detection method information available for this CWE.
edit-config.pl: This CGI script is used to modify settings in a configuration file.
The script intends to take the 'action' parameter and invoke one of a variety of functions based on the value of that parameter - config_file_add_key(), config_file_set_key(), or config_file_delete_key(). It could set up a conditional to invoke each function separately, but eval() is a powerful way of doing the same thing in fewer lines of code, especially when a large number of functions or variables are involved. Unfortunately, in this case, the attacker can provide other values in the action parameter, such as:
This simple script asks a user to supply a list of numbers as input and adds them together.
The eval() function can take the user-supplied list and convert it into a Python list object, therefore allowing the programmer to use list comprehension methods to work with the data. However, if code is supplied to the eval() function, it will execute that code. For example, a malicious user could supply the following string:
This simple script asks a user to supply a list of numbers as input and adds them together.
The eval() function can take the user-supplied list and convert it into a Python list object, therefore allowing the programmer to use list comprehension methods to work with the data. However, if code is supplied to the eval() function, it will execute that code. For example, a malicious user could supply the following string:
Framework for LLM applications allows eval injection via a crafted response from a hosting provider.
View DetailsChain: regex in EXIF processor code does not correctly determine where a string ends (CWE-625), enabling eval injection (CWE-95), as exploited in the wild per CISA KEV.
View DetailsChain: backslash followed by a newline can bypass a validation step (CWE-20), leading to eval injection (CWE-95), as exploited in the wild per CISA KEV.
View DetailsEval injection in Perl program using an ID that should only contain hyphens and numbers.
View DetailsMFV. code injection into PHP eval statement using nested constructs that should not be nested.
View DetailsMFV. code injection into PHP eval statement using nested constructs that should not be nested.
View DetailsCode injection into Python eval statement from a field in a formatted file.
View Detailschain: Resultant eval injection. An invalid value prevents initialization of variables, which can be modified by attacker and later injected into PHP eval statement.
View DetailsNo relationship information available for this CWE.
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
If exploited, CWE-95 (Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')) it can compromise Confidentiality, Access Control, Integrity, Availability, Other and Non-Repudiation, leading to outcomes such as Read Files or Directories, Read Application Data, Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands and Hide Activities.
Recommended mitigations for CWE-95 include: If possible, refactor your code so that it does not need to use eval() at all. Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
CWE-95 commonly affects Java, JavaScript, Python, Perl, PHP, Ruby and Interpreted. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-95, including CVE-2024-4181, CVE-2022-2054, CVE-2021-22204, CVE-2021-22205 and CVE-2008-5071. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-95 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.