CWE-414 describes a product that does not check whether a lock is present before performing sensitive operations on a resource. The lock exists. One code path just ignores it.
How it happens
A team adds locking to the main path, then a second entry point, a maintenance routine or an error handler skips it. Another actor holds the lock, and this path writes anyway.
MITRE's example is a product that did not properly check if a lock was present, letting attackers reach functionality they should not (CVE-2004-1056).
What an attacker gains
Per the record: integrity and availability impact, including modified application data, instability and crashes or restarts.
How to find it
MITRE says static analysis can find some instances by modeling data flow. Also:
- List every function that touches the guarded resource, and confirm each one takes or checks the lock.
- Wrap the resource in one accessor so callers cannot skip the check.
How to fix it
- Route all access through a single function that acquires the lock.
- Fail closed: if the lock is held by someone else, wait with a timeout or return an error.
- Add tests that call every entry point while the lock is held.
A worked scenario
Imagine a job runner that takes a lock before writing a report file. A cleanup task added later writes to the same file and never looks at the lock. Most days nothing happens. When both run together, the report is half old and half new, or the write fails and the service restarts. An attacker who can trigger the second path at will turns a rare glitch into a repeatable one. The lesson is that a lock is a convention, and a convention only protects you when every caller follows it.
Quick check
How does this differ from CWE-413?
CWE-413 is about not locking correctly when you must. CWE-414 is about not checking for an existing lock before acting.
