CWE-369: Divide By Zero
The product divides a value by zero.
Last updated
Overview
This weakness typically occurs when an unexpected value is provided to the product, or if an error occurs that is not properly detected. It frequently occurs in calculations involving physical dimensions such as size, length, width, and height.
Real-world CVEs
190 recorded CVEs are caused by CWE-369 (Divide By Zero). The highest-severity and most recent are shown first. 39 new CWE-369 CVEs have been recorded so far in 2026 (26 in 2025).
- CVE-2021-32494Critical · CVSS 10.0 · EPSS 55th2023-07-07
- CVE-2026-46470Critical · CVSS 9.1 · EPSS 11th2026-05-14
- CVE-2025-4637
Divide By Zero in dlib
High · CVSS 8.7 · EPSS 38th2025-05-14 - CVE-2026-37232High · CVSS 8.6 · EPSS 32th2026-06-01
- CVE-2024-26945High · CVSS 8.4 · EPSS 15th2024-05-01
- CVE-2023-3896
A divide by zero issue existed in vim of OpenCloudOS Stream
High · CVSS 7.8 · EPSS 34th2023-08-07 - CVE-2023-1127High · CVSS 7.8 · EPSS 38th2023-03-01
- CVE-2023-0512High · CVSS 7.8 · EPSS 40th2023-01-26
- CVE-2023-21789High · CVSS 7.8 · EPSS 58th2023-01-10
- CVE-2024-4785
BT: Missing Check in LL_CONNECTION_UPDATE_IND Packet Leads to Division by Zero
High · CVSS 7.6 · EPSS 38th2024-08-19 - CVE-2026-62431
Viridian STIMER division by zero
High · CVSS 7.5 · EPSS 29th2026-07-28 - CVE-2026-33593
Denial of service via crafted DNSCrypt query
High · CVSS 7.5 · EPSS 31th2026-04-22
Showing 12 of 190 recorded CWE-369 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-369 vulnerabilitiesCommon consequences
What can happen when CWE-369 is exploited.
DoS: Crash, Exit, or Restart
Affects: Availability
A Divide by Zero results in a crash.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to detect it
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.)
Effectiveness: High
Fuzzing
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following Java example contains a function to compute an average but does not validate that the input value used as the denominator is not zero. This will create an exception for attempting to divide by zero. If this error is not handled by Java exception handling, unexpected results can occur.
Vulnerable example
public int computeAverageResponseTime (int totalTime, int numRequests) {Safe example
public int computeAverageResponseTime (int totalTime, int numRequests) throws ArithmeticException {By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. The following Java code example will validate the input value, output an error message, and throw an exception.
The following C/C++ example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.
Vulnerable example
double divide(double x, double y){Safe example
const int DivideByZero = 10;By validating the input value used as the denominator the following code will ensure that a divide by zero error will not cause unexpected results. If the method is called and a zero is passed as the second argument a DivideByZero error will be thrown and should be caught by the calling block with an output message indicating the error.
The following C# example contains a function that divides two numeric values without verifying that the input value used as the denominator is not zero. This will create an error for attempting to divide by zero, if this error is not caught by the error handling capabilities of the language, unexpected results can occur.
Vulnerable example
int Division(int x, int y){Safe example
int SafeDivision(int x, int y){The method can be modified to raise, catch and handle the DivideByZeroException if the input value used as the denominator is zero.
Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2007-3268 — Invalid size value leads to divide by zero.
- CVE-2007-2723 — "Empty" content triggers divide by zero.
- CVE-2007-2237 — Height value of 0 triggers divide by zero.
Terminology & mappings
Mapped taxonomies
- OWASP Top Ten 2004: Denial of Service (A9) — CWE More Specific fit
- CERT C Secure Coding: Detect and handle floating point errors (FLP03-C)
- CERT C Secure Coding: Ensure that division and remainder operations do not result in divide-by-zero errors (INT33-C) — Exact fit
- The CERT Oracle Secure Coding Standard for Java (2011): Ensure that division and modulo operations do not result in divide-by-zero errors (NUM02-J)
- Software Fault Patterns: Glitch in computation (SFP1)
Frequently asked questions
Common questions about CWE-369.
- What is CWE-369?
- The product divides a value by zero.
- What CVEs are caused by CWE-369?
- 190 recorded CVEs are attributed to CWE-369, including CVE-2021-32494, CVE-2026-46470, CVE-2025-4637.
- Is CWE-369 part of the OWASP Top 10?
- CWE-369 maps to OWASP Top Ten 2004: Denial of Service (A9) in the OWASP security taxonomy.
- How is CWE-369 detected?
- 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.)
- What are the consequences of CWE-369?
- Exploiting CWE-369 can lead to: DoS: Crash, Exit, or Restart.
- Is CWE-369 actively exploited?
- 190 recorded CVEs are caused by CWE-369; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-369) (opens in a new tab)
- CWE-369 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-369
Get alerted the moment a new CWE-369 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.