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

Definição

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 no mundo real

Real-world CVEs caused by CWE-483

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

Como os atacantes a exploram

Trajeto do atacante passo a passo

  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.

Exemplo de código vulnerável

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.

Vulnerável C
if (condition==true)
  	Do_X();
  	Do_Y();
Exemplo 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 verificação de prevenção

How to prevent CWE-483

  • Implementation Always use explicit block delimitation and use static-analysis technologies to enforce this practice.
Sinais de deteção

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.

Perguntas frequentes

Frequently asked questions

O que é o 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.

Qual a gravidade do CWE-483?

A MITRE classifica a probabilidade de exploração como Baixa — a exploração é pouco comum, mas a fraqueza deve mesmo assim ser corrigida quando descoberta.

Que linguagens ou plataformas são afetadas pelo CWE-483?

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

Como posso prevenir o CWE-483?

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

Como é que o Plexicus deteta e corrige o CWE-483?

O motor SAST do Plexicus correlaciona a assinatura de fluxo de dados do CWE-483 em cada commit. Quando é encontrada uma correspondência, o nosso agente Codex Remedium abre um PR de correção com o código corrigido, testes e um resumo de uma linha para o revisor.

Onde posso saber mais sobre o CWE-483?

A MITRE publica a definição canónica em https://cwe.mitre.org/data/definitions/483.html. Pode também consultar a documentação da OWASP e do NIST para orientações adjacentes.

Pronto para validar o que importa?

Pronto para validar o que importa.

O Plexicus é Proof-Driven AppSec: achados validados, compreensão contextual e remediação revisada — ancorada em evidência, escopada com você.

Qualificação

Verifique se o AI Swarm Pentest se adequa ao seu ambiente.

Partilhe o contexto mínimo. Vamos rever o escopo e indicar o próximo passo comercial.

Antes de enviar — verifique se se encaixa

0 / 280

Sem compromisso. Se não se encaixa, dizemos.

SAMPLE HANDOVER · ILLUSTRATIVE

Sample evidence handover

A trimmed view of what your team receives at the end of an AI Swarm Pentest engagement. Real engagements include full technical evidence, executive narrative, and a remediation plan.

VALIDATED FINDING Evidence attached

Server-Side Request Forgery in webhooks/receiver

demo-project/sample-app · src/webhooks/receiver.py:42

SeverityHigh CVSS 3.18.6 Priority79 Confirmedvia replay

Untrusted caller-supplied URLs reach an internal egress without an allowlist. Replayed in a sandbox against a fresh authorized target — the same control was validated to fail twice.

REVIEWER-READY REMEDIATION Merge-ready PR

Validate the target URL against an allowlist of permitted hostnames. Reject private/internal IP ranges. Enforce HTTPS only.

plexicus/remediation/webhooks-ssrf 3 changed · 0 new files
42resp = requests.get(target_url)
42+if not is_allowed_host(target_url):
43+  raise WebhookRejected(target_url)
44+resp = requests.get(target_url, timeout=5)
Every engagement hands over:
  • Executive briefing
  • Validated findings list
  • Merge-ready PRs
  • Compliance mapping (NIS2 · DORA · CRA)
Ronda privada Para investidores