GHSA-GQ83-8Q7Q-9HFX: Race Condition in OpenClaw Sandbox Registry Leads to Data Corruption

The OpenClaw framework maintains the state of active AI agent sandboxes and browser instances in JSON-based registry files (containers.json and browsers.json). These registries are critical for tracking resource allocation, lifecycle management, and cleanup operations. The vulnerability exists within the file I/O logic used to persist changes to these registries.

Prior to version 2026.2.18, the functions responsible for updating the registry did not implement adequate locking mechanisms or atomic write operations. This omission creates a Time-of-Check to Time-of-Use (TOCTOU) race condition (CWE-367) when multiple agent threads or processes attempt to modify the registry simultaneously.

The impact is primarily on data integrity. When the race condition triggers, the registry may revert to a previous state, lose specific entries, or be completely emptied. While this does not directly expose sensitive credentials, it compromises the stability of the agent orchestration layer, causing the system to lose track of running containers. This results in "orphaned" resources that consume system memory and CPU without being accessible or practically manageable by the framework.

The core failure lies in the implementation of the updateRegistry and removeRegistryEntry functions, which relied on a naive read-modify-write pattern without synchronization primitives. The operation followed this sequence:

1. Read: The entire JSON registry file is read from disk into memory.
2. Modify: The in-memory JavaScript object is updated (entries added or removed).
3. Write: The modified object is serialized and written back to the disk, overwriting the original file.

In a concurrent environment, two processes (A and B) may read the file at the same time. If Process A writes its changes first, and Process B writes immediately after, Process B's write operation—based on the stale state it read earlier—overwrites Process A's changes. This constitutes a classic "Lost Update" problem (CWE-362).

Furthermore, the error handling logic in the original readRegistry implementation exacerbated the issue. The function utilized a broad catch block that suppressed exceptions (such as JSON parsing errors or partial reads caused by a concurrent write operation). Upon encountering an error, the function defaulted to returning an empty array []. If this empty state was subsequently written back to disk during an update cycle, the entire registry would be effectively deleted.

The vulnerability remediation required fundamental changes to how OpenClaw handles file persistence. The patch introduces serialization via file locking and ensures atomicity using temporary files.

Vulnerable Logic (Conceptual):

The original code performed direct writes to the target file. There was no mechanism to prevent overlapping I/O operations.

// Vulnerable: Direct asynchronous write without locking
async function updateRegistry(entry) {
  const current = await readRegistry(); // Reads current state
  current.push(entry);
  // If another process writes here, those changes are lost below
  await fs.writeFile(REGISTRY_PATH, JSON.stringify(current));
}

Patched Logic:

The fix in commit cc29be8c9bcdfaecb90f0ab13124c8f5362a6741 introduces a withRegistryLock wrapper. This wrapper ensures that any operation modifying the registry acquires a session-based write lock before proceeding. Additionally, the write operation now writes to a temporary file first and uses fs.rename to replace the registry atomically.

// Fixed: Uses locking and atomic rename
export async function updateRegistry(entry: RegistryEntry) {
  // 1. Acquire Lock
  return withRegistryLock(async () => {
    const current = await readRegistry();
    // ... modify current ...
    
    // 2. Write to temp file
    const tempPath = `${REGISTRY_PATH}.${uuid()}.tmp`;
    await fs.writeFile(tempPath, JSON.stringify(current));
    
    // 3. Atomic replacement
    await fs.rename(tempPath, REGISTRY_PATH);
  });
}

This approach guarantees that even if multiple processes attempt updates, they will be serialized. The atomic rename ensures that readers never encounter a partially written file, eliminating the risk of the "empty array" rollback corruption.

Exploitation of this vulnerability does not require malicious intent; it is often triggered strictly by normal operational load. However, an attacker with the ability to trigger multiple agent workflows could intentionally induce this state to disrupt system availability or hide the presence of malicious containers.

Attack Vector:

1. Trigger: The attacker initiates two or more simultaneous requests that require sandbox creation or deletion (e.g., instructing two agents to start tasks in parallel).
2. Race: The OpenClaw backend spawns concurrent processes to handle these requests. Both processes attempt to update containers.json.
3. Corruption: Due to the race condition, one of the container entries is dropped from the registry, or the file is corrupted.
4. Result: The system loses a reference to a running container. This container continues to consume resources but is no longer visible to sandbox list or cleanup scripts.

The developers included a reproduction case in src/agents/sandbox/registry.test.ts that simulates this behavior by introducing artificial I/O latency (containerDelayMs: 80) to widen the race window, proving that concurrent writes consistently led to data loss in the unpatched version.

The vulnerability affects the integrity and availability of the OpenClaw infrastructure.

• Integrity (High): The primary registry for tracking system state is unreliable. Entries can disappear or revert to previous states without warning. This makes the system's view of reality inconsistent with the actual state of the host machine.
• Availability (Low/Medium): While the service itself may not crash immediately, the accumulation of orphaned containers leads to resource exhaustion (memory/CPU) over time. In a long-running production environment, this necessitates manual intervention to identify and kill untracked processes.
• Confidentiality (None): The vulnerability does not allow unauthorized access to sensitive data within the registry or the containers.

CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L (Base Score: 6.6). The Attack Complexity is rated High (AC:H) because the successful trigger depends on specific timing conditions (race window), though in high-traffic environments, this condition is frequently met.