This vulnerability occurs when a system correctly checks for a lock's existence, but an unauthorized external actor can control or influence that lock.
When an attacker can manipulate a lock—such as a mutex, file lock, or a shared resource used as a lock—they can prevent the application from accessing critical resources or performing essential operations. This effectively creates a denial-of-service condition, as the system remains blocked waiting for a lock it cannot acquire. The severity of this issue escalates if the attacker can hold the lock indefinitely, leading to a permanent disruption of service. Developers must ensure that lock mechanisms are secured within the application's trusted boundary and cannot be created, modified, or sustained by untrusted external sources.
Impact: DoS: Resource Consumption (Other)
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.
php
//attempt to get logfile lock* if (flock($logfile, LOCK_EX)) { ``` fwrite($logfile,$message);
php