CWE - CWE-754: Improper Check for Unusual or Exceptional Conditions (4.18)

Home > CWE List > CWE-754: Improper Check for Unusual or Exceptional Conditions (4.18)

CWE Glossary Definition

CWE-754: Improper Check for Unusual or Exceptional Conditions

Weakness ID: 754

Vulnerability Mapping: ALLOWED This CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review (with careful review of mapping notes)
Abstraction: Class Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

View customized information:

For users who are interested in more notional aspects of a weakness. Example: educators, technical writers, and project/program managers. For users who are concerned with the practical application and details about the nature of a weakness and how to prevent it from happening. Example: tool developers, security researchers, pen-testers, incident response analysts. For users who are mapping an issue to CWE/CAPEC IDs, i.e., finding the most appropriate CWE for a specific issue (e.g., a CVE record). Example: tool developers, security researchers. For users who wish to see all available information for the CWE/CAPEC entry. For users who want to customize what details are displayed.

Edit Custom Filter

Description

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

Extended Description

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability.

Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

Common Consequences

Section HelpThis table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Impact	Details
DoS: Crash, Exit, or Restart; Unexpected State	Scope: Integrity, Availability The data which were produced as a result of a function call could be in a bad state upon return. If the return value is not checked, then this bad data may be used in operations, possibly leading to a crash or other unintended behaviors.

Potential Mitigations

Phase(s)	Mitigation
Requirements	Strategy: Language Selection Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).
Implementation	Check the results of all functions that return a value and verify that the value is expected. Effectiveness: High Note: Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.
Implementation	If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248). Effectiveness: High Note: Using specific exceptions, and ensuring that exceptions are checked, helps programmers to anticipate and appropriately handle many unusual events that could occur.
Implementation	Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. Exposing additional information to a potential attacker in the context of an exceptional condition can help the attacker determine what attack vectors are most likely to succeed beyond DoS.
Implementation	Strategy: Input Validation 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. Note: Performing extensive input validation does not help with handling unusual conditions, but it will minimize their occurrences and will make it more difficult for attackers to trigger them.
Architecture and Design; Implementation	If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and has a better chance of recovery.
Architecture and Design	Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

Relationships

Section Help This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Pillar Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.	703	Improper Check or Handling of Exceptional Conditions
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	253	Incorrect Check of Function Return Value
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	354	Improper Validation of Integrity Check Value
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	391	Unchecked Error Condition
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	394	Unexpected Status Code or Return Value
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference
CanPrecede	Variant Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	416	Use After Free

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
MemberOf	View View - a subset of CWE entries that provides a way of examining CWE content. The two main view structures are Slices (flat lists) and Graphs (containing relationships between entries).	1003	Weaknesses for Simplified Mapping of Published Vulnerabilities
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	252	Unchecked Return Value
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	273	Improper Check for Dropped Privileges
ParentOf	Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	476	NULL Pointer Dereference

Relevant to the view "Architectural Concepts" (View-1008)

Nature	Type	ID	Name
MemberOf	Category Category - a CWE entry that contains a set of other entries that share a common characteristic.	1012	Cross Cutting

Background Details

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Modes Of Introduction

Section HelpThe different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation	REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Applicable Platforms

Section HelpThis listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

Likelihood Of Exploit

Medium

Demonstrative Examples

Example 1

Consider the following code segment:

(bad code)

Example Language: C

char buf[10], cp_buf[10];
fgets(buf, 10, stdin);
strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(bad code)

Example Language: C

buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.
It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state.
The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

The following examples read a file into a byte array.

(bad code)

Example Language: C#

char[] byteArray = new char[1024];
for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {

String userName = (String) i.Current();
String pFileName = PFILE_ROOT + "/" + userName;
StreamReader sr = new StreamReader(pFileName);
sr.Read(byteArray,0,1024);//the file is always 1k bytes
sr.Close();
processPFile(userName, byteArray);

}

(bad code)

Example Language: Java

FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {

String userName = (String) i.next();
String pFileName = PFILE_ROOT + "/" + userName;
FileInputStream fis = new FileInputStream(pFileName);
fis.read(byteArray); // the file is always 1k bytes
fis.close();
processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

Example 4

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM) == 0) {

...

}
...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

(bad code)

Example Language: Java

String itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {

...

}
...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Example 5

The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.

(bad code)

Example Language: Java

System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

Example 6

The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value.

(bad code)

Example Language: C#

Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)
Dim MyArray(50) As Byte
MyFile.Read(MyArray, 0, 50)
DoDangerousOperation(MyArray(20))

In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Example 7

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

(bad code)

Example Language: C

