CWE-667: Improper Locking

Definición

What is CWE-667?

This vulnerability occurs when a program fails to correctly acquire or release a lock on a shared resource, such as a file, database record, or memory location. This improper synchronization allows other processes or threads to interfere, leading to corrupted data, crashes, or unpredictable behavior.

Locking is a core synchronization technique that prevents multiple threads or processes from modifying a shared resource at the same time. When locking steps are skipped, inconsistent, or incorrectly implemented, one thread's changes can be overwritten or made invisible to another. This race condition often results in data corruption, memory errors, or application instability that is difficult to reproduce and debug. Detecting improper locking manually across a large codebase is challenging, as these flaws are highly dependent on timing and execution paths. While SAST tools can identify common locking patterns, Plexicus uses AI-powered analysis to not only flag these issues but also generate context-aware fixes, helping developers implement correct synchronization efficiently and avoid costly runtime failures.

Impacto en el mundo real

Real-world CVEs caused by CWE-667

CVE-2021-1782

Chain: improper locking (CWE-667) leads to race condition (CWE-362), as exploited in the wild per CISA KEV.
CVE-2009-0935

Attacker provides invalid address to a memory-reading function, causing a mutex to be unlocked twice
CVE-2010-4210

function in OS kernel unlocks a mutex that was not previously locked, causing a panic or overwrite of arbitrary memory.
CVE-2008-4302

Chain: OS kernel does not properly handle a failure of a function call (CWE-755), leading to an unlock of a resource that was not locked (CWE-832), with resultant crash.
CVE-2009-1243

OS kernel performs an unlock in some incorrect circumstances, leading to panic.
CVE-2009-2857

OS deadlock
CVE-2009-1961

OS deadlock involving 3 separate functions
CVE-2009-2699

deadlock in library

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

1
In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized.
2
This code tries to obtain a lock for a file, then writes to it.
3
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().
4
The following function attempts to acquire a lock in order to perform operations on a shared resource.
5
However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason, the function may introduce a race condition into the program and result in undefined behavior.

Ejemplo de código vulnerable

Vulnerable Java

In the following Java snippet, methods are defined to get and set a long field in an instance of a class that is shared across multiple threads. Because operations on double and long are nonatomic in Java, concurrent access may cause unexpected behavior. Thus, all operations on long and double fields should be synchronized.

Vulnerable Java

private long someLongValue;
  public long getLongValue() {
  	return someLongValue;
  }
  public void setLongValue(long l) {
  	someLongValue = l;
  }

Ejemplo de código seguro

Secure C

In order to avoid data races, correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

Seguro C

int f(pthread_mutex_t *mutex) {
  		int result;
  		result = pthread_mutex_lock(mutex);
  		if (0 != result)
  			return result;
```
/* access shared resource */* 
  		
  		
  		return pthread_mutex_unlock(mutex);}

What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.

Lista de prevención

How to prevent CWE-667

Implementation Use industry standard APIs to implement locking mechanism.

Señales de detección

How to detect CWE-667

Automated Static Analysis High

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.)

CWE-667

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.

Request AI Swarm Pentest

Preguntas frecuentes

Frequently asked questions

¿Qué es CWE-667?

This vulnerability occurs when a program fails to correctly acquire or release a lock on a shared resource, such as a file, database record, or memory location. This improper synchronization allows other processes or threads to interfere, leading to corrupted data, crashes, or unpredictable behavior.

¿Qué gravedad tiene CWE-667?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-667?

MITRE no ha especificado plataformas afectadas para esta CWE — puede aplicar a la mayoría de los stacks de aplicaciones.

¿Cómo puedo prevenir CWE-667?

Use industry standard APIs to implement locking mechanism.

¿Cómo detecta y corrige Plexicus CWE-667?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-667 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.

¿Dónde puedo aprender más sobre CWE-667?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/667.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-667

CWE-662 Padre

Listo para validar lo que importa.

Plexicus es Proof-Driven AppSec: hallazgos validados, comprensión contextual y remediación revisada — anclada en evidencia, acotada contigo.

Reservar Pentest

Improper Locking

What is CWE-667?

Real-world CVEs caused by CWE-667

Ruta del atacante paso a paso

Vulnerable Java

Secure C

How to prevent CWE-667

How to detect CWE-667

Don't catalog this weakness. Prove it's reachable.

Frequently asked questions

Weaknesses related to CWE-667

Improper Synchronization

Invokable Control Element in Multi-Thread Context with non-Final Static Storable or Member Element

Singleton Class Instance Creation without Proper Locking or Synchronization

Race Condition within a Thread

Use of Singleton Pattern Without Synchronization in a Multithreaded Context

Unsynchronized Access to Shared Data in a Multithreaded Context

Use of a Non-reentrant Function in a Concurrent Context

Multiple Locks of a Critical Resource

Missing Synchronization

Further reading

Listo para validar lo que importa.

Comprueba si el AI Swarm Pentest encaja en tu entorno.

Solicitud recibida. Reserva el siguiente paso.

Sample evidence handover

Server-Side Request Forgery in `webhooks/receiver`