All CWE Weaknesses

This vulnerability occurs when a J2EE application transmits sensitive data, like login credentials or session tokens, across a network without using strong encryption. Attackers monitoring the network can easily intercept, read, or even alter this information if it's sent in plain text or protected by weak cryptographic methods.

This vulnerability occurs when a J2EE application uses session identifiers that are too short, making them easier for attackers to predict or capture.

This vulnerability occurs when a J2EE application uses the server's default error pages instead of custom ones, potentially leaking sensitive system details.

This vulnerability occurs when an Entity Bean in a J2EE application is incorrectly configured with a remote interface. This exposes data access methods to remote clients, allowing unauthorized users to potentially read sensitive information or manipulate data outside the application's intended security boundaries.

This vulnerability occurs when Enterprise JavaBean (EJB) methods are configured with overly permissive access rights, allowing attackers to exploit elevated privileges they should not have.

Deploying an ASP.NET application with debug binaries enabled exposes detailed system information, which attackers can use to map your infrastructure and plan targeted exploits.

This vulnerability occurs when an ASP.NET application fails to configure custom error pages, allowing attackers to extract sensitive information from the framework's default error messages.

This vulnerability occurs when an ASP.NET application stores passwords or other sensitive credentials in plaintext within configuration files like web.config. This exposes those credentials to anyone with file system access, effectively bypassing security controls and granting unauthorized access to protected resources.

A compiler optimization can remove security-critical code intended to wipe sensitive data from memory, leaving secrets exposed. This happens when the compiler identifies buffer-clearing operations as unnecessary 'dead stores' and eliminates them.

This vulnerability occurs when an application allows users to directly modify critical system settings or configuration values from an external source.

This vulnerability occurs when an application accepts data from an external source but fails to properly verify that the data is safe and correctly formatted before using it. This missing or flawed validation check allows malicious or malformed inputs to disrupt the application's logic or security.

This vulnerability occurs when an application builds a file path using user input but fails to properly validate it, allowing an attacker to break out of the intended directory and access files or folders anywhere on the server.

This vulnerability occurs when an application builds file paths using user-supplied input without properly validating or sanitizing it. Attackers can exploit this by inserting special directory traversal sequences like '..' to access files and directories outside the intended restricted folder.

Path traversal, often called directory traversal, occurs when an application builds a file path using user input without properly blocking sequences like '../'. This allows an attacker to break out of the intended directory and access files or folders anywhere on the server.

This vulnerability, often called directory traversal, occurs when an application builds a file path using user input without properly blocking sequences like '/../'. This lets an attacker break out of the intended directory and access files or folders elsewhere on the server.

This vulnerability occurs when an application builds a file path using user input but fails to properly block directory traversal sequences like '/dir/../filename'. This allows an attacker to break out of the intended restricted directory and access files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input but fails to properly block sequences like 'dir/../../filename'. Attackers can exploit this by injecting multiple '../' segments to escape the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds a file path using user input but fails to block or properly handle '..\' sequences. This oversight allows an attacker to break out of the intended directory and navigate to unauthorized locations in the file system.

This vulnerability occurs when an application builds file paths using user input but fails to block '\..\filename' sequences. Attackers can use these leading backslash and dot-dot sequences to escape the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input but fails to properly sanitize sequences like '\dir\..\filename'. Attackers can exploit this to escape the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input but fails to properly block sequences like 'dir\..\..\filename'. Attackers can use these multiple backslash-dot-dot sequences to escape the intended directory and access files or folders anywhere on the file system.

This vulnerability occurs when an application builds file paths using user input but fails to properly filter out '...' (triple dot) sequences. Attackers can exploit this to escape restricted directories and access unauthorized files or folders on the server.

This vulnerability occurs when an application builds file paths using user input but fails to properly filter sequences of multiple dots ('....'). Attackers can exploit this to break out of the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input but fails to properly sanitize '....//' sequences. Attackers can use this pattern to break out of the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input but fails to properly sanitize the '.../...//' sequence. Attackers can use this specific pattern to break out of the intended directory and access unauthorized files or folders elsewhere on the system.

This vulnerability occurs when an application builds file paths using user input without properly blocking absolute paths like '/etc/passwd' or 'C:\Windows\system32'. Attackers can exploit this to escape the intended directory and access sensitive files anywhere on the server.

This vulnerability occurs when an application accepts user input containing absolute file paths (starting with a forward slash like '/etc/passwd') and uses it to access files without proper security checks. Attackers can exploit this to read, write, or delete sensitive files anywhere on the server's filesystem.

This vulnerability occurs when an application accepts user-supplied input containing Windows-style absolute paths (like '\absolute\pathname\here') without proper validation. Attackers can exploit this to navigate outside the intended directory and access or manipulate sensitive files anywhere on the server's file system.

This vulnerability occurs when an application accepts user input containing Windows drive letters (like 'C:dirname') without proper validation, allowing attackers to redirect file operations to unintended locations or access arbitrary files on the system.

This vulnerability occurs when an application accepts user input containing a Windows UNC share path (like '\\UNC\share\name') without proper validation, allowing attackers to redirect file operations to unintended network locations or arbitrary files.

This vulnerability occurs when an application fails to properly handle different text representations that refer to the same file or directory on the system. Attackers can use special characters or alternative naming conventions to bypass security checks and access restricted files.

This vulnerability occurs when a system accepts file or directory paths that end with a dot (like 'file.txt.' or 'folder.') without properly checking them. Attackers can exploit this to bypass security checks, potentially accessing files or directories they shouldn't be able to reach.

This vulnerability occurs when an application accepts file or directory paths containing multiple trailing dots (like 'file....') without proper validation. Attackers can exploit this to bypass security checks, potentially accessing files or directories outside the intended scope.

This vulnerability occurs when an application accepts file paths containing internal dots (like 'file.ordir') without properly checking them. Attackers can exploit this to bypass security checks, traverse directories, and access sensitive files or system areas they shouldn't be able to reach.

This vulnerability occurs when an application accepts file paths containing sequences of multiple internal dots (like 'file...name') without proper validation. Attackers can exploit this ambiguity to bypass security checks, traverse directories, and access sensitive files or system areas they shouldn't be able to reach.

This vulnerability occurs when an application processes file paths that end with a space character (like 'document.txt ') without properly normalizing or rejecting them. Because many operating systems ignore trailing spaces in paths, this can cause the application to resolve the path differently than intended, potentially allowing attackers to access unauthorized files or directories.

This vulnerability occurs when an application accepts file or directory paths that begin with a space character (like ' filename'), without properly normalizing or validating the input. This can trick the file system's resolution logic, potentially allowing attackers to access unauthorized files or directories outside the intended scope.

This vulnerability occurs when an application accepts file paths containing internal spaces (like 'file name') without proper validation. Attackers can exploit this ambiguity to bypass security checks, potentially accessing files or directories outside the intended scope.

This vulnerability occurs when an application accepts file or directory paths that end with a slash (e.g., 'documents/') without properly normalizing them. This can confuse the system's path resolution logic, potentially allowing an attacker to bypass security checks and access files or directories they shouldn't.

This vulnerability occurs when an application accepts file or directory paths containing multiple leading slashes (like '//multiple/leading/slash') without proper normalization. Attackers can exploit this ambiguity to bypass security checks, potentially accessing files or directories outside the intended scope.

This vulnerability occurs when an application accepts file or directory paths containing multiple consecutive forward slashes (e.g., '/var//www///html') without normalizing them. Attackers can exploit this ambiguity to bypass security checks and access files or directories outside the intended scope.

This vulnerability occurs when an application accepts file or directory paths containing multiple consecutive forward slashes (like '/multiple/trailing/slash//') without normalizing them. Different systems may interpret these duplicate slashes differently, potentially allowing attackers to bypass security checks and access restricted files or directories.

This vulnerability occurs when an application accepts file paths containing sequences of multiple internal backslashes (like '\multiple\\internal\\backslash') without properly normalizing them. This can confuse the system's path resolution logic, potentially allowing attackers to access files or directories outside the intended scope.

