Weakness (CWE)
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code
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").
How to prevent it (4 mitigations)
-
Architecture and Design, Implementation
If possible, refactor your code so that it does not need to use eval() at all.
-
Implementation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
-
Implementation
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.
-
Implementation
For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
Source: MITRE CWE-95
92 results · Clear filters · Feed
-
High 7.8
The nodejs framework in OpenVPN Connect 3.0 through 3.4.3 (Windows)/3.4.7 (macOS) was not properly configured, which al…
-
High 8.1
Arbitrary Code Execution in Pillow
Pillow through 10.1.0 allows PIL.ImageMath.eval Arbitrary Code Execution via the environment parameter, a different vulnerability than CVE-2022-22817 (which was about the expression parameter).
-
High 8.8
Privilege escalation in mk_tsm
Privilege escalation in mk_tsm agent plugin in Checkmk before 2.2.0p18, 2.1.0p38 and 2.0.0p39 allows local user to escalate privileges
-
High 7.8
OpenVPN Connect version 3.0 through 3.4.6 on macOS allows local users to execute code in external third party libraries…
-
High 7.8
Arbitrary Code Execution (ACE) Vulnerability
Spreadsheet::ParseExcel version 0.65 is a Perl module used for parsing Excel files. Spreadsheet::ParseExcel is vulnerable to an arbitrary code execution (ACE) vulnerability due to passing unvalidated input from a file into a string-type “eval”. Specifically, …
KEV Jan 2, 2024 -
High 8.4
fastbots Eval Injection vulnerability
fastbots is a library for fast bot and scraper development using selenium and the Page Object Model (POM) design. Prior to version 0.1.5, an attacker could modify the locators.ini locator file with python code that without proper validation it's executed and …
-
High 8.8CVE-2023-0089 Public exploit
Proofpoint Enterprise Protection webutils authenticated RCE
The webutils in Proofpoint Enterprise Protection (PPS/POD) contain a vulnerability that allows an authenticated user to execute remote code through 'eval injection'. This affects all versions 8.20.0 and below.
-
High —
code injection in phpxmlrpc/phpxmlrpc
code injection in `Wrapper::buildClientWrapperCode` via manipulation of the `$client` argument. It was possible to force the client to access local files or connect to undesired urls instead of the intended target server's url.
-
High 8.3
Improper Neutralization of Directives in Dynamically Evaluated Code
Eaton Intelligent Power Manager (IPM) prior to 1.69 is vulnerable to unauthenticated eval injection vulnerability. The software does not neutralize code syntax from users before using in the dynamic evaluation call in loadUserFile function under scripts/libs/…
-
High 8.3
The web interface of the Vertiv Avocent UMG-4000 version 4.2.1.19 is vulnerable to arbitrary remote code execution
The web interface of the Vertiv Avocent UMG-4000 version 4.2.1.19 is vulnerable to command injection because the application incorrectly neutralizes code syntax before executing. Since all commands within the web application are executed as root, this could a…
-
High 8.3CVE-2020-6650 Public exploit
Arbitrary code execution through “Update Manager” Class
UPS companion software v1.05 & Prior is affected by ‘Eval Injection’ vulnerability. The software does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call e.g.”eval” in “Update Manager” class when software …
-
High 7.9
Remote Code Execution Through Image Uploads in BookStack
BookStack before version 0.25.5 has a vulnerability where a user could upload PHP files through image upload functions, which would allow them to execute code on the host system remotely. They would then have the permissions of the PHP process. This most impa…