CWE-483 Base Borrador 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.

Definición

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.
Impacto en el mundo real

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")

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  1. 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. 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. 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. 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.

Ejemplo de código vulnerable

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.

Vulnerable C 
if (condition==true)
  	Do_X();
  	Do_Y();
Ejemplo de código seguro

Secure pseudo

Seguro 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.
Lista de prevención

How to prevent CWE-483

  • Implementation Always use explicit block delimitation and use static-analysis technologies to enforce this practice.
Señales de detección

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.)

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-483 y abre un PR de corrección en menos de 60 segundos.

Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.

Solicitar demo Probar Plexicus gratis
Preguntas frecuentes

Frequently asked questions

¿Qué es 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.

¿Qué gravedad tiene CWE-483?

MITRE califica la probabilidad de explotación como Baja — la explotación es poco frecuente, pero la debilidad debe corregirse cuando se descubra.

¿Qué lenguajes o plataformas se ven afectados por CWE-483?

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

¿Cómo puedo prevenir CWE-483?

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

¿Cómo detecta y corrige Plexicus CWE-483?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-483 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-483?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/483.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-483

CWE-670 Padre

Always-Incorrect Control Flow Implementation

This weakness occurs when a section of code is structured in a way that always executes incorrectly, regardless of input or conditions.…

CWE-480 Hermano

Use of Incorrect Operator

This vulnerability occurs when a developer mistakenly uses the wrong operator in their code, leading to unintended and potentially…

CWE-484 Hermano

Omitted Break Statement in Switch

This vulnerability occurs when a developer forgets to include a 'break' statement inside a switch-case block. Without it, the code…

CWE-617 Hermano

Reachable Assertion

A reachable assertion occurs when an attacker can trigger an assert() statement or similar debugging check, causing the application to…

CWE-698 Hermano

Execution After Redirect (EAR)

Execution After Redirect (EAR) occurs when a web application sends a redirect response to a user's browser but continues to run…

CWE-783 Hermano

Operator Precedence Logic Error

This vulnerability occurs when a developer writes a conditional expression where the intended logic is broken due to misunderstanding or…

Recursos

Further reading

Listo cuando tú lo estés

Deja de pagar por desarrollador.
Empieza a cerrar el bucle.

Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.

Comenzar gratis Reservar una demo