Vulnerabilities

OpenClaw before 2026.3.11 contains an exec allowlist bypass vulnerability where matchesExecAllowlistPattern improperly normalizes patterns with lowercasing and glob matching that overmatches on POSIX paths. Attackers can exploit the ? wildcard matching across path segments to execute commands or paths not intended by operators.

OpenClaw before 2026.3.12 contains an authentication bypass vulnerability in Feishu webhook mode when only verificationToken is configured without encryptKey, allowing acceptance of forged events. Unauthenticated network attackers can inject forged Feishu events and trigger downstream tool execution by reaching the webhook endpoint.

OpenClaw before 2026.3.12 contains a weak authorization vulnerability in Zalouser allowlist mode that matches mutable group display names instead of stable group identifiers. Attackers can create groups with identical names to allowlisted groups to bypass channel authorization and route messages from unintended groups to the agent.

OpenClaw before 2026.3.11 contains an approval integrity vulnerability where system.run approvals fail to bind mutable file operands for certain script runners like tsx and jiti. Attackers can obtain approval for benign script commands, rewrite referenced scripts on disk, and execute modified code under the approved run context.

OpenClaw before 2026.3.11 contains a session sandbox escape vulnerability in the session_status tool that allows sandboxed subagents to access parent or sibling session state. Attackers can supply arbitrary sessionKey values to read or modify session data outside their sandbox scope, including persisted model overrides.

OpenClaw before 2026.3.11 contains an authorization bypass vulnerability allowing write-scoped callers to reach admin-only session reset logic. Attackers with operator.write scope can issue agent requests containing /new or /reset slash commands to reset targeted conversation state without holding operator.admin privileges.

OpenClaw before 2026.3.11 contains a privilege escalation vulnerability in device.token.rotate that allows callers with operator.pairing scope to mint tokens with broader scopes by failing to constrain newly minted scopes to the caller's current scope set. Attackers can obtain operator.admin tokens for paired devices and achieve remote code execution on connected nodes via system.run or gain unauthorized gateway-admin access.

OpenClaw before 2026.3.11 contains an authorization bypass vulnerability in Discord guild reaction ingestion that fails to enforce member users and roles allowlist checks. Non-allowlisted guild members can trigger reaction events accepted as trusted system events, injecting reaction text into downstream session context.

OpenClaw before 2026.3.12 contains an authorization bypass vulnerability where Feishu reaction events with omitted chat_type are misclassified as p2p conversations instead of group chats. Attackers can exploit this misclassification to bypass groupAllowFrom and requireMention protections in group chat reaction-derived events.

OpenClaw before 2026.3.12 contains an insufficient access control vulnerability in the /config and /debug command handlers that allows command-authorized non-owners to access owner-only surfaces. Attackers with command authorization can read or modify privileged configuration settings restricted to owners by exploiting missing owner-level permission checks.

OpenClaw before 2026.3.11 contains a sandbox boundary bypass vulnerability allowing leaf subagents to access the subagents control surface and resolve against parent requester scope instead of their own session tree. A low-privilege sandboxed leaf worker can steer or kill sibling runs and cause execution with broader tool policies by exploiting insufficient authorization checks on subagent control requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: call set_notification_done() without proc lock<br /> <br /> Consider the following sequence of events on a death listener:<br /> 1. The remote process dies and sends a BR_DEAD_BINDER message.<br /> 2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.<br /> 3. The local process then invokes the BC_DEAD_BINDER_DONE.<br /> Then, the kernel will reply to the BC_DEAD_BINDER_DONE command with a<br /> BR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().<br /> <br /> However, this can result in a deadlock if the current thread is not a<br /> looper. This is because dead_binder_done() still holds the proc lock<br /> during set_notification_done(), which called push_work_if_looper().<br /> Normally, push_work_if_looper() takes the thread lock, which is fine to<br /> take under the proc lock. But if the current thread is not a looper,<br /> then it falls back to delivering the reply to the process work queue,<br /> which involves taking the proc lock. Since the proc lock is already<br /> held, this is a deadlock.<br /> <br /> Fix this by releasing the proc lock during set_notification_done(). It<br /> was not intentional that it was held during that function to begin with.<br /> <br /> I don&amp;#39;t think this ever happens in Android because BC_DEAD_BINDER_DONE<br /> is only invoked in response to BR_DEAD_BINDER messages, and the kernel<br /> always delivers BR_DEAD_BINDER to a looper. So there&amp;#39;s no scenario where<br /> Android userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.