CWE-583 is a Java weakness: finalize() is declared public. MITRE frames it as a violation of secure coding principles for mobile code.
A product should never call finalize() explicitly, except to call super.finalize() inside its own finalizer. In mobile code, where untrusted code runs in the same JVM, a public finalize() becomes a method anyone can call. An attacker can invoke it to trigger cleanup at a time of their choosing, leaving your object half torn down.
How it happens
MITRE's example is a Java applet:
// Vulnerable
public final class urlTool extends Applet {
public void finalize() {
...
}
}
The override widened access from protected to public for no benefit.
What an attacker gains
MITRE lists confidentiality, integrity and availability consequences: altered execution logic, execution of unauthorized code or commands, and modified application data. Calling finalize() directly can release resources or null out state while the object is still in use.
How to find it
Automated static analysis can find some instances, per MITRE. A search for public void finalize works too.
How to fix it
MITRE's mitigation: if you use finalize() as designed, there is no reason to declare it with anything other than protected access.
// Fixed
@Override
protected void finalize() throws Throwable {
try {
releaseResources();
} finally {
super.finalize();
}
}
Modern Java deprecates finalizers. Prefer AutoCloseable and Cleaner.
Quick check
What access level should finalize() have?
Protected, which is how Object declares it.
The free in-browser scan at gold.safeguard.sh/scan lists the dependencies in your manifest. No login is needed, the file stays on your machine, and it handles up to 100 dependencies.
