CWE-578: EJB Bad Practices: Use of Class Loader
The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.
Last updated
Overview
The Enterprise JavaBeans specification requires that every bean provider follow a set of programming guidelines designed to ensure that the bean will be portable and behave consistently in any EJB container. In this case, the product violates the following EJB guideline: "The enterprise bean must not attempt to create a class loader; obtain the current class loader; set the context class loader; set security manager; create a new security manager; stop the JVM; or change the input, output, and error streams." The specification justifies this requirement in the following way: "These functions are reserved for the EJB container. Allowing the enterprise bean to use these functions could compromise security and decrease the container's ability to properly manage the runtime environment."
Common consequences
What can happen when CWE-578 is exploited.
Execute Unauthorized Code or Commands, Varies by Context
Affects: Confidentiality, Integrity, Availability, Other
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-578, grouped by where in the lifecycle they apply.
Do not use the Class Loader when writing EJBs.
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following Java example is a simple stateless Enterprise JavaBean that retrieves the interest rate for the number of points for a mortgage. The interest rates for various points are retrieved from an XML document on the local file system, and the EJB uses the Class Loader for the EJB class to obtain the XML document from the local file system as an input stream.
Vulnerable example
@StatelessThis use of the Java Class Loader class within any kind of Enterprise JavaBean violates the restriction of the EJB specification against obtaining the current class loader as this could compromise the security of the application using the EJB.
An EJB is also restricted from creating a custom class loader and creating a class and instance of a class from the class loader, as shown in the following example.
Vulnerable example
@StatelessTerminology & mappings
Mapped taxonomies
- Software Fault Patterns: Use of an improper API (SFP3)
Frequently asked questions
Common questions about CWE-578.
- What is CWE-578?
- The product violates the Enterprise JavaBeans (EJB) specification by using the class loader.
- How do you prevent CWE-578?
- Do not use the Class Loader when writing EJBs.
- What are the consequences of CWE-578?
- Exploiting CWE-578 can lead to: Execute Unauthorized Code or Commands, Varies by Context.
References
- MITRE CWE definition (CWE-578) (opens in a new tab)
- CWE-578 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-578
Get alerted the moment a new CWE-578 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.