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 Classe Incomplet
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.
Définition
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.
Impact réel
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)
Comment les attaquants l'exploitent
Parcours de l'attaquant étape par étape
- 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.
Exemple de code vulnérable
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;
} Exemple de code sécurisé
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.
Liste de contrôle de prévention
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.
Signaux de détection
How to detect CWE-704
CWE-704
Don't catalog this weakness. Prove it's reachable.
Plexicus turns CWE catalogs into evidence: every CWE-pattern is matched against your real code graph, reach is proven on a sandbox clone, and verified findings ship as reviewed PRs.
Questions fréquentes Qu'est-ce que CWE-704 ?
Quelle est la gravité de CWE-704 ?
Quels langages ou plateformes sont affectés par CWE-704 ?
Comment puis-je prévenir CWE-704 ?
Comment Plexicus détecte et corrige CWE-704 ?
Où puis-je en savoir plus sur CWE-704 ?
Frequently asked questions
Qu'est-ce que CWE-704 ?
This vulnerability occurs when software incorrectly changes data from one type to another, leading to unexpected behavior or security flaws.
Quelle est la gravité de CWE-704 ?
MITRE n'a pas publié de note de probabilité d'exploitation pour cette faiblesse. Traitez-la comme un impact moyen jusqu'à ce que votre modèle de menace prouve le contraire.
Quels langages ou plateformes sont affectés par CWE-704 ?
MITRE lists the following affected platforms: C, C++.
Comment puis-je prévenir 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.
Comment Plexicus détecte et corrige CWE-704 ?
Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-704 à chaque commit. Lorsqu'une correspondance est trouvée, notre agent Codex Remedium ouvre une PR de correction avec le code corrigé, les tests et un résumé d'une ligne pour le relecteur.
Où puis-je en savoir plus sur CWE-704 ?
MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/704.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.
Faiblesses associées
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 Frère
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 Frère
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 Frère
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 Frère
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 Frère
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 Frère
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 Frère
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 Frère
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…
Prêt à valider l'essentiel ?
Prêt à valider ce qui compte.
Plexicus est Proof-Driven AppSec : findings validés, compréhension contextuelle et remédiation relue — ancrée dans la preuve, scopée avec vous.