The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control.
View on MITREThis prevents the product from acting on associated resources or performing other behaviors that are controlled by the presence of the lock. Relevant locks might include an exclusive lock or mutex, or modifying a shared resource that is treated as a lock. If the lock can be held for an indefinite period of time, then the denial of service could be permanent.
When an attacker can control a lock, the program may wait indefinitely until the attacker releases the lock, causing a denial of service to other users of the program. This is especially problematic if there is a blocking operation on the lock.
Use any access control that is offered by the functionality that is offering the lock.
Use unpredictable names or identifiers for the locks. This might not always be possible or feasible.
Consider modifying your code to use non-blocking synchronization methods.
Automated code analysis techniques might not be able to reliably detect this weakness, since the application's behavior and general security model dictate which resource locks are critical. Interpretation of the weakness might require knowledge of the environment, e.g. if the existence of a file is used as a lock, but the file is created in a world-writable directory.
This code tries to obtain a lock for a file, then writes to it.
PHP by default will wait indefinitely until a file lock is released. If an attacker is able to obtain the file lock, this code will pause execution, possibly leading to denial of service for other users. Note that in this case, if an attacker can perform an flock() on the file, they may already have privileges to destroy the log file. However, this still impacts the execution of other programs that depend on flock().
Program can not execute when attacker obtains a lock on a critical output file.
View DetailsProgram can not execute when attacker obtains a lock on a critical output file.
View DetailsCritical file can be opened with exclusive read access by user, preventing application of security policy. Possibly related to improper permissions, large-window race condition.
View DetailsChain: predictable file names used for locking, allowing attacker to create the lock beforehand. Resultant from permissions and randomness.
View DetailsProduct does not check if it can write to a log file, allowing attackers to avoid logging by accessing the file using an exclusive lock. Overlaps unchecked error condition. This is not quite CWE-412, but close.
View DetailsNo relationship information available for this CWE.
CWE-412: Unrestricted Externally Accessible Lock is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product properly checks for the existence of a lock, but the lock can be externally controlled or influenced by an actor that is outside of the intended sphere of control. This prevents the product from acting on associated resources or performing other behaviors that are controlled by the presence of the lock. Relevant locks might include an exclusive lock or mutex, or modifying a shared resource that is treated as a lock. If the lock can be held for an indefinite period of time, then the denial of service could be permanent.
If exploited, CWE-412 (Unrestricted Externally Accessible Lock) it can compromise Availability, leading to outcomes such as DoS: Resource Consumption (Other).
Recommended mitigations for CWE-412 include: Use any access control that is offered by the functionality that is offering the lock. Use unpredictable names or identifiers for the locks. This might not always be possible or feasible. Consider modifying your code to use non-blocking synchronization methods.
CWE-412 can be detected using White Box. Combining automated tooling with manual review typically yields the best coverage.
CWE-412 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-412, including CVE-2001-0682, CVE-2002-1914, CVE-2002-1915, CVE-2002-0051 and CVE-2000-0338. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-412 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.