This vulnerability occurs when an application accepts file or directory paths that end with a backslash (like 'filedir\') without properly normalizing or validating them. This trailing backslash can cause the system to interpret the path ambiguously, potentially allowing attackers to bypass security checks and access files or directories outside the intended scope.

This vulnerability occurs when an application accepts file paths containing '/./' (single dot directory) sequences without proper validation. Attackers can exploit this to bypass intended directory structures, potentially accessing sensitive files or navigating to unauthorized locations within the file system.

This vulnerability occurs when an application accepts file or directory paths containing an asterisk wildcard ('*') without proper validation. Attackers can exploit this to bypass intended access controls, potentially reading, writing, or executing files in unauthorized locations.

This vulnerability occurs when an application uses external input to build file paths, allowing attackers to bypass access controls. By submitting a path like 'fakedir/../realdir/filename', they can navigate out of a restricted directory ('fakedir') and into a protected one ('realdir'), accessing files the security mechanisms were designed to block.

This vulnerability occurs when an application's security controls successfully block access to a file's full name on Windows, but fail to protect the shorter 8.3 format version of the same filename, creating a bypassable loophole.

This vulnerability occurs when an application uses a filename to access a file but fails to properly check if that name points to a symbolic link, shortcut, or junction. This allows an attacker to manipulate the link's target, causing the application to read or write to an unintended, potentially sensitive location.

This vulnerability occurs when a software application opens files or directories without properly checking if they are symbolic links (symlinks). If an attacker can create or control a symlink, they can redirect file operations to locations outside the intended directory, potentially accessing or modifying unauthorized files.

This vulnerability occurs when an application opens a file or directory without verifying if the name points to a hard link that leads outside its intended security boundary. Attackers can exploit this to trick the software into accessing or modifying unauthorized system files.

This vulnerability occurs when an application opens a file or directory without properly validating that it is a Windows shortcut (.LNK). If the shortcut's target points to a location outside the application's intended security boundary, an attacker can trick the software into accessing unauthorized files.

This vulnerability occurs when a Windows application opens a file or directory without properly verifying if the path points to a hard link. An attacker can exploit this by creating a hard link that redirects the application to access files outside its intended permissions, potentially leading to unauthorized data manipulation.

This vulnerability occurs when software incorrectly processes a filename that points to a 'virtual' resource—like a device, pipe, or internal system object—instead of a regular file. The application mistakenly performs file operations (like read, write, or copy) on this non-file resource, which can lead to crashes, data exposure, or unexpected system behavior.

This vulnerability occurs when an application builds file paths from user input but fails to properly recognize or handle Windows reserved device names like AUX, CON, or COM1. Attackers can exploit this by submitting these special names, which typically causes the application to crash, hang, or leak sensitive information when it tries to access them as regular files.

This vulnerability occurs when an application fails to properly secure or monitor Windows Alternate Data Streams (ADS), allowing them to be used to hide or bypass security controls.

This vulnerability occurs when software fails to correctly process HFS+ file system paths that point to alternate data streams, such as a file's data or resource fork.

This vulnerability occurs when an application uses unvalidated user input to construct file or directory paths for filesystem operations.

This vulnerability occurs when an application uses untrusted external input to build a command, query, or data structure for another component, but fails to properly sanitize special characters or syntax. This allows the input to alter the intended meaning or behavior when the downstream component processes it.

This vulnerability occurs when an application fails to properly filter or encode user-supplied data containing special characters or commands that can be interpreted in a different context, such as a command shell, file system, or data format.

This vulnerability occurs when an application successfully blocks or sanitizes a known set of dangerous inputs but fails to recognize and handle alternative forms that have the same meaning or effect.

This vulnerability occurs when an application builds a system command using untrusted user input without properly sanitizing it. An attacker can inject their own commands by inserting special characters or code, tricking the application into executing unintended and potentially harmful actions on the underlying system.

OS Command Injection occurs when an application builds a system command using untrusted, external input without properly sanitizing it. This allows an attacker to inject and execute arbitrary commands on the underlying operating system.

This vulnerability occurs when a web application fails to properly sanitize or encode user-supplied input before displaying it on a webpage viewed by other users.

This vulnerability, commonly known as Basic Cross-Site Scripting (XSS), occurs when a web application fails to properly sanitize user input containing HTML and JavaScript tags. When untrusted data containing characters like <, >, and & is rendered directly into a webpage, a browser may execute it as active code, not just display it as text.

This vulnerability occurs when an application fails to properly sanitize user-supplied input before displaying it within an error message web page. If special characters used in web scripts are not neutralized, an attacker can inject malicious code that executes in a user's browser.

This vulnerability occurs when a web application fails to properly sanitize or escape script code within the attributes of HTML IMG tags, such as the 'src' attribute.

This vulnerability occurs when a web application fails to properly sanitize or block JavaScript URIs (like 'javascript:') within HTML tag attributes. Attackers can inject malicious code into attributes such as onmouseover, onload, onerror, or style, leading to cross-site scripting (XSS) attacks when the page renders.

This vulnerability occurs when a web application fails to properly sanitize user-supplied input that contains malicious scripts disguised using encoded URI schemes like `javascript:` or `data:`.

This vulnerability occurs when a web application fails to properly sanitize user input that contains doubled characters, allowing attackers to bypass filters and inject malicious scripts.

This vulnerability occurs when an application fails to properly filter or escape invalid characters within web identifiers like HTML tag names or URI schemes, allowing malicious sequences to pass through.

This vulnerability occurs when an application fails to properly sanitize user-supplied input that uses alternative methods to execute cross-site scripting (XSS) attacks.

This vulnerability occurs when an application builds a command string for execution by another component, but fails to properly separate or 'neutralize' the intended arguments. This allows an attacker to inject additional command-line arguments, options, or switches by including argument-separating characters (like spaces or dashes) in untrusted input.

SQL Injection occurs when an application builds a database query using untrusted user input without properly sanitizing it. This allows an attacker to insert malicious SQL code that the database executes, potentially letting them view, modify, or delete sensitive data.

This vulnerability occurs when an application builds an LDAP query using untrusted user input without properly sanitizing it. An attacker can inject special characters or commands to alter the query's logic, potentially gaining unauthorized access to, modifying, or extracting sensitive directory information.

XML Injection occurs when an application fails to properly validate or escape user-controlled input before including it in XML documents or queries. This allows attackers to inject malicious XML elements or syntax, potentially altering the document's structure, extracting sensitive data, or disrupting processing logic.

This vulnerability occurs when an application uses carriage return and line feed characters (CRLF) to structure data, like separating lines or records, but fails to properly sanitize these sequences from user-supplied input before processing.

This vulnerability occurs when an application builds executable code using unvalidated external input, such as user data. Because the application fails to properly filter or escape this input, an attacker can inject special characters or commands that alter the intended code's logic or syntax.

This vulnerability occurs when an application takes user input and passes it directly into a dynamic code execution function, like eval(), without properly sanitizing it. This allows an attacker to inject and execute arbitrary code within the application's context.

Static Code Injection occurs when an application incorporates unvalidated or improperly sanitized user input directly into a static, executable resource like a configuration file, template, or library. Because this input is saved and later executed, it allows an attacker to inject malicious code that becomes a permanent part of the application's logic.

This vulnerability occurs when a web application dynamically generates pages but fails to properly sanitize user-supplied input that could be interpreted as server-side include (SSI) commands, allowing an attacker to inject malicious directives.

This vulnerability occurs when a PHP application uses unvalidated or insufficiently restricted user input directly within file inclusion functions like require() or include().

This vulnerability occurs when an application accepts user input as a resource identifier (like a file path or port number) without proper validation, allowing an attacker to access or manipulate resources outside the intended scope.

This vulnerability occurs when an application defines multiple Struts validation forms with identical names. The framework then unpredictably selects only one form for validation, potentially bypassing intended security checks.

This vulnerability occurs in a Struts application when a validator form either completely omits a validate() method or includes one but fails to call super.validate() within it.

This vulnerability occurs in Apache Struts applications when a form bean class does not properly extend the framework's validation class. This bypasses the built-in Validator framework, leaving the application without structured input validation and open to various injection and data manipulation attacks.

This vulnerability occurs when a Struts application form contains an input field that lacks a corresponding validator, leaving it open to unverified user input.

This weakness occurs when a Java application, particularly one using the Struts framework, does not implement a structured input validation plugin like the Struts Validator. Skipping this framework forces developers to write custom validation logic, which is often error-prone and increases the risk of security flaws from improperly handled user input.

This vulnerability occurs when a Struts application contains validation form definitions that are no longer linked to any active form or action, leaving outdated security rules in the codebase.

In Apache Struts, every Action Form that processes user input must have a corresponding validation form configured. Missing this validation exposes the application to unvalidated data.

This vulnerability occurs when an application built with Apache Struts intentionally disables its built-in validation framework. By turning off the Struts Validator bean, developers remove critical automatic input filtering and custom validation rules, leaving the application unprotected against malicious or malformed data.

This vulnerability occurs when a Struts application's validation configuration file references form fields that no longer exist in the corresponding ActionForm class. This mismatch indicates outdated validation logic that can fail to properly check user input.

This weakness occurs when a Java application directly calls native code through the Java Native Interface (JNI), exposing the entire application to security risks present in that external code, even if Java itself is safe from those specific flaws.

This vulnerability occurs when an application processes XML data from an untrusted source without first validating its structure and content against a defined schema.

This vulnerability occurs when an application accepts user-supplied data and includes it directly in HTTP headers without properly filtering out carriage return (CR) and line feed (LF) characters. This allows an attacker to inject new headers or split a single HTTP response into two separate responses, corrupting the intended communication flow.

Process Control vulnerabilities occur when an application executes commands or loads libraries from an untrusted source or environment, allowing an attacker to run malicious code.

This vulnerability occurs when software incorrectly interprets or processes input data, leading to unintended and potentially harmful security consequences. The flawed interpretation can come from user-provided data, external systems, or other components.

This vulnerability occurs when an application builds a structured message—like a query, command, or request—for another component but fails to properly encode or escape user-supplied data. Because the output's structure isn't preserved, an attacker can inject malicious instructions that the receiving component will execute.

This vulnerability occurs when an application creates log entries using unvalidated external data, allowing attackers to inject malicious characters or commands that can corrupt log files, trigger parsing errors, or enable log injection attacks.

This vulnerability occurs when software fails to properly check the boundaries of an indexed resource, like an array, buffer, or file, before accessing it. This allows reading from or writing to memory locations outside the intended range.

This vulnerability occurs when software accesses a memory buffer but reads from or writes to a location outside its allocated boundary. This can corrupt adjacent data, crash the program, or allow attackers to execute arbitrary code.

This vulnerability occurs when a program copies data from one memory location to another without first verifying that the source data will fit within the destination buffer's allocated space.

A stack-based buffer overflow occurs when a program writes more data to a buffer located on the call stack than it can hold, corrupting adjacent memory and potentially hijacking the program's execution flow.

A heap-based buffer overflow occurs when a program writes more data to a memory buffer allocated in the heap than it can hold, corrupting adjacent memory structures. This typically involves buffers created with functions like malloc(), calloc(), or realloc().

A write-what-where condition occurs when an attacker can control both the data written and the exact memory location where it's written, often due to a severe memory corruption flaw like a buffer overflow.

A buffer underwrite, also known as buffer underflow, happens when a program writes data to a memory location before the official start of a buffer.

An out-of-bounds read occurs when software accesses memory outside the boundaries of a buffer, array, or similar data structure, reading data it wasn't intended to see.

This vulnerability occurs when a program reads data from a memory buffer using an index or pointer that points beyond the buffer's allocated boundary, accessing unintended memory locations.

A buffer under-read occurs when a program attempts to read data from a memory location positioned before the start of an allocated buffer.

A wrap-around error happens when a variable exceeds the maximum value its data type can hold, causing it to unexpectedly reset to a very small, negative, or undefined number instead of increasing further.

This vulnerability occurs when software uses unverified, external input to calculate or access an array index, without properly checking that the index points to a valid location within the array's bounds.

This vulnerability occurs when a program reads a structured data packet or message but fails to properly validate that the declared length field matches the actual amount of data provided.

This vulnerability occurs when a program miscalculates the amount of memory needed for a buffer, potentially leading to a buffer overflow that can crash the software or allow attackers to execute malicious code.

This vulnerability occurs when a program uses a format string from an untrusted, external source (like user input, a network packet, or a file) in a formatting function (e.g., printf, sprintf). An attacker can craft a malicious format string to read or write memory, potentially crashing the application or executing arbitrary code.

This vulnerability occurs when software incorrectly measures the length of strings containing multi-byte or wide characters, leading to buffer overflows, data corruption, or crashes.

This vulnerability occurs when an application accepts external input but fails to properly sanitize special characters or syntax that have specific meanings in the target interpreter or protocol. This allows attackers to inject control elements that alter how downstream components process the data.

This vulnerability occurs when an application fails to properly handle or sanitize delimiter characters within data inputs, allowing them to be misinterpreted by downstream systems.

This vulnerability occurs when an application fails to properly sanitize special characters that act as delimiters in data being passed between system components. Attackers can inject these characters to manipulate how downstream processes interpret command arguments or parameter lists.

This vulnerability occurs when an application fails to properly sanitize or escape special characters that act as data separators (delimiters) before passing that data to another system or component. An attacker can inject these characters to manipulate how the downstream process interprets the data structure.

This vulnerability occurs when an application fails to properly sanitize or escape special characters that function as record separators in data streams. When untrusted input containing these delimiters is passed to a downstream system, it can corrupt data structures, cause misinterpretation of records, or trigger unauthorized actions.

This vulnerability occurs when an application fails to properly sanitize or escape line break characters (like newline or carriage return) in user-supplied input before passing that data to another system or component.

This vulnerability occurs when an application fails to properly sanitize or validate special characters that act as section delimiters in data streams. When this unsanitized input is passed to another component, these delimiters can be misinterpreted, leading to incorrect data parsing or unintended behavior.

This vulnerability occurs when an application fails to properly sanitize input that contains special characters used as delimiters in expressions or commands. When this unsanitized input is passed to another component for processing, those characters can be misinterpreted, altering the intended logic or structure.

This vulnerability occurs when an application accepts external input but fails to properly handle special characters that downstream systems interpret as commands to stop processing data.

This vulnerability occurs when an application fails to properly validate or handle input that begins with special control characters or sequences, known as 'leaders.' Issues arise when a required leader is missing, malformed, or when too many leaders are present where only one is expected.

This vulnerability occurs when an application fails to properly validate or escape quote characters (like single ' or double " quotes) in user input. Attackers can inject these quotes to manipulate how the system interprets data, often breaking out of intended data fields to execute unauthorized commands or alter program logic.

This vulnerability occurs when an application fails to properly sanitize or escape special character sequences in user-supplied input before passing that data to another system or component. Attackers can inject escape, meta, or control sequences to manipulate how the downstream component interprets the data, often leading to command execution, data corruption, or unauthorized actions.

This vulnerability occurs when an application accepts user input and fails to properly sanitize characters that can be interpreted as comment markers (like /*, */, //, #, or <!--) before passing that data to another system component. This allows an attacker to inject malicious comments that can break data processing, alter logic, or expose sensitive information.

This vulnerability occurs when an application accepts user input containing macro symbols (like those used in templates or configuration files) and passes it along without properly sanitizing it. This allows attackers to inject malicious macro commands that get executed by downstream systems, potentially leading to data manipulation, system access, or other unintended behaviors.

This vulnerability occurs when an application accepts user input and fails to properly sanitize special characters that can trigger command or variable substitution before passing that data to another system component. This allows attackers to inject malicious substitutions that alter the system's intended behavior.

This vulnerability occurs when an application fails to properly sanitize or escape special characters that act as delimiters for variable names before passing data to another component. Attackers can inject these delimiters to manipulate how variables are interpreted.

This vulnerability occurs when an application fails to properly sanitize user-supplied input containing wildcard characters (like *, ?, or [ ]) before passing it to a command or function that interprets them as pattern-matching symbols.

This vulnerability occurs when an application fails to properly handle or sanitize whitespace characters in input before passing that data to another system component. This allows special whitespace elements to be interpreted incorrectly downstream, potentially altering how the data is processed.

This vulnerability occurs when an application fails to properly validate or neutralize the special characters that come in pairs to define boundaries, such as parentheses, brackets, quotes, or braces. Attackers can exploit this oversight to manipulate data structure, inject malicious code, or cause the application to crash.

This weakness occurs when an application receives data but fails to properly handle or remove NUL characters (\0) before passing that data to another system component.

This vulnerability occurs when an application fails to properly validate or neutralize special characters and control elements within user-supplied input. Without this filtering, attackers can inject these elements to manipulate the application's logic, leading to security breaches or system instability.

This vulnerability occurs when an application accepts external input but fails to properly sanitize leading special characters or commands before passing that data to another system component. This allows an attacker to inject unexpected instructions at the beginning of the data stream.

This vulnerability occurs when an application accepts external input but fails to properly sanitize multiple special characters or sequences at the beginning of that input before passing it to another system component. This allows an attacker to inject unexpected commands or data structures.

This vulnerability occurs when an application fails to properly sanitize or remove trailing special characters from user-supplied input before passing it to another system component. These leftover characters can trick the downstream parser into executing unintended commands or altering the data flow.

This vulnerability occurs when software accepts external input but fails to properly sanitize or incorrectly handles multiple trailing special characters or elements. When this unsanitized data is passed to another system component, these elements can be interpreted in harmful, unintended ways.

This vulnerability occurs when an application accepts data from a source but fails to properly sanitize internal control elements or metadata before passing it to another internal component. This can cause the downstream component to misinterpret the data and perform unintended actions.

This vulnerability occurs when an application accepts external input but fails to properly sanitize multiple internal control characters or delimiters before passing that data to another internal component. This can cause the downstream component to misinterpret the data and execute unintended commands.

This vulnerability occurs when software expects a specific delimiter, terminator, or other special marker in its input but fails to properly handle situations where that element is absent. The application may then misinterpret boundaries, leading to crashes, data corruption, or security breaches.

This vulnerability occurs when software receives data from another component but fails to properly process or validate unexpected special characters or control elements within that input.

This vulnerability occurs when software fails to correctly process input containing conflicting or mismatched special elements like characters, symbols, or reserved keywords.

This weakness occurs when software fails to properly end a string or array with the required null character or equivalent terminator.

This vulnerability occurs when software incorrectly transforms data between different formats, leading to corrupted or misinterpreted information that can break functionality or create security gaps.

This vulnerability occurs when software fails to correctly process input that arrives in a different character encoding than expected, allowing that input to bypass security checks or cause misinterpretation.

This vulnerability occurs when an application decodes the same piece of data twice in sequence. This double processing can bypass or neutralize security checks that happen after the first decode, leaving the system exposed.

This vulnerability occurs when software fails to correctly process input that contains multiple character encodings within the same data stream.

This vulnerability occurs when software fails to correctly process or interpret Unicode-encoded input, leading to security bypasses, data corruption, or unexpected behavior.

This vulnerability occurs when an application fails to correctly process URL-encoded (also known as percent-encoded or hex-encoded) input, either by double-decoding it, not decoding it at all, or inconsistently handling encoded characters across different security checks.

This vulnerability occurs when software fails to consistently handle uppercase and lowercase letters when checking or accessing resources, leading to unpredictable behavior and security gaps.

This vulnerability occurs when an application validates user input before applying security filters or data normalization. Attackers can exploit this order of operations by submitting specially crafted input that passes the initial validation but becomes malicious after the application's filters or canonicalization processes modify it.

This vulnerability occurs when a system checks user input for malicious content before standardizing its format, allowing specially crafted data to bypass security checks.

This vulnerability occurs when a system checks user input for validity before cleaning or filtering it. This flawed sequence allows malicious data to pass validation, only to be altered by later filters into a dangerous form.

This vulnerability occurs when an application's data filtering or transformation process incorrectly merges or simplifies information, producing a result that violates security rules. Essentially, safe input gets collapsed into a dangerous value.

This vulnerability occurs when an application's security filter uses an allowlist that is too broad, mistakenly permitting dangerous inputs that should have been blocked. The flawed assumption that everything on the list is safe creates a direct path for attackers to exploit the system.

This vulnerability occurs when a security filter or validation mechanism relies on a 'denylist'—a predefined list of forbidden inputs—but that list is missing critical entries. Attackers can bypass the protection by using variations or inputs the developers didn't anticipate.

This vulnerability occurs when a regular expression is written incorrectly, causing it to match or validate data in unintended and potentially dangerous ways.

This weakness occurs when a regular expression is too narrow, failing to detect all the dangerous or unexpected input values it was designed to catch.

This weakness occurs when software checks only part of a string or token to determine a match, instead of comparing the entire value. This incomplete validation can lead to incorrect security decisions.

This vulnerability occurs when software incorrectly assumes how data is structured in memory or within network packets, leading to unexpected behavior when those underlying layouts change.

Integer overflow or wraparound occurs when a calculation produces a numeric result that exceeds the maximum value a variable can hold. Instead of increasing as expected, the value wraps around to a very small or negative number, breaking the program's logic.

Integer underflow occurs when a subtraction operation results in a value smaller than the data type's minimum limit, causing the value to wrap around to a large, incorrect number.

An integer coercion error occurs when a program incorrectly converts, extends, or truncates a number between different data types, leading to unexpected values.

An off-by-one error occurs when a program incorrectly calculates a boundary, such as a loop counter or array index, by being one unit too high or too low. This often leads to buffer overflows, memory corruption, or unexpected program behavior.

This vulnerability occurs when a signed number from a smaller data type is moved or cast to a larger type, causing its sign bit to be incorrectly extended. If the original value is negative, this sign extension can fill the new, higher-order bits with '1's, leading to unexpectedly large positive values and causing logic errors, buffer overflows, or security bypasses.

This vulnerability occurs when a signed integer (which can hold negative values) is converted to an unsigned integer (which holds only non-negative values). If the original signed value is negative, the conversion produces a large, unexpected positive number instead of an error, breaking the program's logic.

This vulnerability occurs when a program takes an unsigned integer and converts it directly to a signed integer. If the original unsigned value is too large to fit within the signed type's positive range, the conversion results in an unexpected negative number, corrupting the data.

A numeric truncation error happens when a program converts a number to a smaller data type, cutting off its higher-order bits and corrupting the original value.

This vulnerability occurs when software processes data from another system without considering byte order (endianness), such as big-endian or little-endian. This mismatch can cause the program to misinterpret numbers or values, leading to incorrect calculations, crashes, or security flaws.

This weakness occurs when an application unintentionally reveals sensitive data to someone who shouldn't have access to it.

This vulnerability occurs when an application sends data to an external party, but accidentally includes sensitive information—like passwords, keys, or personal data—that the recipient should not be able to access.

This vulnerability occurs when an attacker uses statistical analysis on aggregated or anonymized data to uncover sensitive details about individuals, even when direct identifiers are removed.

This vulnerability occurs when an application responds differently to unauthorized users based on internal conditions. Attackers can observe these variations—like changes in error messages, timing, or system behavior—to infer sensitive information, such as whether a username exists, a password is incorrect, or a specific operation succeeded.

This vulnerability occurs when an application responds differently to similar requests, unintentionally leaking details about its internal state or logic to unauthorized users.

This vulnerability occurs when an application behaves differently in ways that unauthorized users can detect. These observable differences can reveal internal system logic, state information, or how the product varies from similar applications, providing attackers with valuable clues.

This vulnerability occurs when a system's internal steps or decisions become visible to an attacker because the system behaves differently at each stage. Instead of presenting a single, unified result, the product leaks information about its internal checks, allowing an attacker to map its logic and pinpoint weaknesses.

This vulnerability occurs when a system that should remain anonymous behaves differently than other products with the same purpose, allowing attackers to detect and identify it.

This vulnerability occurs when an application takes measurably different amounts of time to perform different operations, such as checking a password or processing a request. An attacker can observe these timing differences to learn sensitive information, like whether a username is valid or a cryptographic key guess is correct.

This vulnerability occurs when an application reveals sensitive details about its internal systems, user data, or environment within error messages shown to users.

This vulnerability occurs when an application detects a problem and generates its own error messages that accidentally expose sensitive system or user data.

This vulnerability occurs when an application triggers an error message from an external component—like a database, interpreter, or operating system—and that error reveals sensitive details about the system's internal workings, configuration, or data.

This vulnerability occurs when an application stores or transmits a resource containing sensitive data without properly cleaning it first, potentially exposing that information to unauthorized parties.

This vulnerability occurs when a system's data handling aligns with the developer's security rules but accidentally reveals information that other stakeholders—like users or administrators—consider confidential. Essentially, the developer's policy conflicts with the security expectations of the people who use or manage the product.

This vulnerability occurs when a process is started with sensitive data, such as passwords or API keys, passed directly in its command-line arguments or environment variables. Because this information is often visible to other processes on the system, it can be easily exposed.

This vulnerability occurs when developers embed sensitive data, such as passwords or API keys, within debugging statements like logs or console outputs, and fail to remove or disable this code before deploying to a live environment.

This vulnerability occurs when an application saves sensitive files, such as configuration data or private keys, inside the web server's publicly accessible directory. Without proper access restrictions, attackers can directly request and download these files.

This vulnerability occurs when an application saves sensitive files, such as configuration or user data, within the directory served by an FTP server without proper access restrictions. This misconfiguration can allow unauthorized users to download these files directly.

This weakness occurs when an application fails to log critical security events or records them inaccurately, which can misguide security decisions and hinder incident investigation.

This vulnerability occurs when a system shortens or cuts off security-critical data during display, logging, or processing. This truncation can hide the true details of an attack, making it harder to detect, investigate, and respond to threats.

This vulnerability occurs when an application fails to capture or present crucial security-related details, such as the origin of a request or the specifics of a security event. Without this information, developers and security teams cannot effectively trace attacks or validate whether an operation is legitimate.

This vulnerability occurs when a system logs or reports security-critical events using a nickname or alias for a component, instead of its official, unique identifier.

This vulnerability occurs when a system releases a resource like memory or a file for reuse but fails to erase the sensitive data it previously contained. The old information remains accessible when the resource is allocated to a new process or used in a different context.

This vulnerability occurs when software fails to properly reject or process input that doesn't follow the expected format or structure, often leading to crashes or unexpected behavior.

This vulnerability occurs when software fails to correctly process situations where input contains too few values, too many values, or undefined values for expected parameters, fields, or arguments.

This vulnerability occurs when software fails to properly check for or handle missing data values. It happens when a parameter, field, or argument name is provided, but its corresponding value is empty, blank, or null, and the system doesn't manage this absence safely.

This vulnerability occurs when software receives more input values than it was designed to handle, and fails to properly manage or reject the excess data.

This vulnerability occurs when software fails to properly check for or handle undefined, null, or unsupported values passed to parameters, configuration fields, or function arguments. Instead of rejecting or safely converting these values, the system proceeds with an unexpected state, often leading to crashes or security flaws.

This vulnerability occurs when software fails to correctly process input that contains an unexpected number of parameters, missing fields, or undefined arguments. It often leads to crashes, unexpected behavior, or security bypasses.

This vulnerability occurs when a function or method receives fewer arguments than it expects. The function will still attempt to process its expected number of parameters, which can lead to reading undefined, stale, or arbitrary values from the program's memory or stack, causing crashes or unexpected behavior.

This vulnerability occurs when a system fails to properly manage situations where it receives more parameters, fields, or arguments with the same name than it was designed to handle.

This vulnerability occurs when software fails to properly manage input parameters, field names, or arguments that it doesn't recognize or support. Instead of rejecting or safely ignoring the undefined input, the system may behave unpredictably, leading to errors or security issues.

This vulnerability occurs when an application fails to properly validate, sanitize, or interpret the complex internal parts of structured data, such as file headers, network packet fields, or document metadata.

This vulnerability occurs when software fails to properly process or validate data structures that are missing required components or are only partially formed.

This vulnerability occurs when a system fails to properly manage or validate data elements that are missing required parts or are only partially defined.

This vulnerability occurs when a system fails to properly manage situations where related data structures or elements should match but are inconsistent.

This vulnerability occurs when software fails to properly validate or safely process data that arrives in an unexpected format. For example, the system might expect a numeric input but receives text instead, leading to crashes, errors, or security issues.

This vulnerability occurs when code uses functions that are inherently unsafe and cannot be reliably secured, posing a direct risk to application stability and security.

This vulnerability occurs when a program creates a chroot jail but fails to change its current working directory afterward. Because the process's working directory remains outside the jail, attackers can use relative paths to access files and directories that should be restricted.

Using realloc() to resize buffers containing secrets like passwords or keys can leave that sensitive data exposed in memory, as the original data is not securely erased.

This vulnerability occurs when a J2EE application handles database connections directly instead of using the container's built-in connection management system.

This vulnerability occurs when a J2EE application creates network sockets directly, bypassing the container-managed communication framework provided by the platform.

This vulnerability occurs when a function throws an error or exception, but the calling code does not have a proper handler to catch and manage it.

This vulnerability occurs when software runs with higher permissions than it actually needs to perform its tasks. This excessive privilege creates security risks by opening doors to new attacks or making existing weaknesses more dangerous.

This vulnerability occurs when a program fails to verify the result of a function or method call, allowing it to continue execution without detecting errors or unexpected conditions.

This vulnerability occurs when a program misinterprets or improperly validates the return value from a function, causing it to miss critical error states or unexpected conditions.

This vulnerability occurs when an application stores user passwords as readable text instead of using secure, one-way hashing. This insecure practice exposes credentials in memory, files, or databases where attackers can easily retrieve them.

This vulnerability occurs when an application stores user passwords in a format that can be easily reversed or decrypted back to their original plaintext form. This practice, often called storing 'recoverable' passwords, defeats the core purpose of password protection. It allows anyone with access to the stored data—including attackers who breach the system or even malicious insiders—to obtain and reuse the actual passwords on other accounts, offering no real security advantage over storing them in plain text.

This vulnerability occurs when a configuration file, script, or application uses an empty string as a password, effectively disabling authentication for a service or account.

This vulnerability occurs when an application embeds a password directly into its source code or configuration files. This hard-coded secret is then used either to authenticate incoming users or to connect to external services and databases.

This vulnerability occurs when an application stores sensitive passwords directly within a configuration file, making them easily readable to anyone with access to that file.

Using simple encoding like Base64 to hide a password provides no real security, as it can be easily reversed.

This vulnerability occurs when a system lacks password expiration policies, allowing users to keep the same password indefinitely.

The system enforces password changes, but the time allowed between changes is excessively long, weakening security.

This vulnerability occurs when a system mistakenly grants a user, process, or entity a specific permission or privilege they should not have. This error creates an unintended level of access, allowing the actor to perform actions beyond their intended authority.

This vulnerability occurs when a system grants a user, role, or process a specific permission that can be misused to perform dangerous, unintended actions. The permission itself is correctly assigned, but its scope is too broad or allows for unsafe operations.

Privilege chaining occurs when an attacker combines two separate permissions or capabilities, neither of which is dangerous on its own, to perform a harmful action that neither permission should individually allow.

This vulnerability occurs when an application fails to correctly manage user permissions, allowing someone to perform actions or access data beyond their intended authority.

This vulnerability occurs when an application fails to properly manage user permissions while moving between different security contexts, potentially allowing unauthorized actions.

This vulnerability occurs when a system or process fails to reduce its elevated permissions before transferring control of a resource to a less-privileged user or component.

This vulnerability occurs when software fails to reduce its elevated system privileges after completing a sensitive operation, leaving it with unnecessary and dangerous access rights.

This vulnerability occurs when an application tries to lower its system privileges but fails to verify that the operation was successful.

This vulnerability occurs when an application fails to properly manage situations where it lacks the necessary permissions to execute an action. This flawed handling can lead to crashes, data corruption, or unintended security bypasses.

This vulnerability occurs when software installation scripts set overly permissive file or directory access rights by default. Instead of restricting write access to authorized users or processes, the installation allows unintended actors to modify, delete, or corrupt critical application files.

This vulnerability occurs when an application sets default file or directory permissions that are too permissive, and these insecure settings are automatically passed down to new files or objects the program creates.

This vulnerability occurs when a software product copies or extracts files while unintentionally preserving insecure permissions from their original source, such as an archive, without the user's knowledge or consent.

This vulnerability occurs when a running application incorrectly changes an object's access permissions, overriding the security settings that a user or administrator intentionally configured.

This vulnerability occurs when a system fails to properly manage situations where it lacks the necessary permissions to perform an action or access a resource. This flawed handling can force the application into unintended states or error paths, potentially leading to crashes, data corruption, or security bypasses.

This vulnerability occurs when a system fails to correctly maintain file or object permissions during operations like copying, sharing, or restoring data. As a result, these resources can end up with weaker, more permissive security settings than the original owner intended.

This vulnerability occurs when a system incorrectly assigns or fails to verify which user or process rightfully controls a specific object or resource.

This vulnerability occurs when an application fails to confirm that a user has legitimate ownership rights to a sensitive resource before allowing them to perform actions on it.

The software fails to properly limit who can access a resource, allowing unauthorized users or systems to interact with it.

This vulnerability occurs when an application fails to properly verify whether a user has permission to access specific data or perform certain actions before allowing the request.

This vulnerability occurs when an application incorrectly handles user accounts, roles, or group memberships, leading to improper access control.

Improper Authentication occurs when a system fails to properly verify a user's claimed identity, allowing access without sufficient proof of who they are.

This vulnerability occurs when a system has a primary login requirement, but attackers can find an unprotected backdoor or alternative route that completely bypasses those checks.

This vulnerability occurs when a system checks access based on a resource or user name, but fails to account for all the different names or aliases that could refer to the same entity, allowing attackers to bypass authentication.

This weakness occurs when an application's authentication system can be tricked into accepting forged or manipulated credentials, allowing unauthorized access without proper verification.

This vulnerability occurs when a system uses a client's IP address as the sole or primary method to verify their identity.

This vulnerability occurs when a web application uses the HTTP Referer header as a sole or primary method for authentication or authorization decisions. Since this header is entirely controlled by the user's browser or client and can be easily forged, it provides no reliable security.

This vulnerability occurs when an attacker can intercept and record legitimate authentication traffic, then replay it later to gain unauthorized access. The system accepts the replayed data as valid, effectively bypassing normal authentication checks.

This vulnerability occurs when an application fails to properly verify the authenticity of a digital certificate, or performs the verification incorrectly, allowing untrusted connections to appear legitimate.

This vulnerability occurs when software fails to properly validate the entire certificate chain back to a trusted root authority. This mistake can cause the system to incorrectly trust a certificate and the resource it represents, creating a security gap.

This vulnerability occurs when an application accepts a valid SSL/TLS certificate without properly verifying that it actually belongs to the specific host it's connecting to. Even a correctly signed certificate from a trusted authority can be misused if the hostname check is missing or flawed.

This vulnerability occurs when an application fails to properly check if a digital certificate has expired, potentially trusting certificates that are no longer valid due to their age.

This vulnerability occurs when an application fails to properly verify whether a security certificate has been revoked, potentially allowing it to accept and use a compromised or untrustworthy certificate.

This vulnerability occurs when a system fails to properly verify who is on the other end of a communication link or to secure the channel itself. This allows an unauthorized third party to access or manipulate the communication as if they were a legitimate participant.

A reflection attack is a flaw in mutual authentication protocols that allows an attacker to impersonate a legitimate user without knowing the secret key. This happens when an attacker can bounce, or 'reflect,' a server's own challenge back to it using a second connection, tricking the system into granting access.

This vulnerability occurs when an authentication system incorrectly treats certain data as unchangeable, when in fact an attacker can manipulate it to bypass login or verification checks.

This weakness occurs when a developer implements a standard authentication algorithm, but makes critical mistakes in the code that cause it to function incorrectly.

This vulnerability occurs when a software authentication process omits a required step, weakening its overall security.

This vulnerability occurs when a system's core authentication logic is technically correct, but an attacker can completely bypass it by exploiting a separate, more fundamental flaw in the application.

This vulnerability occurs when a software feature that performs a sensitive action or uses significant system resources does not verify the user's identity before executing. Attackers can exploit this to trigger critical functions without any credentials.

This vulnerability occurs when an application fails to properly limit how many times someone can attempt to log in or verify their identity in rapid succession, allowing attackers to systematically guess credentials.

Relying solely on single-factor authentication, like a password, exposes systems to significant security risks because it depends on only one type of proof for verifying a user's identity.

This weakness occurs when an application relies solely on password-based authentication as its main security gate. This single-factor approach is inherently vulnerable to a range of attacks that can compromise user accounts.

This vulnerability occurs when an application stores or sends sensitive information without first encrypting it, leaving the data exposed.

This vulnerability occurs when an application stores sensitive data like passwords, credit card numbers, or personal information in plain text, without any encryption. This unsecured data is kept in files, databases, caches, or logs that could be accessed by unauthorized users or systems.

This vulnerability occurs when an application writes sensitive data, such as passwords or personal information, directly to a file or disk without using encryption.

This vulnerability occurs when an application saves sensitive data, like passwords or keys, as plain text in the Windows Registry.

This vulnerability occurs when an application directly stores sensitive data, like session tokens or personal details, in a browser cookie without encryption.

This vulnerability occurs when an application stores sensitive data, such as passwords or encryption keys, in memory without any form of encryption or protection.

This vulnerability occurs when an application stores sensitive data, such as passwords or personal information, in plain text within its graphical user interface (GUI) elements.

This vulnerability occurs when an application embeds sensitive information, like passwords or keys, directly within its executable code without encryption.

This vulnerability occurs when an application sends sensitive data, such as passwords or personal information, over a network connection without using encryption. Attackers can easily intercept and read this unprotected data as it travels.

This vulnerability occurs when an application embeds a fixed, unchangeable cryptographic key directly within its source code or configuration files.

This vulnerability occurs when a system establishes a cryptographic key with another party without first confirming that party's true identity.

This vulnerability occurs when a cryptographic nonce or key pair is reused, compromising the security of the encrypted data.

This vulnerability occurs when an application continues to use a cryptographic key or password after its designated expiration date. Doing so dramatically increases the security risk by giving attackers more time to discover or crack the key.

This vulnerability occurs when a software implementation skips a critical step in a cryptographic process, resulting in security that is significantly weaker than the intended algorithm provides.

This vulnerability occurs when an application protects sensitive information with encryption, but the specific algorithm or key strength used is too weak to withstand modern attack methods.

The software relies on a cryptographic algorithm or protocol that is either fundamentally flawed or considered too weak by modern security standards.

This vulnerability occurs when software uses a hashing algorithm that is cryptographically weak, allowing attackers to feasibly reverse the hash to find the original input, find a different input that creates the same hash, or discover collisions where two inputs produce identical hash values.

This vulnerability occurs when software uses a predictable or reused Initialization Vector (IV) with Cipher Block Chaining (CBC) mode encryption. Predictable IVs undermine the security of CBC, making encrypted data vulnerable to dictionary and chosen-plaintext attacks, especially when the same key is used multiple times.

This vulnerability occurs when an application uses random values that are not sufficiently unpredictable in security-sensitive operations, making them easier for attackers to guess or calculate.

This vulnerability occurs when a system's random number generator or algorithm lacks sufficient unpredictability, creating patterns or predictable outputs that are easier for attackers to guess.

This vulnerability occurs when a Pseudo-Random Number Generator (PRNG) doesn't have enough randomness (entropy) to start with, or isn't using enough during operation. This makes its outputs predictable, undermining both system stability and security.

This vulnerability occurs when a system fails to properly manage the limited or unpredictable output rate of a true random number generator (TRNG), potentially causing failures, delays, or weakened security.

This vulnerability occurs when a system uses a random number generator that produces too few possible values. Attackers can easily predict or guess these values through brute force attacks.

This vulnerability occurs when a Pseudo-Random Number Generator (PRNG) is used, but its initial seed value is not handled securely or predictably, compromising the randomness of its output.

This vulnerability occurs when a Pseudo-Random Number Generator (PRNG) is repeatedly initialized with the same starting seed value.

This vulnerability occurs when a Pseudo-Random Number Generator (PRNG) uses an easily guessable starting value, like the current system time or a process ID, to begin its sequence.

This vulnerability occurs when software uses a pseudo-random number generator (PRNG) that is not cryptographically strong for security-sensitive operations, such as generating keys, tokens, or initialization vectors.

This vulnerability occurs when a Pseudo-Random Number Generator (PRNG) uses a seed that has too few possible values, making it easy for an attacker to guess through brute force.

This vulnerability occurs when a system creates numbers or identifiers that are too easy to guess, undermining security mechanisms that rely on unpredictability.

This vulnerability occurs when an attacker can guess or deduce sensitive values, like random numbers or identifiers, by observing predictable system or network characteristics such as timestamps, process IDs, or other public information.

This vulnerability occurs when a system uses a predictable sequence for generating values, allowing an attacker to accurately guess future numbers by analyzing past ones.

This vulnerability occurs when a system's random number generator produces values that, after observing previous outputs, allow an attacker to predict a limited range for the next value.

This vulnerability occurs when code uses a fixed, unchanging value (like a hardcoded string, number, or reference) in a situation where that value should actually be flexible and adapt to different runtime conditions or environments.

This vulnerability occurs when an application fails to properly check where data comes from or confirm its legitimacy, allowing untrusted or forged information to be processed as valid.

This vulnerability occurs when an application fails to properly confirm the true origin of incoming data or communication, allowing attackers to spoof their source.

This vulnerability occurs when an application fails to properly check the digital signature on data, or skips the verification step entirely, allowing tampered or forged information to be accepted as legitimate.

This vulnerability occurs when a system has access to multiple sources for the same critical data, but it chooses to rely on the less secure or less trustworthy one. This creates a security gap because the system ignores better-protected alternatives that offer stronger verification or are harder for attackers to compromise.

This vulnerability occurs when a system processes both trusted and untrusted data together, but fails to separate them. The application incorrectly treats all incoming data—including the untrusted portion—with the same level of trust as the legitimate data.

This vulnerability occurs when an application uses a reverse DNS lookup on an IP address to get a hostname and then uses that hostname for a security decision—like access control or logging—without verifying that the IP address actually belongs to that hostname.

This vulnerability occurs when an application fails to properly differentiate between different types of data or objects, leading to unintended and insecure behavior.

Cross-Site Request Forgery (CSRF) happens when a web application cannot reliably tell if a user actually intended to submit a request, allowing an attacker to trick a user's browser into performing unwanted actions on their behalf.

This vulnerability occurs when a system uses a communication protocol that lacks built-in integrity verification, such as a checksum or cryptographic hash, to detect if data has been altered or corrupted during transmission.

This vulnerability occurs when software fails to properly check the integrity of data by validating its checksum or hash value. Without this verification, the application cannot reliably detect if information has been altered, corrupted, or tampered with during storage or transmission.

This vulnerability occurs when a software interface fails to alert users before they perform a risky action. Without clear warnings, users can be more easily misled into taking steps that harm their system or data.

This vulnerability occurs when a software application does present a warning to a user before a risky action, but the warning is designed or placed in a way that makes it too easy to miss, ignore, or accidentally dismiss.

This vulnerability occurs when software fails to correctly implement one or more critical security checks required by a standard protocol, algorithm, or security technique.

This vulnerability occurs when an application fails to adequately protect sensitive personal data, allowing access to individuals who either lack proper authorization or haven't provided necessary consent for its use.

This vulnerability occurs when software blindly trusts system event data without verifying its source, allowing attackers to spoof events and manipulate application behavior.

A race condition occurs when multiple processes or threads access a shared resource simultaneously without proper coordination, creating a timing window where the resource's state can be unexpectedly altered, leading to unpredictable behavior or security vulnerabilities.

This vulnerability occurs when a program checks a file's status before using it, creating a brief window where an attacker can replace that file with a malicious link. This causes the program to follow the link and access an unintended, potentially dangerous location.

A signal handler race condition occurs when a program's signal handling routine is vulnerable to timing issues, allowing its state to be corrupted through asynchronous execution.

This vulnerability occurs when two or more threads within the same application access and manipulate a shared resource (like a variable, data structure, or file) without proper synchronization. Because the threads can execute in an unpredictable order, they can corrupt the resource's state, leading to crashes, incorrect calculations, or data loss.

This vulnerability occurs when a program verifies a resource's state (like a file's permissions or existence) but then uses it after that state has already changed. The gap between checking and using creates a race window where an attacker can manipulate the resource, causing the program to operate on invalid or malicious data.

This vulnerability occurs when an application switches between different security contexts (like privilege levels or domains) using a series of steps that can be interrupted. An attacker can exploit the timing gap during this switch to trick the application into performing actions with the wrong permissions or resources.

A divide-by-zero error occurs when software attempts to perform a division operation where the denominator is zero.

This vulnerability occurs when software only verifies a certificate's revocation status once, then continues to trust it for subsequent privileged actions without re-checking. This allows operations to proceed even if the certificate is revoked later.

This vulnerability occurs when an application fails to accurately track its own operational state. The system incorrectly assumes it's in one mode or condition when it's actually in another, leading to security-critical actions being performed with the wrong assumptions.

This vulnerability occurs when a function receives a direct reference to mutable data, such as an object or array, instead of a safe copy of that data.

This vulnerability occurs when a method directly returns a reference to its internal mutable data, allowing untrusted calling code to modify that data unexpectedly.

This vulnerability occurs when an application creates temporary files with insecure permissions or in predictable locations, allowing attackers to read, modify, or delete sensitive data.

This vulnerability occurs when a program creates a temporary file but sets its file permissions too loosely, allowing other users or processes on the system to read, modify, or delete the file.

This vulnerability occurs when an application creates a temporary file in a directory that is too permissive, allowing unauthorized users or processes to see, access, or manipulate the file.

This vulnerability occurs when a J2EE application directly calls System.exit(), which forcibly terminates the entire application server process, not just the application itself.

Creating or managing threads directly within a J2EE application is a risky practice that violates the platform's standards and often leads to unstable applications.

Session fixation occurs when an application authenticates a user without first destroying the previous session ID. This allows an attacker who knows that session identifier to hijack the user's authenticated session.

A covert timing channel is a security flaw where an attacker can deduce secret information by observing how long certain operations take to execute. Instead of directly reading data, they analyze timing variations in system behavior to infer protected details.

This vulnerability occurs when a program uses a fixed symbolic name (like a constant or identifier) to refer to an object, but that name can later point to a different, unintended object during execution.

This weakness occurs when software successfully identifies an error condition but then fails to take any meaningful action to address it. The error is detected but ignored, leaving the system in an inconsistent or vulnerable state.

This vulnerability occurs when a program fails to properly check or handle error conditions, such as exceptions or return codes. By ignoring these failures, the software can enter an unexpected state that attackers might exploit, often without any logging or user notification.

This vulnerability occurs when a system fails to properly signal that an error has happened. Instead of returning a clear error code, status, or exception, the software continues as if nothing went wrong, leaving other components unaware of the failure.

This vulnerability occurs when a function returns an inaccurate status code or value that misrepresents the actual outcome of an operation. This false signal can cause the application to behave in unexpected and potentially insecure ways.

This vulnerability occurs when software fails to properly validate the full range of possible return values from a function or system call. While a returned value might be technically valid for that operation, the application doesn't anticipate or handle it correctly, leading to unexpected behavior.

Using a try-catch block for NullPointerException as a substitute for proper null checks is an anti-pattern. This approach masks the root cause of null pointer dereferences instead of preventing them, leading to unstable and difficult-to-debug code.

This weakness occurs when code catches a generic exception type like 'Exception' or 'Throwable', which can hide specific errors and create insecure error handling logic.

This vulnerability occurs when a method is declared to throw an overly broad exception type, such as a generic 'Exception' or 'Throwable'. This practice masks the specific error conditions that can occur, making it difficult for calling code to handle failures appropriately.

This vulnerability occurs when an application fails to properly manage a finite resource, allowing an attacker to exhaust it and cause a denial of service.

This vulnerability occurs when a program allocates memory but fails to properly release it after it's no longer needed, causing a gradual accumulation of unused memory that can't be reclaimed by the system.

This vulnerability occurs when an application unintentionally exposes internal resources, like files, memory, or database connections, to unauthorized users or systems. Essentially, it's a type of resource leak where sensitive assets cross a security boundary.

This vulnerability occurs when a parent process launches a child process without first closing sensitive file descriptors. The child process inherits these open handles, potentially gaining unauthorized access to files, sockets, or other resources it shouldn't be able to interact with.

This vulnerability occurs when a program fails to properly close or release a system resource—like a file handle, database connection, or memory block—after it's no longer needed, preventing its reuse.

This vulnerability occurs when a system allows an attacker to trigger a disproportionate amount of resource consumption—like CPU, memory, or bandwidth—with minimal effort on their part. The attacker's small input causes a large, inefficient output, creating an unfair 'asymmetric' advantage.

This vulnerability occurs when a system fails to properly limit the amount of network traffic it can generate in response to a request, allowing an attacker to abuse it to send a disproportionately large volume of data.

This vulnerability occurs when a software component uses an algorithm with poor worst-case performance. An attacker can exploit this by providing specially crafted input that forces the algorithm into its slowest possible execution path, leading to severe performance degradation or denial of service.

This vulnerability occurs when a system allows a user to trigger a resource-intensive operation before verifying their identity or checking their permissions.

This vulnerability occurs when software fails to safely process highly compressed data, where a small input file can trigger the creation of an extremely large amount of data during decompression, overwhelming system resources.

This vulnerability occurs when a system's resource pool is too small to handle maximum usage. Attackers can exploit this by making a high volume of requests, consuming all available resources and blocking legitimate users.

This vulnerability occurs when a system correctly checks for a lock's existence, but an unauthorized external actor can control or influence that lock.

This vulnerability occurs when an application fails to properly lock a shared resource, such as a file or memory location, before performing operations that require exclusive access.

This vulnerability occurs when software fails to verify that a proper synchronization lock is active before accessing or modifying a shared resource, potentially leading to race conditions and data corruption.

A double free vulnerability occurs when a program mistakenly calls the 'free()' function twice on the same block of memory.

Use After Free happens when a program continues to use a pointer to a memory location after that memory has been freed. This can lead to unpredictable behavior, crashes, or security vulnerabilities because the freed memory may have been reallocated for a different purpose.

This vulnerability occurs when an application exposes a privileged administrative interface or restricted functionality through a primary channel (like a specific port, endpoint, or protocol) without implementing adequate security controls to protect it.

This vulnerability occurs when an application secures its main communication path but leaves a backup or alternative channel with weaker or no protection.

A race condition occurs when an application opens a secondary communication channel intended for an authorized user, but fails to secure it, allowing other actors to potentially access it first.

This vulnerability, often called a 'Shatter' attack, occurs when a Windows application running with high privileges accepts messages from the Windows messaging system without verifying their source. This allows a less-privileged or malicious application to send commands directly to the privileged application, potentially hijacking its functionality.

This vulnerability occurs when an application fails to secure every possible route a user could take to reach sensitive features or data, leaving backdoors or unintended access points open.

This vulnerability occurs when a web application fails to verify user permissions for every protected page, file, or API endpoint, allowing attackers to access them directly.

This vulnerability occurs when an application relies on an external search path, provided by a user or environment, to find and load critical resources like executables or libraries. Because the application does not fully control this path, an attacker can manipulate it to point to malicious files.

This vulnerability occurs when an application searches for critical files like libraries or executables using a predefined list of directories, but one or more of those directories can be manipulated by an unauthorized user.

This vulnerability occurs when a program uses a file path or command that contains spaces and is not enclosed in quotes. The operating system may misinterpret where the executable file is located, potentially allowing an attacker to run a malicious program with higher privileges.

This vulnerability occurs when a system incorrectly assigns or routes an object to the wrong processing component.

This vulnerability occurs when a software component lacks the necessary code to properly handle an error or unexpected event.

This vulnerability occurs when a program's signal handler, which shares resources like global variables with other handlers, can be interrupted and re-entered before it finishes its work. The program fails to block other signals during this sensitive operation, leaving shared state vulnerable to corruption.

This vulnerability occurs when a web application stores unprocessed files—like configuration scripts or raw source code—in publicly accessible directories using file extensions the server doesn't recognize.

This vulnerability occurs when an application accepts file uploads without properly restricting the file types, allowing attackers to upload and execute malicious files on the server.

This weakness occurs when individually secure components interact in unexpected ways within a larger system, creating new security flaws that weren't present in isolation.

An interpretation conflict occurs when two systems process the same data or sequence of events differently, leading one system to make incorrect decisions based on its flawed understanding of the other's state.

This vulnerability occurs when a security product, proxy, or monitoring system sits between endpoints but lacks a full understanding of what those endpoints can do or their current state. Because it's working with incomplete information, it can make wrong decisions, allowing malicious traffic to pass or incorrectly blocking legitimate requests.

This vulnerability occurs when a component's behavior unexpectedly changes after an update or when deployed to a different environment, and the systems or users depending on it are unaware of and cannot manage this change.

This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's actual behavior deviates from its promised specification, leading to unpredictable results.

A confused deputy vulnerability occurs when a system receives a request from a client and forwards it to an external destination without properly identifying the original source. This makes the system appear to be the originator of the request, effectively turning it into an unintended proxy for the client.

This weakness occurs when a proxy, firewall, or other intermediary HTTP agent interprets a malformed HTTP request or response differently than the final destination server or client. This inconsistency allows an attacker to craft messages that bypass the intermediary's security checks.

This vulnerability occurs when a user interface incorrectly displays a security feature as active or properly configured, misleading users into believing they are protected when they are not.

This vulnerability occurs when a user interface displays a security feature as active and functional, but the underlying code that powers it is either missing or disabled. Users receive visual confirmation that a protection is in place, creating a false sense of security.

This vulnerability occurs when a user interface (UI) includes outdated or deprecated features, but fails to alert users about their obsolete status. This can mislead users into relying on functionality that may be broken, unsupported, or pose a security risk.

This vulnerability occurs when a user interface (UI) element or command performs a different, unintended action than what the user requested, potentially leading to security bypass, data corruption, or unexpected system behavior.

This vulnerability occurs when a user interface can interpret the same input in multiple ways, but automatically chooses a less secure option without warning the user.

This vulnerability occurs when a user interface fails to accurately display or highlight crucial information, potentially misleading users about the true state of the system or the source of data. Attackers exploit this weakness to trick users into performing unintended actions, often as part of phishing campaigns or other deception-based attacks.

This vulnerability occurs when software sets an internal variable to an insecure or unnecessarily weak default value during initialization, rather than using the most secure option available.

This vulnerability occurs when an application sets up its critical internal variables or storage systems using data from untrusted, external sources that an attacker could control.

This vulnerability occurs when software continues to run as normal after encountering a critical security failure during its startup process. Instead of halting or entering a safe mode, the application proceeds with weakened or missing security controls, leaving it exposed.

This vulnerability occurs when a program uses a variable before giving it a starting value, causing the software to rely on unpredictable data left over in memory.

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.

This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they are no longer needed.

This vulnerability occurs when a program fails to properly restore its state or release resources after an exception is thrown, leaving the application in an inconsistent or unexpected condition.

This vulnerability occurs when an associative list (alist) contains duplicate keys, which can cause unexpected behavior when software incorrectly handles or interprets these duplicates.

This vulnerability occurs when a program accidentally removes or corrupts a special marker used to define the boundaries of a data structure, leading to logic errors and unexpected behavior.

This vulnerability occurs when a program unintentionally adds or modifies a special marker, known as a sentinel, within a data structure, leading to critical logic errors.

This vulnerability occurs when a function returns a memory pointer that points outside the expected buffer range, potentially exposing unrelated memory or causing crashes.

This vulnerability occurs when a developer uses the sizeof() operator on a pointer variable instead of the data it points to, leading to incorrect size calculations and potential buffer overflows or underflows.

This vulnerability occurs when a programmer incorrectly accounts for pointer arithmetic in C or C++, causing the program to access unintended memory locations. The core issue is forgetting that adding an integer to a pointer automatically scales that integer by the size of the data type it points to.

This vulnerability occurs when a program calculates a size or offset by subtracting two memory pointers, but the pointers point to locations in different memory blocks, leading to an incorrect and potentially dangerous result.

This vulnerability occurs when an application uses unvalidated external input, like a URL parameter or form field, to dynamically decide which class to load or which method to execute via reflection. An attacker can manipulate this input to force the application to load unexpected, potentially malicious code.

This vulnerability occurs when an application fails to protect data it assumes cannot be changed, allowing an attacker to alter it.

This vulnerability occurs when a web application incorrectly trusts data that appears to be fixed or hidden from the user, such as values in hidden form fields, cookies, or URL parameters. Because this data is actually controllable by the client, attackers can modify it to bypass security checks or corrupt application logic.

This vulnerability occurs when a PHP application fails to properly validate or sanitize variables that originate from outside the application, such as HTTP query strings, cookies, or POST data. Attackers can exploit this to inject unexpected values, altering the program's logic and security controls.

This vulnerability occurs when code relies on a function whose behavior changes across different operating systems or versions, leading to unpredictable security risks when the software runs in an unexpected environment.

This API function exhibits unpredictable or undefined behavior when its control parameter is not set to the exact, required value.

This vulnerability occurs when a program attempts to access or manipulate memory using a pointer that is set to NULL, causing a crash or unexpected behavior.

This vulnerability occurs when code relies on deprecated or obsolete functions, indicating outdated practices and insufficient maintenance that can introduce security gaps.

This vulnerability occurs when code with multiple conditional branches, like a switch statement, lacks a default case to handle unexpected values.

This vulnerability occurs when a signal handler in your code calls a function that is not safe to re-enter. If that function is interrupted and called again before it finishes, it can corrupt memory and crash your program or create security weaknesses.

This vulnerability occurs when a developer mistakenly uses the wrong operator in their code, leading to unintended and potentially insecure logic.

This flaw occurs when a developer accidentally uses the assignment operator (=) instead of the comparison operator (== or ===). The code assigns a value when it was meant to check for equality, which fundamentally changes the program's logic.

This vulnerability occurs when a developer accidentally uses a comparison operator (like '==') where an assignment operator (like '=') was intended, creating a logic error instead of setting a value.

This vulnerability occurs when a developer fails to use explicit braces or delimiters to group multiple statements within a block, leading to unexpected program logic.

This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code execution 'falls through' and unintentionally runs the logic for subsequent cases, leading to unexpected behavior.

This vulnerability occurs when an application determines an object's trustworthiness or behavior solely by checking its class name. Since multiple classes can share identical names across different packages or classloaders, this comparison can lead to using the wrong, potentially malicious, class.

This weakness occurs when a Java application mistakenly treats package-level access as a security boundary, assuming it can prevent unauthorized access to code.

This vulnerability occurs when an application fails to properly isolate data between different user sessions, allowing information from one user's session to leak into another's.

This vulnerability occurs when software is deployed to production with debugging or diagnostic features still enabled and accessible.

This vulnerability occurs when a class implements a public clone() method without declaring it final. This allows attackers to create copies of objects without invoking their constructors, potentially leaving the cloned object in an inconsistent or insecure state.

Using inner classes to handle sensitive data can unintentionally expose that data because of how Java compiles them. The compiler transforms inner classes into separate, package-visible classes, which can bypass the intended private access restrictions.

This vulnerability occurs when a security-sensitive variable is declared as public but not marked as final, allowing untrusted code to unexpectedly change its value after initialization.

This vulnerability occurs when an application fetches and runs code from an external source—like a remote server or CDN—without properly verifying where it came from or ensuring it hasn't been tampered with.

This vulnerability occurs when a public method directly returns a reference to a private, internal data structure. Because the reference is live, external callers can bypass intended controls and modify the data unexpectedly, corrupting the application's state.

This vulnerability occurs when a developer stores sensitive data in a private array, but then assigns a publicly accessible reference to that same array. This effectively makes all the private array's contents available to unauthorized code, bypassing intended access controls.

This vulnerability occurs when an application unintentionally reveals sensitive details about its underlying system, such as file paths, software versions, or environment data, to users who should not have access to that information.

This vulnerability occurs when a class containing sensitive information, such as credentials or personal data, is made cloneable. Attackers can bypass normal initialization and access the sensitive data by creating a copy of the object.

This vulnerability occurs when a class containing sensitive information, such as credentials or personal data, is left serializable by default. Because the class does not explicitly prevent serialization, its internal data can be accessed and extracted by other parts of the application or external processes.

This vulnerability occurs when a class exposes a public static field without declaring it as final, allowing unintended modification from anywhere in the application.

This vulnerability occurs when an application incorrectly stores or processes trusted and untrusted data together within the same structure, such as an object, array, or message.

This vulnerability occurs when an application accepts and processes serialized data from an untrusted source without proper validation, allowing an attacker to manipulate the data to execute malicious code or cause unexpected behavior.

This vulnerability occurs when an application or codebase contains intentionally harmful code inserted by a developer or third party.

A Trojan Horse vulnerability occurs when software presents itself as legitimate and useful, but secretly contains malicious functionality that bypasses security controls. This hidden code operates without the user's knowledge, violating the intended security policy of the system or its administrator.

This type of malicious code is designed to operate only on the specific system it initially infects. Unlike viruses or worms, it does not contain mechanisms to copy itself or spread to other devices or networks.

This weakness describes software that is vulnerable to infection by self-replicating malicious programs like viruses or worms. Once such malware compromises a system, it can use that system as a launchpad to automatically spread and attack others.

A trapdoor, often called a backdoor, is a hidden piece of code intentionally placed within software. It activates in response to a specific, often secret, input—like a special password or sequence—bypassing standard authentication and authorization checks to grant unauthorized access.

A logic or time bomb is malicious code intentionally placed within software to trigger harmful actions when a specific condition is met or a predetermined time is reached.

Spyware is software that secretly gathers personal information about a user or their activities. It does this by accessing data from other sources on the system, without the user's direct input or explicit consent.

A covert channel is a hidden communication path that allows data to be transmitted in a way that bypasses the system's intended security controls and monitoring.

A covert storage channel is a type of security flaw where one process secretly encodes data into a shared system resource (like a file, memory bit, or status flag), and another unauthorized process later reads that resource to extract the hidden information.

This vulnerability occurs when a .NET application is configured to run with impersonation, potentially granting it excessive system-level permissions that attackers could exploit.

This vulnerability occurs when an application fails to enforce strong password policies, making user accounts easier to compromise through guessing or automated attacks.

This vulnerability occurs when an application handles sensitive credentials like passwords or API keys in an insecure way, making them easy for attackers to steal during transmission or while stored.

This vulnerability occurs when a login page or authentication system transmits user credentials (like usernames and passwords) over a network without proper encryption, exposing them to interception.

This vulnerability occurs when an application stores sensitive data in a cache that is accessible to unauthorized users or external systems.

This vulnerability occurs when a web application fails to implement secure caching directives, allowing sensitive user data or pages to be stored in the browser's cache where unauthorized parties could retrieve them.

This vulnerability occurs when an application stores sensitive data, such as passwords or API keys, as plain text in an environment variable.

This vulnerability occurs when a version control repository, like Git or SVN, is accidentally placed in a location accessible to unauthorized users, such as a web server directory or a public archive.

This vulnerability occurs when an application creates a core dump file (a snapshot of memory at the time of a crash) and places it in a location accessible to unauthorized users or systems.

This vulnerability occurs when an application stores sensitive access control list (ACL) files in a location that is accessible to unauthorized users or systems.

This vulnerability occurs when backup or temporary files are stored in locations that unauthorized users can access, such as web directories.

This vulnerability occurs when sensitive data, such as credentials, API keys, or internal logic, is embedded within test code or debugging applications that remain accessible in production environments. Attackers can discover and exploit these forgotten endpoints to gain unauthorized access or gather critical intelligence about the system.

This vulnerability occurs when an application unintentionally writes confidential data, such as passwords or API keys, into its log files.

This vulnerability occurs when a web application's command shell returns detailed error messages to users. Attackers can analyze these messages to understand the underlying system, identify weaknesses, and potentially gain unauthorized access.

This vulnerability occurs when a Java servlet application displays detailed runtime error messages that reveal sensitive information about the application's internal structure, such as stack traces, file paths, or database queries. These unhandled exception details can give attackers critical insights to craft further exploits.

This vulnerability occurs when a Java application's runtime error messages reveal sensitive details about the system, such as file paths, internal IP addresses, or stack traces. Attackers can exploit these overly informative error messages to map the application's structure and gather intelligence for further attacks.

This vulnerability occurs when an application unintentionally stores confidential data—like passwords, API keys, or personal user details—in a location that is publicly accessible or readable by unauthorized users. Even if the file itself is intended to be available, the sensitive information within it should not be.

This vulnerability occurs when a web application stores sensitive data, like authentication details or personal information, within persistent cookies that remain on a user's device.

This vulnerability occurs when sensitive information like passwords, API keys, or internal logic is exposed within source code that remains accessible on a web server or in a public repository.

This vulnerability occurs when sensitive data like passwords or system details is placed inside a publicly accessible include file. Attackers can directly request these files to steal credentials and compromise the application.

This vulnerability occurs when a singleton pattern is implemented in a multithreaded application without proper synchronization, potentially leading to multiple instances or corrupted state.

This weakness occurs when software lacks a unified, consistent approach to managing errors across its codebase, leading to unpredictable security gaps and unreliable behavior.

This weakness occurs when code contains comments that flag potential issues, such as bugs, security gaps, or unfinished work, which can expose underlying problems or oversights.

This vulnerability occurs when code directly embeds security-critical values like passwords, cryptographic keys, or access levels as raw numbers or strings, instead of using named constants or configuration files. This practice makes the code brittle and error-prone during updates or security reviews.

This vulnerability occurs when a web server is misconfigured to display a full list of files within a directory instead of serving a default web page, unintentionally exposing sensitive resources to anyone who visits the URL.

This vulnerability occurs when an application fails to hide password characters as they are typed, making them visible to anyone who can see the screen. This exposes user credentials to onlookers or screen-capturing malware.

This vulnerability occurs when a web application or server returns detailed error messages that reveal sensitive internal information about the system.

This vulnerability occurs when a web server checks access permissions before fully processing and normalizing a URL, potentially allowing attackers to bypass security controls.

This vulnerability occurs when an application exposes files or directories to users who shouldn't have access to them.

This vulnerability occurs when a command shell script is placed in a web-accessible directory, such as /cgi-bin/. Attackers can directly request this file to execute arbitrary commands on the server, leading to full system compromise.

This vulnerability occurs when an ASP.NET application fails to implement a structured input validation framework, relying instead on ad-hoc or missing validation checks.

A J2EE application insecurely stores an unprotected password within a configuration file.

This vulnerability occurs when an ASP.NET application is configured to run using impersonated credentials, which can grant the application excessive and unnecessary system privileges.

Using the getlogin() function in a multithreaded application can lead to unreliable or incorrect username results, creating security and logic flaws.

This vulnerability occurs when a program incorrectly uses the `umask()` system call with an argument formatted for `chmod()`, leading to unintended and overly permissive file permissions.

Dead code refers to sections of a program that can never run during normal execution, effectively making them inactive and unreachable.

This vulnerability occurs when a function returns a pointer to its own local variable. Since that variable's memory is on the stack, the pointer becomes invalid as soon as the function finishes, leading to crashes or unpredictable behavior.

This vulnerability occurs when a value is stored in a variable, but that variable is never read or used in subsequent code, creating a 'dead store.'

This vulnerability occurs when an application uses Hibernate to construct dynamic SQL queries with unsanitized user input, allowing an attacker to alter the query's logic or execute unauthorized SQL commands.

This vulnerability occurs when an application uses cookies to make security decisions—like granting access or changing settings—but fails to verify that the cookie data is legitimate, unaltered, and belongs to the current user.

This vulnerability occurs when an application allows a user to directly control the primary key value used in a SQL query, enabling them to access database records they are not authorized to view.

This vulnerability occurs when multiple threads in an application can read and modify shared data, like static variables, without proper coordination. This unsynchronized access corrupts data, causes crashes, and leads to unpredictable, often security-critical, behavior.

This vulnerability occurs when a Java class overrides the finalize() method but fails to call super.finalize() within it.

This vulnerability occurs when code contains a conditional expression that can never evaluate to true, causing a section of the program to be permanently unreachable.

This vulnerability occurs when code contains a conditional expression that will always evaluate to 'true', making the check ineffective and potentially bypassing critical security or logic gates.

This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the caller's current thread, bypassing the creation of a new, concurrent thread of execution.

This weakness occurs when software fails to properly follow the documented rules, protocols, or requirements of an external component it uses, such as a library, API, framework, or platform.

This vulnerability occurs when an Enterprise JavaBeans (EJB) component improperly uses thread synchronization primitives, violating the EJB specification's design principles.

This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses AWT or Swing UI toolkits, violating the EJB specification's design principles.

This vulnerability occurs when an Enterprise JavaBeans (EJB) component incorrectly uses Java I/O (java.io) operations to access the file system, violating the EJB specification's design principles.

This vulnerability occurs when an Enterprise JavaBeans (EJB) component breaks the EJB specification by directly creating or using network sockets.

This vulnerability occurs when an Enterprise JavaBeans (EJB) component directly manipulates the Java class loader, violating the EJB specification's security and portability rules.

This vulnerability occurs when a Java application stores an object in the user's session that cannot be serialized, which can break critical application features and hurt reliability.

This vulnerability occurs when a class's clone() method creates a new object directly instead of calling super.clone().

This vulnerability occurs when a Java class defines either the equals() method or the hashCode() method, but not both, breaking a fundamental contract of object equality.

This vulnerability occurs when an array is declared as public, final, and static, which does not protect the data inside the array from being altered.

This vulnerability occurs when a Java class declares its finalize() method as public, violating secure coding practices for mobile code.

This vulnerability occurs when a function places a return statement inside a finally block. This dangerous pattern silently discards any unhandled exceptions thrown earlier in the try block, making errors invisible and undermining application stability.

An empty synchronized block is a Java code construct where a synchronized block exists but contains no executable statements inside it.

This vulnerability occurs when code directly calls an object's finalize() method from outside its designated finalizer context.

This vulnerability occurs when code explicitly assigns a hardcoded memory address to a pointer, instead of using a dynamic or null value.

This vulnerability occurs when code incorrectly treats a pointer to a basic data type (like an integer) as if it points to a structured object (like a 'struct' in C). The program then tries to access a member field that doesn't exist at that memory location, which can cause crashes or corrupt adjacent data.

This vulnerability occurs when software relies on an operating system function that isn't available on all versions of the target platform. This can cause crashes, unexpected behavior, or security failures when the software runs in an environment where the API is missing.

This vulnerability occurs when a program calls free() on a memory pointer that wasn't originally allocated using standard heap functions like malloc(), calloc(), or realloc().

This vulnerability occurs when an application stores sensitive information, like passwords or encryption keys, in system memory that isn't properly secured from being written to disk. If the memory isn't locked, the operating system's virtual memory manager can swap it to a page or swap file, leaving the data exposed on the storage drive where attackers could potentially recover it.

This vulnerability occurs when an application modifies an OpenSSL context object after it has already been used to create active SSL/TLS connections.

This vulnerability occurs when a J2EE application framework attempts to save objects to disk that cannot be properly serialized, risking application failure.

This vulnerability occurs when code incorrectly checks if two object references point to the same memory location, rather than comparing the actual data or values contained within the objects. This mistake prevents the software from correctly identifying when two separate objects hold equivalent content.

This vulnerability occurs when a developer incorrectly compares string values, typically by using reference equality operators (like == or !=) instead of dedicated string comparison methods (like .equals()).

This vulnerability occurs when a web application handles sensitive data, like passwords or session tokens, by passing them within the URL's query string using an HTTP GET request.

This vulnerability occurs when an application uses OpenSSL but fails to properly verify server certificates by not calling SSL_get_verify_result(). Without this validation, the application may accept insecure or fraudulent certificates.

This vulnerability occurs when a Java Servlet fails to properly catch and handle exceptions, potentially exposing sensitive system information in error messages.

An open redirect vulnerability occurs when a web application uses unvalidated user input to determine the destination of a redirect, allowing an attacker to send users to an untrusted, external website.

This vulnerability occurs when a server incorrectly trusts the client to enforce critical security rules, such as input validation or access controls, instead of performing these checks itself.

This vulnerability occurs when an application places its authentication logic solely within the client-side code, such as in a mobile app or web browser, without enforcing the same checks on the server. Attackers can bypass authentication by modifying the client to skip these checks entirely.

This vulnerability occurs when a system's socket configuration allows multiple applications to bind to the same network port simultaneously. This can let a malicious process hijack or impersonate legitimate services running on that port.

This vulnerability occurs when an application fails to properly validate or limit user-supplied values that control loop iterations. Without these checks, malicious input can force the program into an endless or excessively long loop, consuming system resources and leading to denial of service or application instability.

This vulnerability occurs when a class exposes a public or protected static final field that points to a changeable object. Because the field's reference is constant but the object itself is not, malicious code or even accidental code in other packages can modify the object's contents, violating the intended immutability.

This vulnerability occurs when an Apache Struts ActionForm class exposes a field without declaring it as private. This allows other parts of the application to directly read or modify the field's data, bypassing the intended setter and getter methods.

Double-checked locking is an insufficient synchronization pattern where a program checks a resource's state, acquires a lock, and checks the state again before initialization, failing to guarantee thread safety across all systems.

This vulnerability occurs when an application uses user-supplied input to reference a resource located outside its intended security boundary, allowing attackers to redirect operations to unintended locations.

This vulnerability occurs when an application processes XML input without properly restricting external entity references. Attackers can exploit this to read local files, trigger internal network requests, or cause denial of service.

This vulnerability occurs when a system indexes sensitive documents for search but fails to properly restrict who can query that index. Attackers can then discover and extract confidential information from the indexed content without having direct access to the original files.

Insufficient session expiration occurs when an application allows old session tokens or IDs to remain valid for too long, letting attackers reuse them to gain unauthorized access.

This vulnerability occurs when a web application transmits sensitive cookies over an HTTPS connection but fails to set the 'Secure' attribute on those cookies.

This vulnerability occurs when developers leave sensitive details within source code comments. These can include internal file paths, hidden URLs, inactive code snippets, credentials, or other information meant for internal use only.

This vulnerability occurs in PHP applications that rely on the deprecated, auto-registered global variables for file uploads (like $varname, $varname_size). Because these variables are not properly validated, an attacker can overwrite them to trick the application into processing malicious or unauthorized files.

A reachable assertion occurs when an attacker can trigger an assert() statement or similar debugging check, causing the application to crash or behave in a more disruptive way than intended. This turns a helpful development tool into a denial-of-service vulnerability.

This vulnerability occurs when an ActiveX control, designed for web browsers, exposes methods that bypass the browser's built-in security restrictions. These unsafe methods can perform actions outside the browser's intended security boundaries, such as those defined by zones or domains.

A dangling database cursor occurs when a database cursor is not properly closed, potentially allowing other users to access it while it retains its original, often elevated, privileges.

This vulnerability occurs when an application allows a user to set a new password without first verifying their identity through the old password or a secure secondary authentication method.

This vulnerability occurs when an application uses unvalidated external input to dynamically select which variables to populate with data. Without proper checks, this can allow an attacker to overwrite critical internal variables, leading to unexpected behavior or security breaches.

This vulnerability occurs when an application adds monitoring or interception hooks to critical functions, but fails to properly check the arguments passed to those hooks. This lack of validation can allow attackers to inject malicious data, leading to security bypasses or system compromise.

This vulnerability occurs when an ActiveX control designed for limited use is incorrectly flagged as safe for scripting, allowing web pages to access its potentially dangerous functions.

This vulnerability occurs when an application uses a regular expression that can execute code, either because it directly contains executable logic with unsafe user input, or because an attacker can inject pattern modifiers that enable code execution.

This weakness occurs when a regular expression is too permissive, failing to properly validate or sanitize input by allowing unintended values or patterns.

This vulnerability occurs when software incorrectly processes null bytes (NUL characters) as data moves between different systems or programming languages, leading to unexpected and potentially dangerous behavior.

This vulnerability occurs when an application allows user input to directly determine which variable or function name is used at runtime. Without strict validation, an attacker can manipulate these names to access or modify sensitive data, execute unauthorized functions, or disrupt the application's logic.

This weakness occurs when a function is called with arguments that are incorrectly specified, causing the function to behave in an unintended and consistently wrong manner.

This vulnerability occurs when a system, upon encountering an error or failure, defaults to its least secure configuration instead of a safer alternative. Examples include reverting to the weakest encryption or the most permissive access rules.

This weakness occurs when a security feature is implemented with excessive complexity, creating unnecessary risk. Overly intricate protection mechanisms are harder to understand, configure, and implement correctly, often leading to security gaps and misconfigurations.

This vulnerability occurs when software fails to verify access permissions every single time a user or process tries to use a resource. Instead, it might rely on a single, outdated check, creating a security gap if the user's privileges are later revoked or changed.

This vulnerability occurs when an application's authorization system fails to verify that a user is allowed to access specific data before retrieving it, allowing an attacker to access another user's information by manipulating an identifier they control.

This vulnerability occurs when an application's password reset or recovery feature is poorly designed or implemented, allowing attackers to bypass authentication and hijack user accounts.

This vulnerability occurs when an application creates file or resource names using unvalidated user input, failing to properly limit what characters or paths can be used.

This vulnerability occurs when an application stores security-sensitive state data in locations that unauthorized users can access and modify.

XPath Injection occurs when an application uses unvalidated user input to build an XPath query for an XML database. Without proper sanitization, attackers can manipulate the query's structure.

This vulnerability occurs when an application fails to properly sanitize or escape user-controlled data placed within HTTP response headers. Malicious scripting syntax can then be injected and executed by client-side components like Flash that process raw headers.

This vulnerability occurs when an application's account lockout feature is too strict, allowing attackers to easily trigger it and lock legitimate users out of their accounts, causing a denial of service.

This vulnerability occurs when an application uses the name or extension of an uploaded file to decide how to handle it. Attackers can manipulate this by uploading files with deceptive names, causing the application to process them incorrectly and potentially dangerously.

This vulnerability occurs when an application's authorization logic relies on specific URL paths but fails to enforce a single, standardized format. Attackers can bypass access controls by using alternative, equivalent URL formats that the system doesn't recognize as the same protected resource.

This vulnerability occurs when software incorrectly uses functions that require special permissions. Attackers can exploit these mistakes to gain unauthorized access, elevate their privileges, or steal sensitive data.

This vulnerability occurs when an application uses obfuscation or encryption to hide security-sensitive data (like tokens or parameters) but fails to verify whether that data has been altered. Without integrity checks, the system cannot detect if an attacker has tampered with these inputs.

This vulnerability occurs when a server incorrectly assumes that HTTP GET requests are always safe and cannot change server-side data. Attackers can exploit this flawed assumption to bypass security controls and perform unauthorized actions like modifying or deleting resources.

This vulnerability occurs when a Web Service Definition Language (WSDL) file, which acts as a public blueprint for a web service, is exposed in a way that reveals sensitive information about the application's internal structure or functionality.

XQuery Injection occurs when an application uses unvalidated user input to build an XQuery expression for querying an XML database. Without proper neutralization, an attacker can manipulate the query's structure.

This vulnerability occurs when an application fails to enforce strong boundaries between components that operate at different security levels, allowing lower-privileged functions to improperly interact with higher-privileged ones.

This vulnerability occurs when a system's security check depends almost entirely on just one condition, object, or piece of data to decide whether to grant access to sensitive resources or actions. It's like having a single, easily compromised lock on a vault, instead of a layered defense.

This weakness occurs when security features are so cumbersome or confusing that well-intentioned users feel forced to turn them off or find workarounds, defeating their purpose entirely.

This weakness occurs when a system's primary defense relies on hiding how it works, rather than using a robust, well-tested security mechanism. If an attacker discovers the hidden details—like a secret algorithm or hardcoded key—the protection fails completely.

This weakness occurs when a system's architecture or design fails to follow fundamental security principles, creating a flawed foundation that can lead to multiple vulnerabilities.

This vulnerability occurs when a multi-threaded or multi-process application allows shared resources to be accessed by multiple threads or processes simultaneously, without proper safeguards to enforce exclusive access.

This vulnerability occurs when a program uses a function that is not safe for reentrancy within a concurrent environment, such as multi-threaded code or signal handlers. If another thread or signal handler interrupts and calls the same function, it can corrupt shared data, cause crashes, or create unpredictable behavior.

This vulnerability occurs when software fails to properly manage a resource throughout its entire lifecycle—from creation and active use to its final release or destruction.

This vulnerability occurs when software fails to properly set up a resource before use, or provides incorrect starting values, leaving it in an unpredictable and potentially dangerous state.

This vulnerability occurs when software interacts with a resource—like memory, a file, or a network connection—at an incorrect stage of its existence, leading to crashes, data corruption, or unpredictable behavior.

This vulnerability occurs when a program fails to correctly acquire or release a lock on a shared resource, such as a file, database record, or memory location. This improper synchronization allows other processes or threads to interfere, leading to corrupted data, crashes, or unpredictable behavior.

This vulnerability occurs when an application unintentionally makes a resource accessible to users or systems that should not have permission to use it.

This vulnerability occurs when an application incorrectly moves or shares a resource (like data, permissions, or functionality) between different trust boundaries or security contexts. This improper transfer can give unintended actors control over that resource, leading to security breaches.

This weakness occurs when a section of code is structured in a way that always executes incorrectly, regardless of input or conditions. The control flow logic is fundamentally flawed and does not match the intended algorithm.

This weakness occurs when a system's built-in security settings cannot be adjusted by its administrator. This prevents tailoring security to the specific deployment environment, forcing the system to operate at a lower or inappropriate security level than required.

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.

The application allows external parties to modify its security boundaries or trusted zones, which should be defined and controlled internally.

This vulnerability occurs when an application fails to limit how deeply a function can call itself. Without proper controls, this uncontrolled recursion can exhaust system resources like memory or stack space, leading to crashes or denial-of-service.

This vulnerability occurs when a software component performs the same action on a resource multiple times, even though the action is designed to be executed only once. This redundant execution can lead to unintended side effects, data corruption, or resource exhaustion.

This vulnerability occurs when code calls a function that can be dangerous if misused, but can also be used safely with proper precautions. The risk lies not in the function itself, but in how it's implemented.

This vulnerability occurs when a program calculates the size of memory to allocate, but an integer overflow in that calculation results in a much smaller buffer being created than intended. This undersized buffer can then be overflowed by subsequent operations, corrupting adjacent memory.

This vulnerability occurs when a program converts a value from one numeric type to another (like a 64-bit integer to a 32-bit integer) and the conversion loses or misinterprets data. If these corrupted values are later used in security-critical operations—like calculating buffer sizes, checking permissions, or performing financial transactions—they can lead to crashes, incorrect behavior, or security bypasses.

This vulnerability occurs when software performs a calculation that produces wrong or unexpected results, which are then used to make security decisions or manage critical resources.

This vulnerability occurs when a program calls a function but supplies the arguments in the wrong order, which can cause unexpected behavior or security flaws.

This weakness occurs when software behaves differently than its documented specifications, which can mislead users and create security risks.

This weakness occurs when a program calls a function, method, or subroutine but provides the wrong number of arguments—either too many or too few. This mismatch can cause the program to behave unpredictably, access incorrect memory, or crash, creating a security vulnerability.

This vulnerability occurs when a program calls a function or method but passes an argument of the wrong data type, which can cause unexpected behavior or security flaws.

This vulnerability occurs when a function is called with an argument that holds an incorrect or unexpected value, leading to unintended program behavior or security flaws.

This vulnerability occurs when a function is called with the wrong variable or reference passed as an argument. This simple coding mistake can cause the program to behave unpredictably, access incorrect data, or trigger other security flaws.

This vulnerability occurs when a system copies a file or resource but delays setting its final permissions until the entire copy operation is finished. During the copy process, the resource remains exposed with default or overly permissive access, creating a temporary window where unauthorized users or processes could read, modify, or delete it.

This vulnerability occurs when a program calls a function that can return a NULL pointer to signal failure, but the code does not check for this error condition before using the returned value, leading to a crash or unexpected behavior from dereferencing the NULL pointer.

This vulnerability occurs when a program's execution flow isn't properly managed, allowing attackers to bypass critical checks, trigger unexpected code paths, or disrupt normal operation.

This vulnerability occurs when an application relies on an incomplete denylist to block cross-site scripting (XSS) attacks, leaving the door open for attackers to craft payloads that bypass the filter.

This weakness occurs when software either lacks a necessary security control, implements one that is too weak, or fails to activate an existing control in a critical area, leaving it vulnerable to targeted attacks.

This vulnerability occurs when a system uses multiple resources that can share the same identifier, even though the application logic requires each identifier to be unique.

This vulnerability occurs when code bypasses high-level framework controls by directly using low-level system functions, violating the intended security model.

This weakness occurs when a system executes multiple dependent actions in the wrong sequence, leading to unexpected and potentially vulnerable states.

This weakness occurs when a security-critical decision relies on a flawed comparison between two pieces of data. The incorrect logic can create a gap that attackers exploit to bypass checks or trigger unintended behavior.

Execution After Redirect (EAR) occurs when a web application sends a redirect response to a user's browser but continues to run server-side code, potentially performing unintended actions.

This vulnerability occurs when software fails to properly plan for or manage rare but possible error scenarios, leaving it unprepared for unexpected events that can disrupt normal operation.

This vulnerability occurs when software incorrectly changes data from one type to another, leading to unexpected behavior or security flaws.

This vulnerability occurs when a program fails to return execution to the correct point in the code after finishing a specific operation or handling an error. Instead of resuming normal flow, it may jump to an unintended location, leading to unpredictable behavior or security issues.

This vulnerability occurs when software uses a name, path, or reference to access a resource, but that identifier points to something outside the area the application is supposed to control, leading to unauthorized access or manipulation.

This vulnerability occurs when an application fails to properly validate or sanitize structured data before it's received from an external source or sent to another component. This allows malformed messages to be processed, which can lead to misinterpretation and security breaches.

This vulnerability occurs when a system grants ownership of a resource to an entity that should not have that level of control, placing it outside the intended security boundary.

This weakness occurs when developers don't consistently follow established coding standards and best practices, which can introduce security flaws or make existing vulnerabilities more severe.

This vulnerability occurs when a system grants overly permissive access to a sensitive resource, allowing unauthorized users or processes to read or alter it.

This vulnerability occurs when a compiler's optimization process unintentionally strips out or alters security-critical code that a developer intentionally wrote, leaving the application exposed.

This vulnerability occurs when a software component exposes an API or interface containing a high-risk function that lacks proper access controls, allowing unauthorized actors to trigger it.

This weakness occurs when software fails to properly anticipate and handle rare or unexpected runtime situations that fall outside normal operation.

This vulnerability occurs when software fails to properly manage unexpected situations or errors, leaving it in an unstable or insecure state.

This vulnerability occurs when an application fails to display its own user-friendly error pages, instead falling back to default system messages that can leak sensitive technical details.

This vulnerability occurs when a protocol or system allows negotiating a security algorithm (like encryption) but chooses a weaker option than the strongest one both parties support, creating an unnecessary security gap.

This weakness occurs when software depends on specific behaviors of an API, data structure, or system component that are not formally guaranteed by its specification. The code assumes these behaviors will always work a certain way, but they might change or fail under different conditions.

This vulnerability occurs when a system uses a one-way hash function (like MD5 or SHA-256) to protect sensitive data like passwords, but fails to add a unique random value called a salt before hashing.

This vulnerability occurs when an application uses a one-way hash (like for password storage) but combines it with a predictable or easily guessed salt. This undermines the security benefit of salting, making pre-computed attack methods like rainbow tables highly effective.

This vulnerability occurs when a program incorrectly frees a memory pointer that no longer points to the beginning of the allocated heap buffer, often due to pointer arithmetic.

This vulnerability occurs when a program uses incompatible functions to allocate and free memory. For example, freeing memory with a function that doesn't match the one used to create it, like mixing different memory management systems.

This vulnerability occurs when a program tries to free a memory resource back to the system but uses an incorrect deallocation method or calls the correct method improperly.

This vulnerability occurs when a critical resource, such as a file, data structure, or connection, is locked more times than the software logic intended, putting the system into an unstable or unresponsive state.

This vulnerability occurs when a critical resource, like a lock or semaphore, is unlocked more times than it was locked, putting the system into an unexpected and potentially unstable state.

This vulnerability occurs when a critical piece of data—like a variable, field, or class member—is mistakenly declared as public when it should be kept private according to the application's security design.

This vulnerability occurs when a class exposes a public method that directly accesses or alters a private variable.

This vulnerability occurs when a program's conditional statement uses short-circuit evaluation (where later parts of an AND/OR check are skipped if the outcome is already determined), and the skipped portions contain code that changes the program's state. Because these side effects—like updating a variable, checking a permission, or logging an event—are never executed, the application can enter an unexpected and potentially insecure state.

This vulnerability occurs when a system allows users or processes to request resources without any built-in caps or rate limits. Think of it as a buffet with no rules on how much one person can take, eventually leaving nothing for others and causing the system to fail.

This vulnerability occurs when software loses track of a resource it has allocated, like memory or a file handle, preventing the system from properly releasing it back for future use.

This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation of unused resources, known as a resource leak.

This vulnerability occurs when a program fails to keep track of open files or resources, preventing the system from properly closing and reclaiming them.

This vulnerability occurs when an application creates file descriptors or handles for a user or process without enforcing any limits on the total number that can be opened.

This vulnerability occurs when a program fails to properly close file descriptors or handles after they are no longer needed, leaving these system resources allocated.

This vulnerability occurs when an XML parser allows Document Type Definitions (DTDs) to contain recursively defined entities without proper limits, enabling malicious data structures.

This vulnerability occurs when a regular expression used for validation or sanitization lacks anchors, allowing unintended characters or malicious payloads to bypass security checks.

This weakness occurs when an application fails to properly record important security events or captures them with insufficient detail, making it hard to spot and investigate suspicious activity.

This vulnerability occurs when an application records more information than necessary in its logs, making log files difficult to analyze and potentially slowing down incident response or security investigations.

This vulnerability occurs when an application implements RSA encryption but fails to use Optimal Asymmetric Encryption Padding (OAEP), significantly weakening the cryptographic protection.

This vulnerability occurs when a Windows driver defines an IOCTL using METHOD_NEITHER but fails to properly check the user-supplied memory addresses before using them.

This vulnerability occurs when a system exposes an IOCTL (Input/Output Control) interface that performs sensitive operations, but fails to implement proper checks to verify which users or processes are allowed to call it.

This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or misapplying the rules of operator precedence.

This vulnerability occurs when an application makes security decisions—like granting access or verifying identity—based solely on cookie data without first confirming the cookie's authenticity or integrity.

This vulnerability occurs when a program uses a path manipulation function but supplies an output buffer that is too small to hold the maximum possible path length, such as PATH_MAX.

This vulnerability occurs when software attempts to read from or write to a memory location positioned before the official start of a buffer.

This vulnerability occurs when software incorrectly writes data outside the boundaries of its allocated memory buffer, either beyond the end or before the beginning.

This vulnerability occurs when software attempts to read from or write to a memory buffer using an index or pointer that points past the buffer's allocated boundary.

This vulnerability occurs when a program allocates memory based on a user-supplied or untrusted size value without proper validation. If an attacker provides an excessively large number, the application can attempt to allocate massive amounts of system memory, leading to a denial-of-service or system instability.

This vulnerability occurs when an application accepts data from a source but fails to properly sanitize or incorrectly filters out special characters or control elements before passing that data to another system component.

This vulnerability occurs when an application accepts data from a source but fails to properly clean or neutralize all special characters or commands before passing that data to another system component.

This vulnerability occurs when an application receives external data but fails to properly neutralize all instances of potentially dangerous characters or code patterns before passing that data to another system component.

This vulnerability occurs when an application processes incoming data but only removes or neutralizes one occurrence of a dangerous element, leaving other identical or similar elements untouched before passing the data along.

This vulnerability occurs when an application receives data from a source but fails to remove or neutralize every instance of a potentially dangerous element before passing that data to another component.

This vulnerability occurs when a security filter only checks for dangerous input patterns at specific, predefined locations within the data. It fails to scan the entire input stream, allowing malicious elements that appear outside the expected location to pass through and potentially harm downstream components.

This vulnerability occurs when software filters dangerous inputs or characters, but only checks for them in specific, expected locations (like the start or end of a string). It fails to detect and remove the same dangerous elements if they appear elsewhere in the data, allowing them to pass through to critical system components.

This vulnerability occurs when software checks for dangerous characters or patterns only at a fixed, hardcoded location in input data. Because it ignores these same elements if they appear anywhere else, attackers can bypass the filter by simply moving the malicious content to a different position.

This vulnerability occurs when software contains built-in, unchangeable authentication secrets like passwords or encryption keys within its source code or configuration files.

This vulnerability occurs when an application fails to properly restrict how often or how many times a user or automated system can interact with it.

This vulnerability occurs when a CAPTCHA challenge is too easy for automated bots to solve, either by guessing or using pattern recognition, allowing them to bypass the human verification step.

This vulnerability occurs when software reads from or writes to a buffer using a loop or sequential operation, but mistakenly calculates or provides an incorrect length value. This incorrect length causes the operation to access memory outside the buffer's allocated boundaries.

This vulnerability occurs when a program uses the size of the source data buffer to control reading or writing to a smaller destination buffer, potentially accessing memory outside the destination's allocated bounds.

This vulnerability occurs when an application's security check depends on user-controlled data that can be manipulated to bypass protection mechanisms, such as authentication or authorization gates.

This vulnerability occurs when multiple parts of your application (like threads or processes) use the same resource—such as a variable, file, or data structure—without proper coordination to control who accesses it and when.

This vulnerability occurs when multiple parts of a program, such as threads or processes, access a shared resource like a variable, file, or data structure without proper coordination, leading to a race condition.

This vulnerability occurs when software takes a value from an untrusted source, treats it as a memory address (a pointer), and then accesses that memory location directly for reading or writing.

This vulnerability occurs when a program calculates a new memory address using a valid pointer and an offset, but the resulting address points outside the intended, safe memory region, such as beyond the bounds of an array or structure.

This vulnerability occurs when a program tries to use a pointer variable before it has been assigned a valid memory address.

This vulnerability occurs when a program tries to use a pointer that still points to a memory location that has already been freed or released.

This happens when software incorrectly frees or closes a resource—like memory, a file handle, or a network connection—while that resource is still supposed to be in active use by the program or another component.

This vulnerability occurs when an application fails to properly restrict which Document Type Definitions (DTDs) can be referenced during XML parsing. Attackers can exploit this by injecting references to malicious DTDs, potentially leading to unauthorized file access, server-side request forgery (SSRF), or denial-of-service through resource exhaustion.