What are the consequences of CWE-586?

Exploiting CWE-586 can lead to: Unexpected State, Quality Degradation.

RadicalNotion.AI

Log in Start free

Log in

Log in Start free

Base weakness

Draft

CWE-586: Explicit Call to Finalize()

The product makes an explicit call to the finalize() method from outside the finalizer.

Last updated May 1, 2026

0

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

While the Java Language Specification allows an object's finalize() method to be called from outside the finalizer, doing so is usually a bad idea. For example, calling finalize() explicitly means that finalize() will be called more than once: the first time will be the explicit call and the last time will be the call that is made after the object is garbage collected.

Common consequences

What can happen when CWE-586 is exploited.

Unexpected State, Quality Degradation

Affects: Integrity, Other

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

Applies to

Languages

Java

How to prevent it

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

Implementation

Do not make explicit calls to finalize().

How to detect it

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

Code examples

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

The following code fragment calls finalize() explicitly:

Vulnerable example

java

// time to clean up

Terminology & mappings

Mapped taxonomies

The CERT Oracle Secure Coding Standard for Java (2011): Do not use finalizers (MET12-J)
Software Fault Patterns: Use of an improper API (SFP3)

Frequently asked questions

Common questions about CWE-586.

What is CWE-586?: The product makes an explicit call to the finalize() method from outside the finalizer.
How do you prevent CWE-586?: Do not make explicit calls to finalize().
How is CWE-586 detected?: 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.)
What are the consequences of CWE-586?: Exploiting CWE-586 can lead to: Unexpected State, Quality Degradation.

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-586

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

Start free See pricing