CVE-2026-100532 in openclaw
Summary
by MITRE • 09/26/2026
@openclaw/whatsapp (npm) before 2026.8.1 exposes the WhatsApp login tool through the generic channel-tool path without preserving the originating sender's owner status, so the owner-only tool boundary is not enforced. An admitted non-owner sender able to steer the tool can request a forced login and receive a new QR code for a configured account, disconnecting the Gateway's WhatsApp account and causing loss of availability; full account relinking additionally requires the attacker to scan the returned QR code with another phone. The issue affects the owner-only tool boundary rather than WhatsApp transport authentication. Fixed in 2026.8.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in @openclaw/whatsapp versions prior to 2026.8.1 represents a critical failure in access control enforcement within the application's channel-tool routing mechanism. Specifically, the software exposes WhatsApp login tools through a generic endpoint that fails to validate or preserve the originating sender's owner status. In secure architectural designs for messaging gateways, administrative functions such as account authentication and session management are strictly segregated from standard user interactions to prevent privilege escalation. This flaw allows any authenticated non-owner user who can steer requests toward this specific tool path to bypass these security boundaries. The core technical deficiency lies in the absence of proper authorization checks that verify whether the requesting entity possesses the necessary privileges to execute administrative actions, effectively treating a regular user request with the same trust level as an administrator's command.
The operational impact of this vulnerability is severe and directly affects service availability and account integrity. An attacker who gains access to the application interface can exploit this misconfiguration to initiate a forced login sequence for any configured WhatsApp Gateway account. Upon triggering this action, the system generates and returns a new QR code intended for scanning by an authorized device. This process inherently disconnects the existing session of the targeted WhatsApp account from the gateway service. Consequently, legitimate users lose access to their messaging capabilities immediately upon the generation of the new credential, resulting in a denial of service condition. The disruption is not merely theoretical; it actively breaks ongoing communications and prevents further message delivery until the account is re-authenticated by an owner who can physically scan the maliciously generated QR code with another phone device.
From a threat modeling perspective, this vulnerability aligns closely with CWE-269 Improper Privilege Assignment, as the system incorrectly assigns administrative capabilities to users lacking those privileges. It also reflects aspects of CWE-862 Missing Authorization, where the application fails to enforce proper access controls on critical resources. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is consistent with techniques involving Account Manipulation and potentially Service Stop or Denial of Service via resource exhaustion through forced re-authentication cycles. The attacker does not need to compromise the underlying WhatsApp transport authentication protocol itself; rather, they exploit a logical flaw in the application layer's handling of user roles and tool routing. This distinction highlights that while the communication channel may be secure, the application logic governing who can invoke specific administrative tools is fundamentally broken.
Mitigation strategies must focus on immediate remediation through software updates combined with robust architectural hardening. The primary resolution involves upgrading to version 2026.8.1 or later, where this access control flaw has been addressed by developers. For environments unable to upgrade immediately due to dependency constraints, temporary mitigations should include implementing strict role-based access control checks at the API gateway level before requests reach the application logic. Additionally, administrators should enforce multi-factor authentication for administrative actions and monitor logs for unusual patterns of QR code generation or session disconnections. It is also advisable to review other generic tool paths within the system to ensure that similar privilege escalation vectors do not exist elsewhere in the codebase, ensuring a comprehensive defense-in-depth approach against logical access control failures.