Summary
OpenWA's WebSocket event gateway may disclose WhatsApp session QR codes to VIEWER API keys that subscribe to the relevant event, despite QR retrieval being restricted to the OPERATOR role. If a permitted session is waiting for pairing, an exposed QR code could let the key holder link an external device and read or send messages outside OpenWA's controls and audit trail.
Affected context
The issue occurs in OpenWA deployments where:
- The
/eventsWebSocket gateway is enabled - A session is waiting to be paired
- A VIEWER API key can subscribe by event name or through a wildcard subscription
- Authorization for the
session.qrevent is weaker than authorization for the corresponding QR API endpoint
Keys constrained with allowedSessions remain limited to those sessions. Deployments that issue only OPERATOR or ADMIN keys are not affected by this specific exposure.
Exploit preconditions
- Attack surface: The OpenWA
/eventsWebSocket gateway - Required access: A valid API key with VIEWER-level access and permission to observe the affected session
- Trigger point: A
session.qrevent is emitted while the session awaits pairing - Why exploitation is possible: Event subscription authorization does not consistently enforce the stronger role requirement applied to direct QR retrieval
Why this happens
The underlying flaw is an authorization mismatch between related access paths. The WebSocket gateway exposes a sensitive session QR event to subscribers whose role would not permit retrieving the same information through the HTTP API. This represents CWE-862: Missing Authorization, because a server-side authorization check is absent or insufficient at a sensitive event delivery boundary.
Potential impact
- An attacker with suitable VIEWER access may link an external device to an allowed WhatsApp session
- The attacker could read messages associated with the linked account
- The attacker could send messages while operating outside OpenWA's audit trail
- The affected WhatsApp account or session could be compromised
- Business communications and connected workflows may be exposed or misused
General mitigation guidance
Mitigation generally focuses on enforcing consistent, server-side authorization for sensitive events and equivalent API operations.
Defensive patterns include:
- Require an OPERATOR-level authorization decision before emitting session QR events
- Apply the same session and role checks to direct endpoints, WebSocket subscriptions, and wildcard subscriptions
- Treat QR codes and pairing artifacts as highly sensitive credentials
- Default new API keys to the least privilege needed and restrict them to specific sessions where possible
- Prevent VIEWER roles from receiving operational secrets or account-linking material
- Preserve authorization decisions and sensitive-event access in security logs
- Invalidate or rotate pairing artifacts when exposure is suspected
How teams detect issues like this
Detection approaches may include:
- Static and architectural analysis comparing authorization checks across HTTP and WebSocket handlers
- Code review for event subscription paths that rely only on event names or wildcard filters
- Tests verifying that each role receives only events authorized for its privilege level
- Policy checks ensuring sensitive session artifacts are excluded from viewer-scoped channels
- Runtime monitoring for QR-event delivery to low-privilege keys and unusual device-linking activity
- Automated security testing of wildcard subscriptions and session-scoping rules
