CWE-483 Base Brouillon Low likelihood

Incorrect Block Delimitation

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.

Définition

What is CWE-483?

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.

In programming languages like JavaScript, Python, or Go, braces, indentation, or keywords are sometimes optional for single-statement blocks. However, when you intend for multiple statements to execute together—such as within an `if` condition or a loop—omitting the explicit block delimiter means only the first statement is controlled by that condition. Subsequent statements execute unconditionally, creating a critical logic error. This error often manifests as a subtle bug where security-critical operations, like privilege checks or input validation, are bypassed. For example, an access control check might only guard a logging statement while allowing the actual data transaction to proceed without authorization. Always use explicit delimiters for multi-statement blocks to ensure your code's logic and security controls behave as intended.

Impact réel

Real-world CVEs caused by CWE-483

CVE-2014-1266

incorrect indentation of "goto" statement makes it more difficult to detect an incorrect goto (Apple's "goto fail")

Comment les attaquants l'exploitent

Parcours de l'attaquant étape par étape

1
In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.
2
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.
3
In this example, the programmer has indented the Do_Y() statement as if the intention is that the function should be associated with the preceding conditional and should only be called when the condition is true. However, because Do_X() was called on the same line as the conditional and there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.
4
This might not be what the programmer intended. When the condition is critical for security, such as in making a security decision or detecting a critical error, this may produce a vulnerability.

Exemple de code vulnérable

Vulnerable C

In this example, the programmer has indented the statements to call Do_X() and Do_Y(), as if the intention is that these functions are only called when the condition is true. However, because there are no braces to signify the block, Do_Y() will always be executed, even if the condition is false.

Vulnérable C

if (condition==true)
  	Do_X();
  	Do_Y();

Exemple de code sécurisé

Secure pseudo

Sécurisé 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-483

Implementation Always use explicit block delimitation and use static-analysis technologies to enforce this practice.

Signaux de détection

How to detect CWE-483

Automated Static Analysis High

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

CWE-483

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.

Request AI Swarm Pentest

Questions fréquentes

Frequently asked questions

Qu'est-ce que CWE-483 ?

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.

Quelle est la gravité de CWE-483 ?

MITRE évalue la probabilité d'exploitation comme Faible — l'exploitation est rare, mais la faiblesse doit tout de même être corrigée lorsqu'elle est découverte.

Quels langages ou plateformes sont affectés par CWE-483 ?

MITRE lists the following affected platforms: C, C++.

Comment puis-je prévenir CWE-483 ?

Always use explicit block delimitation and use static-analysis technologies to enforce this practice.

Comment Plexicus détecte et corrige CWE-483 ?

Le moteur SAST de Plexicus reconnaît la signature de flux de données de CWE-483 à 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-483 ?

MITRE publie la définition canonique à https://cwe.mitre.org/data/definitions/483.html. Vous pouvez également consulter la documentation OWASP et NIST pour des conseils adjacents.

Faiblesses associées

Weaknesses related to CWE-483

CWE-670 Parent

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.

Réserver un Pentest

Incorrect Block Delimitation

What is CWE-483?

Real-world CVEs caused by CWE-483

Parcours de l'attaquant étape par étape

Vulnerable C

Secure pseudo

How to prevent CWE-483

How to detect CWE-483

Don't catalog this weakness. Prove it's reachable.

Frequently asked questions

Weaknesses related to CWE-483

Always-Incorrect Control Flow Implementation

Use of Incorrect Operator

Omitted Break Statement in Switch

Reachable Assertion

Execution After Redirect (EAR)

Operator Precedence Logic Error

Further reading

Prêt à valider ce qui compte.

Vérifiez si l'AI Swarm Pentest convient à votre environnement.

Demande reçue. Réservez la prochaine étape.

Sample evidence handover

Server-Side Request Forgery in `webhooks/receiver`