Base weakness

Draft

CWE-562: Return of Stack Variable Address

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

Last updated May 1, 2026

7

Recorded CVEs

With this primary weakness

0

KEVs

In the CISA KEV catalog

Not rated

Likelihood of exploit

Per MITRE

Base

Abstraction

MITRE classification

Overview

Because local variables are allocated on the stack, when a program returns a pointer to a local variable, it is returning a stack address. A subsequent function call is likely to re-use this same stack address, thereby overwriting the value of the pointer, which no longer corresponds to the same variable since a function's stack frame is invalidated when it returns. At best this will cause the value of the pointer to change unexpectedly. In many cases it causes the program to crash the next time the pointer is dereferenced.

Real-world CVEs

7 recorded CVEs are caused by CWE-562 (Return of Stack Variable Address). The highest-severity and most recent are shown first. 2 new CWE-562 CVEs have been recorded so far in 2026.

CVE-2024-4418

Libvirt: stack use-after-free in virnetclientioeventloop()

Medium · CVSS 6.2 · EPSS 71th

2024-05-08

CVE-2026-3591

A stack use-after-return flaw in SIG(0) handling code may enable ACL bypass

Medium · CVSS 5.4 · EPSS 8th

2026-03-25

CVE-2026-26399

Medium · CVSS 5.3 · EPSS 1th

Common consequences

What can happen when CWE-562 is exploited.

Read Memory, Modify Memory, Execute Unauthorized Code or Commands, DoS: Crash, Exit, or Restart

Affects: Availability, Integrity, Confidentiality

If the returned stack buffer address is dereferenced after the return, then an attacker may be able to modify or read memory, depending on how the address is used. If the address is used for reading, then the address itself may be exposed, or the contents that the address points to. If the address is used for writing, this can lead to a crash and possibly code execution.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Applies to

Languages

C

C++

How to prevent it

Practical mitigations for CWE-562, grouped by where in the lifecycle they apply.

Implementation

Fix the code so that it does not return a stack address.

How to detect it

Fuzzing

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.

Effectiveness: High

Automated Static Analysis

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

Effectiveness: High

Automated Dynamic Analysis

Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].

Effectiveness: Moderate

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

The following function returns a stack address.

Vulnerable example

c

char* getName() {

Illustrative examples

Real CVEs that MITRE cites as examples of this weakness.

CVE-2024-33045 — product returns stack variable address, leading to memory corruption

Terminology & mappings

Mapped taxonomies

CERT C Secure Coding: Declare objects with appropriate storage durations (DCL30-C) — CWE More Specific fit
CERT C Secure Coding: Do not call putenv() with a pointer to an automatic variable as the argument (POS34-C)
Software Fault Patterns: Glitch in computation (SFP1)

Frequently asked questions

Common questions about CWE-562.

What is CWE-562?

A function returns the address of a stack variable, which will cause unintended program behavior, typically in the form of a crash.

What CVEs are caused by CWE-562?

7 recorded CVEs are attributed to CWE-562, including CVE-2022-41837, CVE-2021-21798, CVE-2024-33045.

How do you prevent CWE-562?

Fix the code so that it does not return a stack address.

How is CWE-562 detected?

Fuzzing: 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.

What are the consequences of CWE-562?

Exploiting CWE-562 can lead to: Read Memory, Modify Memory, Execute Unauthorized Code or Commands, DoS: Crash, Exit, or Restart.

Is CWE-562 actively exploited?

7 recorded CVEs are caused by CWE-562; none are currently in CISA's KEV catalog of actively exploited flaws.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Stay ahead of CWE-562

Get alerted the moment a new CWE-562 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.

Start free See pricing