void host_lookup(char *user_supplied_addr){

struct hostent *hp;
in_addr_t *addr;
char hostname[64];
in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);
addr = inet_addr(user_supplied_addr);
hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);
strcpy(hostname, hp->h_name);

}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL. Since the code does not check the return value from gethostbyaddr (CWE-252), a NULL pointer dereference (CWE-476) would then occur in the call to strcpy().

Note that this code is also vulnerable to a buffer overflow (CWE-119).

Example 8

In the following C/C++ example the method outputStringToFile opens a file in the local filesystem and outputs a string to the file. The input parameters output and filename contain the string to output to the file and the name of the file respectively.

(bad code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

openFileToWrite(filename);
writeToFile(output);
closeFile(filename);

}

However, this code does not check the return values of the methods openFileToWrite, writeToFile, closeFile to verify that the file was properly opened and closed and that the string was successfully written to the file. The return values for these methods should be checked to determine if the method was successful and allow for detection of errors or unexpected conditions as in the following example.

(good code)

Example Language: C++

int outputStringToFile(char *output, char *filename) {

int isOutput = SUCCESS;

int isOpen = openFileToWrite(filename);
if (isOpen == FAIL) {

printf("Unable to open file %s", filename);
isOutput = FAIL;

}
else {

int isWrite = writeToFile(output);
if (isWrite == FAIL) {

printf("Unable to write to file %s", filename);
isOutput = FAIL;

}

int isClose = closeFile(filename);
if (isClose == FAIL)

isOutput = FAIL;

}
return isOutput;

}

Example 9

In the following Java example the method readFromFile uses a FileReader object to read the contents of a file. The FileReader object is created using the File object readFile, the readFile object is initialized using the setInputFile method. The setInputFile method should be called before calling the readFromFile method.

(bad code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}

}

However, the readFromFile method does not check to see if the readFile object is null, i.e. has not been initialized, before creating the FileReader object and reading from the input file. The readFromFile method should verify whether the readFile object is null and output an error message and raise an exception if the readFile object is null, as in the following code.

(good code)

Example Language: Java

private File readFile = null;

public void setInputFile(String inputFile) {

// create readFile File object from string containing name of file

}

public void readFromFile() {

try {

if (readFile == null) {

System.err.println("Input file has not been set, call setInputFile method before calling openInputFile");
throw NullPointerException;

}

reader = new FileReader(readFile);

// read input file

} catch (FileNotFoundException ex) {...}
catch (NullPointerException ex) {...}

}

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Reference	Description
CVE-2023-49286	Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
CVE-2007-3798	Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2006-2916	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.

Detection Methods

Method	Details
Automated Static Analysis	Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules. Effectiveness: Moderate
Manual Dynamic Analysis	Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Method

Details

Automated Static Analysis

Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.

Effectiveness: Moderate

Manual Dynamic Analysis

Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Memberships

Section HelpThis MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	742	CERT C Secure Coding Standard (2008) Chapter 9 - Memory Management (MEM)
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	802	2010 Top 25 - Risky Resource Management
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	867	2011 Top 25 - Weaknesses On the Cusp
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	876	CERT C++ Secure Coding Section 08 - Memory Management (MEM)
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	880	CERT C++ Secure Coding Section 12 - Exceptions and Error Handling (ERR)
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	962	SFP Secondary Cluster: Unchecked Status Condition
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1141	SEI CERT Oracle Secure Coding Standard for Java - Guidelines 07. Exceptional Behavior (ERR)
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1181	SEI CERT Perl Coding Standard - Guidelines 03. Expressions (EXP)
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1364	ICS Communications: Zone Boundary Failures
MemberOf	CategoryCategory - a CWE entry that contains a set of other entries that share a common characteristic.	1405	Comprehensive Categorization: Improper Check or Handling of Exceptional Conditions

Vulnerability Mapping Notes

Usage ALLOWED-WITH-REVIEW

(this CWE ID could be used to map to real-world vulnerabilities in limited situations requiring careful review)

Reason Abstraction

Rationale

This CWE entry is a Class and might have Base-level children that would be more appropriate

Comments

Examine children of this entry to see if there is a better fit

Notes

Relationship

Sometimes, when a return value can be used to indicate an error, an unchecked return value is a code-layer instance of a missing application-layer check for exceptional conditions. However, return values are not always needed to communicate exceptional conditions. For example, expiration of resources, values passed by reference, asynchronously modified data, sockets, etc. may indicate exceptional conditions without the use of a return value.

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
SEI CERT Perl Coding Standard	EXP31-PL	CWE More Abstract	Do not suppress or ignore exceptions
ISA/IEC 62443	Part 4-2	Req CR 3.5
ISA/IEC 62443	Part 4-2	Req CR 3.7

References

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341. 1st Edition. Addison Wesley. 2006.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 1, "Exceptional Conditions," Page 22. 1st Edition. Addison Wesley. 2006.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 11: Failure to Handle Errors Correctly." Page 183. McGraw-Hill. 2010.

