CWE-395: Use of NullPointerException Catch to Detect NULL… | Glexia
CWE-395 (Use of NullPointerException Catch to Detect NULL Pointer Dereference) weakness overview with consequences, detection methods, mitigations, related CVEs…
Glexia's Take · Automated analysis
CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference
Use of NullPointerException Catch to Detect NULL Pointer Dereference represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability: DoS: Resource Consumption (CPU)
Developer Pattern
CWE-395 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-395, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-395: Use of NullPointerException Catch to Detect NULL Pointer Dereference
Catching NullPointerException should not be used as an alternative to programmatic checks to prevent dereferencing a null pointer.
Programmers typically catch NullPointerException under three circumstances: The program contains a null pointer dereference. Catching the resulting exception was easier than fixing the underlying problem. The program explicitly throws a NullPointerException to signal an error condition. The code is part of a test harness that supplies unexpected input to the classes under test. Of these three circumstances, only the last is acceptable.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- The following code mistakenly catches a NullPointerException.
Remediation
- Architecture and Design Implementation: Do not extensively rely on catching exceptions (especially for validating user input) to handle errors. Handling exceptions can decrease the performance of an application.
Detection
- Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Bytecode Weakness Analysis - including disassembler + source code weakness analysis Binary Weakness Analysis - including disassembler + source code weakness analysis
- Dynamic Analysis with Manual Results Interpretation: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Framework-based Fuzzer
- Manual Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Cost effective for partial coverage: Manual Source Code Review (not inspections)
- Automated Static Analysis - Source Code: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
- Architecture or Design Review: According to SOAR [REF-1479], the following detection techniques may be useful: Highly cost effective: Formal Methods / Correct-By-Construction Cost effective for partial coverage: Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.