6

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-43574

CVE-2026-43574: OpenClaw < 2026.4.12 - Improper Authorization via Empty Approver Lists

OpenClaw before 2026.4.12 contains an improper authorization vulnerability in helper-backed channels where empty resolved approver lists are interpreted as explicit approval authorization. Attackers can resolve pending approvals without proper authorization by exploiting this logic flaw if they know an approval id.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-43574

CVE-2026-43574:

6

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
openclaw	npm	< 2026.4.12	2026.4.12

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability, identified as GHSA-49cg-279w-m73x, allowed an empty list of approvers in OpenClaw to be interpreted as explicit approval authorization. This could permit an unauthorized sender to resolve pending approvals. The analysis of the patch commit 0a105c0900de701d2ee9f1abc96b017afbd0afdd reveals the root cause and the affected functions.

The core of the issue lies in two functions:

createResolvedApproverActionAuthAdapter in src/plugin-sdk/approval-auth-helpers.ts: This function is responsible for creating an authorization adapter. In the vulnerable version, if the list of approvers was empty, it would return a generic { authorized: true } object. This did not carry enough information to distinguish it from a case where a sender was explicitly listed as an approver.
resolveApprovalCommandAuthorization in src/infra/channel-approval-auth.ts: This function consumes the result from the authorization adapter. It incorrectly interpreted the generic { authorized: true } from an empty approver list as an explicit authorization, setting an explicit: true flag. This bypasses further security checks, such as verifying if the sender is an authorized user for the channel.

The patch rectifies this by introducing a mechanism to mark authorizations derived from an empty approver list as 'implicit'.

The createResolvedApproverActionAuthAdapter function is updated to use a new markImplicitSameChatApprovalAuthorization helper. This adds a non-enumerable symbol to the authorization result, effectively tagging it as implicit without changing its structure for most consumers.
The resolveApprovalCommandAuthorization function is updated to use a corresponding isImplicitSameChatApprovalAuthorization helper to check for this tag. If the tag is present, it ensures the explicit flag is set to false, thereby preventing the authorization bypass.

By identifying these two functions, createResolvedApproverActionAuthAdapter and resolveApprovalCommandAuthorization, we can pinpoint the exact locations in the code that would be exercised during an exploit of this vulnerability. These functions would appear in a runtime profile when an approval command is processed under the vulnerable conditions.

Vulnerable functions

createResolvedApproverActionAuthAdapter

src/plugin-sdk/approval-auth-helpers.ts

The `createResolvedApproverActionAuthAdapter` function is vulnerable because when the `resolveApprovers` function returned an empty list, it would return `{ authorized: true }`. This was treated as an explicit approval by consuming functions, leading to a bypass of sender authorization checks. The patch modifies this to return a specially marked object to distinguish this case from an explicit approval.

resolveApprovalCommandAuthorization

src/infra/channel-approval-auth.ts

This function was vulnerable because it did not distinguish between an implicit authorization (due to an empty approver list) and an explicit one. It incorrectly set the `explicit` flag to `true` when `resolved.authorized` was `true`, without considering the source of the authorization. This allowed an unauthorized sender to gain explicit approval. The fix adds a check (`!implicitSameChatAuthorization`) to correctly identify and handle implicit authorizations.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.