[REF-622] Frank Kim. "Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions". SANS Software Security Institute. 2010年03月15日.
<https://www.sans.org/blog/top-25-series-rank-15-improper-check-for-unusual-or-exceptional-conditions/>. (URL validated: 2023年04月07日)

Content History

Submissions
Submission Date	Submitter	Organization
2009年03月03日 (CWE 1.3, 2009年03月10日)	CWE Content Team	MITRE
2009年03月03日 (CWE 1.3, 2009年03月10日)	New entry for reorganization of CWE-703.
Contributions
Contribution Date	Contributor	Organization
2023年04月25日	"Mapping CWE to 62443" Sub-Working Group	CWE-CAPEC ICS/OT SIG
2023年04月25日	Suggested mappings to ISA/IEC 62443.
Modifications
Modification Date	Modifier	Organization
2024年07月16日 (CWE 4.15, 2024年07月16日)	CWE Content Team	MITRE
2024年07月16日 (CWE 4.15, 2024年07月16日)	updated Relationships
2024年02月29日 (CWE 4.14, 2024年02月29日)	CWE Content Team	MITRE
2024年02月29日 (CWE 4.14, 2024年02月29日)	updated Observed_Examples
2023年06月29日	CWE Content Team	MITRE
2023年06月29日	updated Mapping_Notes
2023年04月27日	CWE Content Team	MITRE
2023年04月27日	updated References, Relationships, Taxonomy_Mappings
2023年01月31日	CWE Content Team	MITRE
2023年01月31日	updated Description, Potential_Mitigations
2022年04月28日	CWE Content Team	MITRE
2022年04月28日	updated Relationships
2021年07月20日	CWE Content Team	MITRE
2021年07月20日	updated Relationships
2021年03月15日	CWE Content Team	MITRE
2021年03月15日	updated Demonstrative_Examples, Relationships
2020年12月10日	CWE Content Team	MITRE
2020年12月10日	updated Potential_Mitigations
2020年06月25日	CWE Content Team	MITRE
2020年06月25日	updated Potential_Mitigations
2020年02月24日	CWE Content Team	MITRE
2020年02月24日	updated Potential_Mitigations, Relationships
2019年06月20日	CWE Content Team	MITRE
2019年06月20日	updated Description, Relationships
2019年01月03日	CWE Content Team	MITRE
2019年01月03日	updated Relationships, Taxonomy_Mappings
2017年11月08日	CWE Content Team	MITRE
2017年11月08日	updated Modes_of_Introduction, References, Relationships, Taxonomy_Mappings
2017年01月19日	CWE Content Team	MITRE
2017年01月19日	updated Relationships
2015年12月07日	CWE Content Team	MITRE
2015年12月07日	updated Relationships
2014年07月30日	CWE Content Team	MITRE
2014年07月30日	updated Demonstrative_Examples, Relationships
2013年02月21日	CWE Content Team	MITRE
2013年02月21日	updated Relationships
2012年10月30日	CWE Content Team	MITRE
2012年10月30日	updated Potential_Mitigations
2012年05月11日	CWE Content Team	MITRE
2012年05月11日	updated Relationships
2011年09月13日	CWE Content Team	MITRE
2011年09月13日	updated Relationships, Taxonomy_Mappings
2011年06月27日	CWE Content Team	MITRE
2011年06月27日	updated Common_Consequences, Related_Attack_Patterns, Relationships
2011年06月01日	CWE Content Team	MITRE
2011年06月01日	updated Common_Consequences
2011年03月29日	CWE Content Team	MITRE
2011年03月29日	updated Description, Relationships
2010年12月13日	CWE Content Team	MITRE
2010年12月13日	updated Relationship_Notes
2010年09月27日	CWE Content Team	MITRE
2010年09月27日	updated Potential_Mitigations
2010年06月21日	CWE Content Team	MITRE
2010年06月21日	updated Common_Consequences, Detection_Factors, Potential_Mitigations, References
2010年04月05日	CWE Content Team	MITRE
2010年04月05日	updated Demonstrative_Examples, Related_Attack_Patterns
2010年02月16日	CWE Content Team	MITRE
2010年02月16日	updated Background_Details, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Name, Observed_Examples, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships
2009年12月28日	CWE Content Team	MITRE
2009年12月28日	updated Applicable_Platforms, Likelihood_of_Exploit, Time_of_Introduction
2009年07月27日	CWE Content Team	MITRE
2009年07月27日	updated Relationships
Previous Entry Names
Change Date	Previous Entry Name
2010年02月16日	Improper Check for Exceptional Conditions

More information is available — Please edit the custom filter or select a different filter.

Page Last Updated: September 09, 2025

MITRE

Use of the Common Weakness Enumeration (CWE™) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006–2025, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

HSSEDI