OpenWA EUVD-2026-86295

Requires a valid VIEWER-role OpenWA API key scoped to the target session (PR:L) that can reach the GET /api/sessions/{sessionId}/groups/{groupId}/invite-code REST endpoint or the GroupGetInviteCode MCP tool; the session must be started and the account must administer the target group so an invite code exists. Exploitation is only meaningful in deployments that issue VIEWER keys to parties who should NOT be able to add accounts to administered groups - the vendor states OPERATOR and ADMIN access to this capability is intended. Single-operator or trusted-tenant deployments are not practically at risk. No user interaction is required, and the leaked invite code grants group access that persists even after the VIEWER key is revoked.

This is a genuine but moderate-severity broken-authorization flaw (CWE-863), not a critical remote-code issue. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N, base 6.4) is internally consistent with the description: network-reachable REST/MCP endpoint, low complexity, requiring a valid but low-privilege VIEWER API key (PR:L), no user interaction, with a scope change (S:C) because the leaked invite code grants access to the WhatsApp group - a system outside OpenWA's authorization boundary. Confidentiality and integrity are Low and availability None, matching 'retrieve an invite code / join and post to a group' rather than full compromise. No EPSS score, no CISA KEV listing, and no public PoC were provided, so there is no signal of active or automated exploitation - no public exploit identified at time of analysis. The most important limiter is baked into the vendor's own framing: the issue only matters in deployments that hand VIEWER keys to parties who should not be able to add accounts to administered groups; in single-tenant or trusted-operator setups the practical risk approaches zero. Net: patch on a normal cycle, prioritize if you delegate scoped VIEWER keys to untrusted third parties.

An organization issues a session-scoped VIEWER API key to a third party for read-only monitoring of WhatsApp traffic. That party calls GET /api/sessions/{sessionId}/groups/{groupId}/invite-code (or the GroupGetInviteCode MCP tool), receives a live invite code, and shares it with an external WhatsApp account that then joins the administered group to read and post messages - retaining access even after the VIEWER key is later revoked. No public exploit code is known, but exploitation is a single authenticated HTTP GET requiring no special tooling.