What is CWE-476?
CWE-476 is NULL Pointer Dereference. The flaw arises when the product dereferences a pointer that it expects to be valid, but the pointer is `NULL`.
CWE-476 is NULL Pointer Dereference. The flaw arises when the product dereferences a pointer that it expects to be valid, but the pointer is `NULL`.
No vulnerability data for CWE-476
No vulnerability data in CISA KEV for CWE-476
The product dereferences a pointer that it expects to be valid but is NULL. (Roles: Acronym, Abbreviation, Acronym)
The weakness occurs when software accesses memory or an object through a NULL pointer instead of checking and handling the invalid state. It can result from an unchecked function result, incomplete initialization, input that produces a missing object, or concurrent activity that changes the pointer or its associated resource after a check. In most environments the operation faults and the process fails; in unusual conditions where NULL corresponds to address 0x0 and privileged code can access it, reads or writes may have more serious security effects.
This weakness appears when a pointer is assumed to be valid although it contains NULL, often during implementation. It may follow a function returning NULL, incomplete initialization, externally influenced state, or a race that changes a resource between checking and using it. The record lists C, C++, Java, C#, Go, and Python as applicable languages, and includes the related terms NPD, null deref, NPE, and nil pointer dereference.
The usual consequence is an availability failure: the process may crash, exit, or restart. Exception handling may prevent immediate termination on some platforms, but safely restoring operation can still be difficult. In rare cases where privileged code can read or write the memory represented by NULL, the weakness may affect confidentiality or integrity through memory disclosure, memory modification, or unauthorized code or command execution.
| Impact | Scope | Explanation |
|---|---|---|
| DoS: Crash, Exit, or Restart | Availability | NULL pointer dereferences usually result in the failure of the process unless exception handling (on some platforms) is available and implemented. Even when exception handling is being used, it can still be very difficult to return the software to a safe state of operation. |
| Execute Unauthorized Code or Commands, Read Memory, Modify Memory | Integrity, Confidentiality | In rare circumstances, when NULL is equivalent to the 0x0 memory address and privileged code can access it, then writing or reading memory is possible, which may lead to code execution. |
Requirements: Select a programming language that is not susceptible to null pointer dereference issues.
Architecture and design: Identify variables and data stores that receive information from external sources, and validate that their values are initialized only to expected values.
Implementation: Explicitly initialize variables and other data stores during declaration or immediately before first use. Check every function result and verify that it is non-null before acting on it. For pointers that may have been modified or returned by a function that can return NULL, check for NULL before dereferencing. In multithreaded or asynchronous code, use appropriate locking APIs to hold the lock from the check through the operation, then unlock it. Return-value checks are generally effective, but do not by themselves address race conditions or improperly initialized variables.
Automated dynamic analysis: Use fuzzing, robustness testing, and fault injection with diverse inputs, and watch for instability, crashes, or incorrect results. This has moderate effectiveness and may slow execution. Compilation-integrated memory-safety checks such as AddressSanitizer for C/C++ also have moderate effectiveness; they require inputs that reach the faulty code, may reduce performance, and report the error condition rather than the original cause.
Manual dynamic analysis: Trigger unusual error conditions such as low memory, insufficient privileges, interrupted transactions, or disabled basic network services, then monitor for unexpected behavior. An exception caught by the application environment may still indicate that the application did not properly handle the underlying condition.
Automated static analysis: SAST can detect some instances by modeling data and control flow and searching for vulnerable patterns from input sources to sinks. It has high effectiveness but does not guarantee detection of every instance.
| Method | Approach | Effectiveness |
|---|---|---|
| Automated Dynamic Analysis | This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results. | 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. | - |
| 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 |
| Automated Dynamic Analysis | Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].Crafted inputs are necessary to reach the code containing the error, such as generated by fuzzers. Also, these tools may reduce performance, and they only report the error condition - not the original mistake that led to the error. | Moderate |
The following are representative examples, not an exhaustive list:
CVE-2024-41130: a C++ LLM inference library dereferences NULL when a read operation fails.CVE-2005-3274, CVE-2009-4895, and CVE-2009-3547: race conditions or inadequate locking lead to a NULL dereference.CVE-2002-1912, CVE-2005-0772, CVE-2004-0365, CVE-2003-1013, CVE-2003-1000, CVE-2004-0389, CVE-2004-0458, CVE-2004-0079, and CVE-2002-0401: malformed or excessive packets and requests trigger the weakness, commonly causing denial of service or a crash.CVE-2020-29652: SSH clients can cause denial of service against Go SSH servers through a nil pointer dereference.CVE-2009-2692, CVE-2009-3620, CVE-2009-2698, CVE-2009-0949, CVE-2008-3597, CVE-2020-6078, CVE-2008-0062, CVE-2008-5183, and CVE-2001-1559: chains involve uninitialized handlers, unchecked return values, uninitialized memory or structures, inconsistent state, or incorrect system-call results.CVE-2004-0119: a crafted request during authentication protocol selection can cause a crash or arbitrary code execution.Below are representative vulnerabilities related to this CWE, prioritized by severity.
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
CyStack VulnScan continuously discovers assets, validates vulnerabilities, and helps security teams prioritize remediation across the organization.
Review CyStack's security rating and practical recommendations for websites and edge assets.
Explore cybersecurity research from our team of security specialists.
Browse practical cybersecurity knowledge across CyStack's articles and guides.
en