The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code.
View on MITREIf the product uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the product to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the product's classpath (CWE-427) or add new entries to the product's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the product.
The attacker might be able to execute code that is not directly accessible to the attacker. Alternately, the attacker could call unexpected code in the wrong place or the wrong time, possibly modifying critical system state.
The attacker might be able to use reflection to call the wrong code, possibly with unexpected arguments that violate the API (CWE-227). This could cause the product to exit or hang.
By causing the wrong code to be invoked, the attacker might be able to trigger a runtime error that leaks sensitive information in the error message, such as CWE-536.
Refactor your code to avoid using reflection.
Do not use user-controlled inputs to select and load classes or code.
Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.
No detection method information available for this CWE.
A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
A common reason that programmers use the reflection API is to implement their own command dispatcher. The following example shows a command dispatcher that does not use reflection:
A programmer might refactor this code to use reflection as follows:
Cryptography API uses unsafe reflection when deserializing a private key
View DetailsDatabase system allows attackers to bypass sandbox restrictions by using the Reflection API.
View DetailsCWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product uses external input with reflection to select which classes or code to use, but it does not sufficiently prevent the input from selecting improper classes or code. If the product uses external inputs to determine which class to instantiate or which method to invoke, then an attacker could supply values to select unexpected classes or methods. If this occurs, then the attacker could create control flow paths that were not intended by the developer. These paths could bypass authentication or access control checks, or otherwise cause the product to behave in an unexpected manner. This situation becomes a doomsday scenario if the attacker can upload files into a location that appears on the product's classpath (CWE-427) or add new entries to the product's classpath (CWE-426). Under either of these conditions, the attacker can use reflection to introduce new, malicious behavior into the product.
If exploited, CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection')) it can compromise Integrity, Confidentiality, Availability and Other, leading to outcomes such as Execute Unauthorized Code or Commands, Alter Execution Logic, DoS: Crash, Exit, or Restart, Other and Read Application Data.
Recommended mitigations for CWE-470 include: Refactor your code to avoid using reflection. Do not use user-controlled inputs to select and load classes or code. Apply strict input validation by using allowlists or indirect selection to ensure that the user is only selecting allowable classes or code.
CWE-470 commonly affects Java, PHP and Interpreted. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-470, including CVE-2018-1000613 and CVE-2004-2331. 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-470 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.