A J2EE application uses System.exit(), which also shuts down its container.
It is never a good idea for a web application to attempt to shut down the application container. Access to a function that can shut down the application is an avenue for Denial of Service (DoS) attacks.

Primary

Implementation
A call to System.exit() is probably part of leftover debug code or code imported from a non-J2EE application.

Availability
DoS: Crash, Exit, or Restart

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Architecture and Design
Separation of Privilege
The shutdown function should be a privileged function available only to a properly authorized administrative user

Implementation
Web applications should not call methods that cause the virtual machine to exit, such as System.exit()

Implementation
Web applications should also not throw any Throwables to the application server as this may adversely affect the container.

Implementation
Non-web applications may have a main() method that contains a System.exit(), but generally should not call System.exit() from other locations in the code

Included in the doPost() method defined below is a call to System.exit() in the event of a specific exception.

Public void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {try {...} catch (ApplicationSpecificException ase) {logger.error("Caught: " + ase.toString());System.exit(1);}}

J2EE Bad Practices: System.exit()

A9
Denial of Service
CWE More Specific

ERR09-J
Do not allow untrusted code to terminate the JVM

SFP3
Use of an improper API

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

7 Pernicious Kingdoms
2006-07-19
Draft 3
2006-07-19

Sean Eidemiller
Cigital
2008-07-01
added/updated demonstrative examples

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Other_Notes, Taxonomy_Mappings

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2014-06-23
updated Description, Modes_of_Introduction, Other_Notes, Potential_Mitigations

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Relationships

CWE Content Team
MITRE
2019-01-03
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2020-02-24
updated References, Relationships

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Relationships, Weakness_Ordinalities

J2EE Bad Practices: System.exit()