CWE-457 Variante Borrador High likelihood

Use of Uninitialized Variable

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.

Definición

What is CWE-457?

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.
In languages like C and C++, local variables declared on the stack are not automatically set to a known value. They contain whatever data was previously in that memory location ('junk data'), which an attacker might be able to influence or read. This can lead to information leaks, crashes, or logic flaws depending on how the program uses this unpredictable value. Using an uninitialized variable often points to a coding mistake, such as a typo or missing initialization logic. Even in languages that provide default values (like zero or null), relying on implicit initialization can introduce security weaknesses if the program's logic isn't explicitly handling the variable's starting state, making outcomes hard to predict and secure.
Impacto en el mundo real

Real-world CVEs caused by CWE-457

  • Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked (CWE-252), causing an uninitialized variable to be checked (CWE-457), returning success to allow authorization bypass for executing a privileged (CWE-863).

  • Chain: A denial of service may be caused by an uninitialized variable (CWE-457) allowing an infinite loop (CWE-835) resulting from a connection to an unresponsive server.

  • Uninitialized variable leads to code execution in popular desktop application.

  • Crafted input triggers dereference of an uninitialized object pointer.

  • Crafted audio file triggers crash when an uninitialized variable is used.

  • Uninitialized random seed variable used.

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  1. 1

    This code prints a greeting using information stored in a POST request:

  2. 2

    This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.

  3. 3

    The following switch statement is intended to set the values of the variables aN and bN before they are used:

  4. 4

    In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

  5. 5

    This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

Ejemplo de código vulnerable

Vulnerable PHP

This code prints a greeting using information stored in a POST request:

Vulnerable PHP
if (isset($_POST['names'])) {
  	$nameArray = $_POST['names'];
  }
  echo "Hello " . $nameArray['first'];
Ejemplo de código seguro

Secure C

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457). To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf(). One solution would be to set test_string to an acceptable default before the conditional:

Seguro C
char *test_string = "Done at the beginning";
 if (i != err_val)
 {

```
  test_string = "Hello World!";
 }
 printf("%s", test_string);
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-457

  • Implementation Ensure that critical variables are initialized before first use [REF-1485].
  • Build and Compilation Most compilers will complain about the use of uninitialized variables if warnings are turned on.
  • Implementation / Operation When using a language that does not require explicit declaration of variables, run or compile the software in a mode that reports undeclared or unknown variables. This may indicate the presence of a typographic error in the variable's name.
  • Requirements Choose a language that is not susceptible to these issues.
  • Architecture and Design Mitigating technologies such as safe string libraries and container abstractions could be introduced.
Señales de detección

How to detect CWE-457

Fuzzing High

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.

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

Preguntas frecuentes

Frequently asked questions

¿Qué es CWE-457?

This vulnerability occurs when a program accesses a variable before it has been assigned a value, leading to unpredictable behavior and potential security risks.

¿Qué gravedad tiene CWE-457?

MITRE califica la probabilidad de explotación como Alta — esta debilidad se explota activamente en la práctica y debe priorizarse para su remediación.

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

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

¿Cómo puedo prevenir CWE-457?

Ensure that critical variables are initialized before first use [REF-1485]. Most compilers will complain about the use of uninitialized variables if warnings are turned on.

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

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-457 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-457?

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

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.