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-393 Base Brouillon
Return of Wrong Status Code
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…
Définition
What is CWE-393?
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.
When a system relies on these incorrect return codes to make decisions, it can lead to unpredictable application states, logic errors, and instability. For example, a function might incorrectly report a successful file deletion or a failed authentication check, causing the program flow to proceed down the wrong path.
If these status checks are part of security-critical logic—like access control, authentication, or data validation—the consequences are severe. The application might grant access to unauthorized users, assume a dangerous operation succeeded safely, or fail to alert on genuine security failures, creating hidden vulnerabilities that attackers can exploit.
Impact réel
Real-world CVEs caused by CWE-393
-
DNS server returns wrong response code for non-existent AAAA record, which effectively says that the domain is inaccessible.
-
Hardware-specific implementation of system call causes incorrect results from geteuid.
-
Chain: System call returns wrong value (CWE-393), leading to a resultant NULL dereference (CWE-476).
-
chain: incorrect "goto" in Apple SSL product bypasses certificate validation, allowing Adversary-in-the-Middle (AITM) attack (Apple "goto fail" bug). CWE-705 (Incorrect Control Flow Scoping) -> CWE-561 (Dead Code) -> CWE-295 (Improper Certificate Validation) -> CWE-393 (Return of Wrong Status Code) -> CWE-300 (Channel Accessible by Non-Endpoint).
Comment les attaquants l'exploitent
Parcours de l'attaquant étape par étape
- 1
Identifier un chemin de code qui traite des entrées non fiables sans validation.
- 2
Élaborer une charge utile qui exploite le comportement non sécurisé — injection, traversal, débordement ou abus de logique.
- 3
Délivrer la charge utile via une requête normale et observer la réaction de l'application.
- 4
Itérer jusqu'à ce que la réponse divulgue des données, exécute le code de l'attaquant ou élève les privilèges.
Exemple de code vulnérable
Vulnerable Java
In the following example, an HTTP 404 status code is returned in the event of an IOException encountered in a Java servlet. A 404 code is typically meant to indicate a non-existent resource and would be somewhat misleading in this case.
try {
```
// something that might throw IOException*
...} catch (IOException ioe) {
```
response.sendError(SC_NOT_FOUND);
} 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-393
- 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-393
CWE-393
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-393 ?
Quelle est la gravité de CWE-393 ?
Quels langages ou plateformes sont affectés par CWE-393 ?
Comment puis-je prévenir CWE-393 ?
Comment Plexicus détecte et corrige CWE-393 ?
Où puis-je en savoir plus sur CWE-393 ?
Frequently asked questions
Qu'est-ce que CWE-393 ?
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.
Quelle est la gravité de CWE-393 ?
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-393 ?
MITRE n'a pas spécifié les plateformes affectées pour ce CWE — il peut s'appliquer à la plupart des stacks applicatives.
Comment puis-je prévenir CWE-393 ?
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-393 ?
Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-393 à 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-393 ?
MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/393.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.
Faiblesses associées
Weaknesses related to CWE-393
CWE-684 Parent
Incorrect Provision of Specified Functionality
This weakness occurs when software behaves differently than its documented specifications, which can mislead users and create security…
CWE-1245 Frère
Improper Finite State Machines (FSMs) in Hardware Logic
This vulnerability occurs when hardware logic contains flawed Finite State Machines (FSMs). Attackers can exploit these design errors to…
CWE-392 Frère
Missing Report of Error Condition
This vulnerability occurs when a system fails to properly signal that an error has happened. Instead of returning a clear error code,…
CWE-440 Frère
Expected Behavior Violation
This weakness occurs when a software component, such as a function, API, or feature, fails to act as documented or intended. The system's…
CWE-446 Frère
UI Discrepancy for Security Feature
This vulnerability occurs when a user interface incorrectly displays a security feature as active or properly configured, misleading users…
CWE-451 Frère
User Interface (UI) Misrepresentation of Critical Information
This vulnerability occurs when a user interface fails to accurately display or highlight crucial information, potentially misleading users…
CWE-912 Frère
Hidden Functionality
Hidden functionality refers to undocumented features, commands, or code within a product that are not part of its official specification…
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.