Missing authorization in openclaw @openclaw/whatsapp disrupts WhatsApp accounts

@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.

• The npm package @openclaw/whatsapp from vendor openclaw is affected from semver 0 through < 2026.8.1.
• 2026.8.1 is identified as the first patched release and is marked unaffected.
• The record confirms only the package and branch listed above; it does not establish the status of other parallel branches or products.

The flaw is in the generic channel-tool path, which does not preserve the originating sender's owner status when the request reaches the WhatsApp login tool. As a result, the owner-only control is not applied correctly, and an admitted non-owner sender able to steer the tool can request a forced login for a configured account. The tool can return a new QR code, disconnecting or replacing the Gateway's WhatsApp account; completing an unauthorized relink additionally requires the attacker to scan that QR code with another phone. The confirmed preconditions are an admitted sender and the ability to steer the tool; the public sources do not specify the exact request format or internal authorization check.

• The path is remotely reachable through the generic channel-tool route.
• The attacker must be an admitted non-owner sender who can steer the tool; the available assessment describes low complexity and no additional victim interaction for triggering the forced login.
• Complete account relinking is conditional on the attacker scanning the returned QR code with another phone.
• Current enrichment for the record marks exploitation as none and automatable as no. This is an assessment status at the time of recording, not proof that abuse has never occurred.

The flaw lets a non-owner sender invoke a function that changes the login state of a configured WhatsApp account in the Gateway. Confirmed outcomes include disconnecting or replacing the Gateway's WhatsApp account and loss of availability; complete relinking requires the additional step of scanning the QR code with another phone. The record does not establish confidentiality loss or a bypass of WhatsApp transport authentication. The available evidence also does not confirm impact beyond the affected Gateway and configured account.

• The Gateway can lose its configured WhatsApp account connection, disrupting workflows that depend on that channel.
• A non-owner sender can cause an account association change, creating an integrity impact within the integration.
• If the attacker scans the returned QR code with another phone, the account may be relinked without authorization and recovery may take longer.
• The available evidence does not establish message disclosure, data exposure, or a bypass of WhatsApp transport authentication.

1. Upgrade @openclaw/whatsapp to 2026.8.1, the first stable release identified as patched.
2. Before upgrading, disable the WhatsApp login tool after setup where operationally feasible.
3. Restrict agent access to owner-controlled conversations.
4. Do not expose tool-capable agents to non-owner senders while the deployment remains unpatched.
5. After remediation, recheck deployments and sender permissions to ensure the generic channel-tool path cannot give non-owners access to the login tool.

1. Inventory deployments using the @openclaw/whatsapp package and verify the installed semver release.
2. Identify deployments that expose the WhatsApp login tool through the generic channel-tool path, especially where agents can process messages from non-owner senders.
3. Review admitted senders and their tool-control permissions, looking for non-owners with a path to the login tool.
4. Review logs or operational records for forced login requests, new QR codes, Gateway disconnects, account replacement, or relinking. These are precautionary behavior-based checks, not confirmed indicators of compromise.
5. Do not treat the absence of these events as proof of safety because the available sources do not define specific log patterns or IOCs.