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.)
Call to Thread run() instead of start()
This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the…
What is CWE-572?
Real-world CVEs caused by CWE-572
Bisher sind in MITREs Katalog keine öffentlichen CVE-Referenzen mit dieser CWE verknüpft.
Angreiferpfad Schritt für Schritt
- 1
Identifiziere einen Codepfad, der nicht vertrauenswürdige Eingaben ohne Validierung verarbeitet.
- 2
Erzeuge eine Payload, die das unsichere Verhalten auslöst — Injection, Traversal, Overflow oder Logik-Missbrauch.
- 3
Liefere die Payload über einen normalen Request aus und beobachte die Reaktion der Anwendung.
- 4
Iteriere, bis die Antwort Daten preisgibt, Angreifer-Code ausführt oder Berechtigungen eskaliert.
Vulnerable Java
The following excerpt from a Java program mistakenly calls run() instead of start().
Thread thr = new Thread() {
public void run() {
...
}
};
thr.run(); Secure pseudo
// Validate, sanitize, or use a safe API before reaching the sink.
function handleRequest(input) {
const safe = validateAndEscape(input);
return executeWithGuards(safe);
} How to prevent CWE-572
- Implementation Use the start() method instead of the run() method.
How to detect CWE-572
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.
Frequently asked questions
Was ist CWE-572?
This vulnerability occurs when a program incorrectly calls a thread's `run()` method directly, instead of using the `start()` method. This mistake causes the thread's code to execute within the caller's current thread, bypassing the creation of a new, concurrent thread of execution.
Wie gravierend ist CWE-572?
MITRE hat für diese Schwachstelle keine Exploit-Wahrscheinlichkeit veröffentlicht. Behandle sie als mittlere Auswirkung, bis dein Threat Model anderes belegt.
Welche Sprachen oder Plattformen sind von CWE-572 betroffen?
MITRE lists the following affected platforms: Java.
Wie kann ich CWE-572 verhindern?
Use the start() method instead of the run() method.
Wie erkennt und behebt Plexicus CWE-572?
Die SAST-Engine von Plexicus erkennt die Datenfluss-Signatur von CWE-572 bei jedem Commit. Bei einem Treffer öffnet unser Codex-Remedium-Agent einen Fix-PR mit korrigiertem Code, Tests und einer einzeiligen Zusammenfassung für den Reviewer.
Wo erfahre ich mehr über CWE-572?
MITRE veröffentlicht die kanonische Definition unter https://cwe.mitre.org/data/definitions/572.html. Für ergänzende Hinweise kannst du auch die OWASP- und NIST-Dokumentation heranziehen.
Weaknesses related to CWE-572
Incorrect Synchronization
This vulnerability occurs when multiple parts of a program, such as threads or processes, access a shared resource like a variable, file,…
Synchronous Access of Remote Resource without Timeout
This vulnerability occurs when an application makes a synchronous call to a remote service or resource but does not set a timeout, or sets…
Hardware Logic with Insecure De-Synchronization between Control and Data Channels
This vulnerability occurs when a hardware design incorrectly forwards data before its security or permission checks have finished…
EJB Bad Practices: Use of Synchronization Primitives
This vulnerability occurs when an Enterprise JavaBeans (EJB) component improperly uses thread synchronization primitives, violating the…
Further reading
Bereit zu validieren, was zählt.
Plexicus ist Proof-Driven AppSec: validierte Funde, kontextuelles Verständnis und geprüfte Remediation — in Evidenz verankert, mit Ihnen gescoped.