CVE-2026-22175
Openclaw ≤ 2026.2.23
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-22175 is a high-severity Incomplete List of Disallowed Inputs (CWE-184) vulnerability in Openclaw Openclaw. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 26th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-22175 is an exec approval bypass vulnerability in OpenClaw versions prior to 2026.2.23. In allowlist mode, the flaw allows allow-always grants to be circumvented through unrecognized multiplexer shell wrappers, such as busybox and toybox sh -c commands. Attackers can invoke arbitrary payloads under these wrappers to satisfy stored allowlist rules, bypassing intended execution restrictions. The issue is classified as CWE-184 and carries a CVSS v3.1 base score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N).
The vulnerability can be exploited by an attacker with low privileges (PR:L) over the network (AV:N) with low attack complexity (AC:L) and no user interaction (UI:N). By crafting commands that leverage the multiplexer wrappers, the attacker bypasses allowlist checks, enabling execution of unauthorized payloads. This results in high confidentiality impact (C:H), such as potential access to sensitive data, and low integrity impact (I:L), with no availability disruption (A:N).
Mitigation is provided in OpenClaw version 2026.2.23. Patch details are available in the GitHub commit at https://github.com/openclaw/openclaw/commit/a67689a7e3ad494b6637c76235a664322d526f9e. Additional guidance appears in the GitHub security advisory at https://github.com/openclaw/openclaw/security/advisories/GHSA-gwqp-86q6-w47g and the VulnCheck advisory at https://www.vulncheck.com/advisories/openclaw-exec-approval-bypass-via-unrecognized-multiplexer-shell-wrappers.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-12718
Vulnerability Data
OpenClaw versions prior to 2026.2.23 contain an exec approval bypass vulnerability in allowlist mode where allow-always grants could be circumvented through unrecognized multiplexer shell wrappers like busybox and toybox sh -c commands. Attackers can exploit this by invoking arbitrary payloads…
more
under the same multiplexer wrapper to satisfy stored allowlist rules, bypassing intended execution restrictions.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 2 hardening rules · 1 OS baseline
V3.5.2V4.4.2V16.2.5
Mitigating Controls (NIST 800-53 r5) AI
SI-10 requires validity checks on inputs, which structurally replaces incomplete deny-lists with complete allow-list or sanitization logic.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require complete, positive input validation instead of incomplete denylists.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can discover missing input checks, but does not prevent the weakness during development.
Application security requirements can mandate complete input validation rules, but the control itself does not prescribe how to build those rules.
Secure architecture principles include robust input validation design, yet the control is broader than this single weakness.
Secure coding standards directly require exhaustive allow-lists or complete deny-lists for inputs, addressing the root cause of incomplete disallowed-input lists.