CVE-2026-27007
Hash Collision Vulnerability in OpenClaw Sandbox Configuration Arrays
Publication date: 2026-02-20
Last updated on: 2026-02-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openclaw | openclaw | to 2026.2.15 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1254 | The product's comparison logic is performed over a series of steps rather than across the entire string in one operation. If there is a comparison logic failure on one of these steps, the operation may be vulnerable to a timing attack that can result in the interception of the process for nefarious purposes. |
Attack-Flow Graph
AI Powered Q&A
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade OpenClaw to version 2026.2.15 or later, where the vulnerability is fixed by preserving array order during hash normalization.
Until you can upgrade, avoid relying on order-only changes in sandbox configuration arrays (such as Docker dns and binds) to trigger container recreation, as these changes may be ignored and cause stale containers to be reused.
Additionally, consider manually recreating sandbox containers after configuration changes to ensure that stale containers are not reused.
Can you explain this vulnerability to me?
This vulnerability exists in the OpenClaw personal AI assistant prior to version 2026.2.15. The function `normalizeForHash` used to recursively sort arrays containing only primitive values when generating a hash for sandbox configurations. Because of this, arrays that are sensitive to order, such as Docker DNS and bind mount arrays, would produce the same hash even if their order changed.
OpenClaw uses this hash to decide whether to recreate sandbox containers. Due to the sorting, order-only changes in configuration were ignored, causing stale containers to be reused improperly. This is a configuration integrity issue affecting sandbox recreation behavior.
The issue was fixed in version 2026.2.15 by preserving the original order of arrays during hash normalization, while still sorting object keys for deterministic hashing.
How can this vulnerability impact me? :
[{'type': 'paragraph', 'content': 'This vulnerability can lead to improper reuse of stale sandbox containers because order-only changes in configuration arrays are ignored during hashing. As a result, sandbox containers may not be recreated when they should be, potentially causing the system to run with outdated or incorrect configurations.'}, {'type': 'paragraph', 'content': "This impacts the integrity and correctness of sandbox recreation, which could affect the reliability and expected behavior of the OpenClaw AI assistant's sandboxed environments."}] [1, 2]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability relates to the hashing mechanism of sandbox configuration arrays in OpenClaw versions prior to 2026.2.15. Detection involves identifying if your OpenClaw installation is using a version vulnerable to this issue (≤2026.2.14) and if sandbox containers are being reused incorrectly due to order-insensitive hashing of configuration arrays.
To detect the vulnerability on your system, you can check the OpenClaw version installed and inspect sandbox container recreation behavior when order-only changes are made to configuration arrays such as Docker dns or binds.
Suggested commands include:
- Check OpenClaw version: `openclaw --version` or check package.json/dependency versions if installed as a package.
- Modify the order of Docker sandbox configuration arrays (e.g., dns or binds) and observe if sandbox containers are recreated or not.
- Use logging or debugging to monitor the hash values generated by the `normalizeForHash` function in `src/agents/sandbox/config-hash.ts` if you have access to the source or can instrument the code.
- Check container creation timestamps or IDs to see if containers are stale despite configuration order changes.