cve.bz

CAPEC-28

Fuzzing

Medium severityHigh likelihoodMeta pattern

In this attack pattern, the adversary leverages fuzzing to try to identify weaknesses in the system. Fuzzing is a software security and functionality testing method that feeds randomly constructed input to the system and looks for an indication that a failure in response to that input has occurred. Fuzzing treats the system as a black box and is totally free from any preconceptions or assumptions about the system. Fuzzing can help an attacker discover certain assumptions made about user input in the system. Fuzzing gives an attacker a quick way of potentially uncovering some of these assumptions despite not necessarily knowing anything about the internals of the system. These assumptions can then be turned against the system by specially crafting user input that may allow an attacker to achieve their goals.

On this page

Ask an AI about this attack pattern

Show the promptExplain the attack pattern CAPEC-28: Fuzzing: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/28.html and https://cve.bz/cve/capec/28?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Observe communication and inputs] The fuzzing attacker observes the target system looking for inputs and communications between modules, subsystems, or systems.

      3 techniques
      • Network sniffing. Using a network sniffer such as wireshark, the attacker observes communications into and out of the target system.
      • Monitor API execution. Using a tool such as ktrace, strace, APISpy, or another debugging tool, the attacker observes the system calls and API calls that are made by the target system, and the nature of their parameters.
      • Observe inputs using web inspection tools (OWASP's WebScarab, Paros, TamperData, TamperIE, etc.)
  2. Experiment

    They probe what they found.

    1. [Generate fuzzed inputs] Given a fuzzing tool, a target input or protocol, and limits on time, complexity, and input variety, generate a list of inputs to try. Although fuzzing is random, it is not exhaustive. Parameters like length, composition, and how many variations to try are important to get the most cost-effective impact from the fuzzer.

      2 techniques
      • Boundary cases. Generate fuzz inputs that attack boundary cases of protocol fields, inputs, or other communications limits. Examples include 0xff and 0x00 for single-byte inputs. In binary situations, approach each bit of an individual field with on and off (e.g., 0x80).
      • Attempt arguments to system calls or APIs. The variations include payloads that, if they were successful, could lead to a compromise on the system.
    2. [Observe the outcome] Observe the outputs to the inputs fed into the system by fuzzers and see if anything interesting happens. If failure occurs, determine why that happened. Figure out the underlying assumption that was invalidated by the input.

  3. Exploit

    They carry out the attack.

    1. [Craft exploit payloads] Put specially crafted input into the system that leverages the weakness identified through fuzzing and allows to achieve the goals of the attacker. Fuzzers often reveal ways to slip through the input validation filters and introduce unwanted data into the system.

      3 techniques
      • Identify and embed shell code for the target system.
      • Embed higher level attack commands in the payload. (e.g., SQL, PHP, server-side includes, etc.)
      • Induce denial of service by exploiting resource leaks or bad error handling.

Skills required

  • Low skill

    There is a wide variety of fuzzing tools available.

Resources required

  • Fuzzing tools.

Signs of an attack

  • A lot of invalid data is fed to the system. Data that cannot have been generated through a legitimate transaction/request. Data is coming into the system within a short period of time and potentially from the same IP.

Consequences

What a successful attack can lead to
ImpactAffectsNote
Modify DataIntegrity
Unreliable ExecutionAvailability
Read DataConfidentiality
Gain PrivilegesConfidentiality, Access Control, Authorization
Alter Execution LogicConfidentiality, Integrity, Availability

Mitigations

  • Test to ensure that the software behaves as per specification and that there are no unintended side effects. Ensure that no assumptions about the validity of data are made.

  • Use fuzz testing during the software QA process to uncover any surprises, uncover any assumptions or unexpected behavior.

Weaknesses it exploits

  • CWE-20 Improper Input Validation
  • CWE-74 Improper Neutralization of Special Elements in Output Used by a Downstream Component

Recent CVEs with these weaknesses

  1. 9.6CVE-2026-108186

    Improper Input Validation in Zoom Workplace for Windows may allow an unauthenticated user to conduct an escalation of privilege via network access.

  2. 4.9CVE-2026-105427

    Improper input validation in Ivanti EPMM before version 12.10.0.1, 12.9.0.3, and 12.8.0.5 allows a remote authenticated attacker with admin privileges to permanently disable all Apache HTTPS services resulting in denial of service.

  3. 6.7CVE-2026-105426

    Improper input validation in Ivanti EPMM before version 12.10.0.1, 12.9.0.3, and 12.8.0.5 allows a remote authenticated attacker with admin privileges to set arbitrary Linux kernel parameters as root.

  4. 4.3CVE-2026-123178

    An insufficient input validation vulnerability in the listed NETGEAR Orbi Models router allows an authenticated administrator connected to the local network to execute unauthorized commands and modify the router’s software and functionalit…

  5. 6.3CVE-2026-125871

    The sourcecache expansion module in MISP Modules (misp-modules) contains a Server-Side Request Forgery (SSRF) vulnerability. When a user with permission to create or modify attributes of type 'link' or 'url' submits an attribute value, the…

  6. 5.5CVE-2026-125703

    A flaw was found in the GStreamer gst-plugins-bad MXF plugin. Insufficient bounds checks when parsing crafted VANC data can cause an out-of-bounds read in the demuxer, while an incorrect buffer size calculation when muxing multiple ancilla…

  7. 5.3CVE-2026-125113

    The XRootD project provides a high-performance, fault-tolerant, and secure solution for handling large amounts of data distributed across multiple storage resources. Prior to version 5.9.2, XRootD's rpCheck() function in src/XrdXrootd/XrdX…

  8. 6.9CVE-2026-63634

    pympp is a Python SDK for the Machine Payments Protocol. Prior to version 0.9.1, when the server acts as the fee_payer, pympp validates calldata using eth_abi decoding, which is lenient about trailing bytes. The FeePayerPolicy caps gas_lim…

The newest records naming one of them. Each weakness's page lists them all.

More specific patterns

Examples

A fuzz test reveals that when data length for a particular field exceeds certain length, the input validation…

A fuzz test reveals that when data length for a particular field exceeds certain length, the input validation filter fails and lets the user data in unfiltered. This provides an attacker with an injection vector to deliver the malicious payload into the system.

MITRE's words, unchanged: CAPEC-28 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.