Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
CWE-704 Class Incomplete
Incorrect Type Conversion or Cast
This vulnerability occurs when software incorrectly changes data from one type to another, leading to unexpected behavior or security flaws.
Definition
What is CWE-704?
This vulnerability occurs when software incorrectly changes data from one type to another, leading to unexpected behavior or security flaws.
Incorrect type conversion, often called a type confusion or type casting bug, happens when a developer assumes a piece of data is one kind of object or structure (like an integer, string, or class instance) but the program treats it as another. This mismatch can cause the application to misinterpret the data's meaning, access the wrong memory locations, or call incorrect functions, which attackers can exploit to crash the system, leak information, or execute arbitrary code.
These issues are common in languages that allow manual type casting (like C/C++) or have weak typing, but they can also appear in higher-level languages during serialization, inter-process communication, or when using reflection. To prevent this, developers should validate data types before conversion, use safe casting functions provided by the language, and implement strict input validation at all system boundaries.
Real-world impact
Real-world CVEs caused by CWE-704
-
Chain: in a web browser, an unsigned 64-bit integer is forcibly cast to a 32-bit integer (CWE-681) and potentially leading to an integer overflow (CWE-190). If an integer overflow occurs, this can cause heap memory corruption (CWE-122)
-
Chain: data visualization program written in PHP uses the "!=" operator instead of the type-strict "!==" operator (CWE-480) when validating hash values, potentially leading to an incorrect type conversion (CWE-704)
How attackers exploit it
Step-by-step attacker path
- 1
In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.
- 2
If the return value of accessmainframe() is -1, then the return value of readdata() will be 4,294,967,295 on a system that uses 32-bit integers.
- 3
The following code uses a union to support the representation of different types of messages. It formats messages differently, depending on their type.
- 4
The code intends to process the message as a NAME_TYPE, and sets the default message to "Hello World." However, since both buf.name and buf.nameID are part of the same union, they can act as aliases for the same memory location, depending on memory layout after compilation.
- 5
As a result, modification of buf.nameID - an int - can effectively modify the pointer that is stored in buf.name - a string.
Vulnerable code example
Vulnerable C
In this example, depending on the return value of accecssmainframe(), the variable amount can hold a negative value when it is returned. Because the function is declared to return an unsigned value, amount will be implicitly cast to an unsigned number.
unsigned int readdata () {
int amount = 0;
...
amount = accessmainframe();
...
return amount;
} Secure code example
Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-704
- Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
- Implementation Validate input at trust boundaries; use allowlists, not denylists.
- Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
- Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
- Operation Monitor logs for the runtime signals listed in the next section.
Detection signals
How to detect CWE-704
Plexicus auto-detects CWE-704 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-704?
How serious is CWE-704?
What languages or platforms are affected by CWE-704?
How can I prevent CWE-704?
How does Plexicus detect and fix CWE-704?
Where can I learn more about CWE-704?
Frequently asked questions
What is CWE-704?
This vulnerability occurs when software incorrectly changes data from one type to another, leading to unexpected behavior or security flaws.
How serious is CWE-704?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-704?
MITRE lists the following affected platforms: C, C++.
How can I prevent CWE-704?
Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.
How does Plexicus detect and fix CWE-704?
Plexicus's SAST engine matches the data-flow signature for CWE-704 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-704?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/704.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-704
CWE-664 Parent
Improper Control of a Resource Through its Lifetime
This vulnerability occurs when software fails to properly manage a resource throughout its entire lifecycle—from creation and active use…
CWE-118 Sibling
Incorrect Access of Indexable Resource ('Range Error')
This vulnerability occurs when software fails to properly check the boundaries of an indexed resource, like an array, buffer, or file,…
CWE-1229 Sibling
Creation of Emergent Resource
This vulnerability occurs when a system's normal operations unintentionally create new, exploitable resources that attackers can use to…
CWE-1250 Sibling
Improper Preservation of Consistency Between Independent Representations of Shared State
This vulnerability occurs when a system with multiple independent components (like distributed services or separate hardware units) each…
CWE-1329 Sibling
Reliance on Component That is Not Updateable
This vulnerability occurs when a product depends on a component that cannot be updated or patched to fix security flaws or critical bugs.
CWE-221 Sibling
Information Loss or Omission
This weakness occurs when an application fails to log critical security events or records them inaccurately, which can misguide security…
CWE-372 Sibling
Incomplete Internal State Distinction
This vulnerability occurs when an application fails to accurately track its own operational state. The system incorrectly assumes it's in…
CWE-400 Sibling
Uncontrolled Resource Consumption
This vulnerability occurs when an application fails to properly manage a finite resource, allowing an attacker to exhaust it and cause a…
CWE-404 Sibling
Improper Resource Shutdown or Release
This vulnerability occurs when a program fails to properly close or release a system resource—like a file handle, database connection, or…
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.