CWE-667 Class Draft

Improper Locking

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…

Definition

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.
Real-world impact

Real-world CVEs caused by CWE-667

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

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

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

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

  • OS kernel performs an unlock in some incorrect circumstances, leading to panic.

  • OS deadlock

  • OS deadlock involving 3 separate functions

  • deadlock in library

How attackers exploit it

Step-by-step attacker path

  1. 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. 2

    This code tries to obtain a lock for a file, then writes to it.

  3. 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. 4

    The following function attempts to acquire a lock in order to perform operations on a shared resource.

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

Vulnerable code example

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;
  }
Secure code example

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.

Secure 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.
Prevention checklist

How to prevent CWE-667

  • Implementation Use industry standard APIs to implement locking mechanism.
Detection signals

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

Plexicus auto-fix

Plexicus auto-detects CWE-667 and opens a fix PR in under 60 seconds.

Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.

Frequently asked questions

Frequently asked questions

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.

How serious is CWE-667?

MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.

What languages or platforms are affected by CWE-667?

MITRE has not specified affected platforms for this CWE — it can apply across most application stacks.

How can I prevent CWE-667?

Use industry standard APIs to implement locking mechanism.

How does Plexicus detect and fix CWE-667?

Plexicus's SAST engine matches the data-flow signature for CWE-667 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.

Where can I learn more about CWE-667?

MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/667.html. You can also reference OWASP and NIST documentation for adjacent guidance.

Related weaknesses

Weaknesses related to CWE-667

CWE-662 Parent

Improper Synchronization

This vulnerability occurs when a multi-threaded or multi-process application allows shared resources to be accessed by multiple threads or…

CWE-1058 Sibling

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

This happens when a method or function, designed to run in a multi-threaded environment, accesses or modifies a non-final static variable…

CWE-1096 Sibling

Singleton Class Instance Creation without Proper Locking or Synchronization

This flaw occurs when a Singleton class is implemented without proper thread-safe controls, allowing multiple instances to be created in…

CWE-366 Sibling

Race Condition within a Thread

This vulnerability occurs when two or more threads within the same application access and manipulate a shared resource (like a variable,…

CWE-543 Sibling

Use of Singleton Pattern Without Synchronization in a Multithreaded Context

This vulnerability occurs when a singleton pattern is implemented in a multithreaded application without proper synchronization,…

CWE-567 Sibling

Unsynchronized Access to Shared Data in a Multithreaded Context

This vulnerability occurs when multiple threads in an application can read and modify shared data, like static variables, without proper…

CWE-663 Sibling

Use of a Non-reentrant Function in a Concurrent Context

This vulnerability occurs when a program uses a function that is not safe for reentrancy within a concurrent environment, such as…

CWE-764 Sibling

Multiple Locks of a Critical Resource

This vulnerability occurs when a critical resource, such as a file, data structure, or connection, is locked more times than the software…

CWE-820 Sibling

Missing Synchronization

This vulnerability occurs when multiple parts of your application (like threads or processes) use the same resource—such as a variable,…

Ready when you are

Don't Let Security
Weigh You Down.

Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.