CVE-2026-33575: Openclaw Information Disclosure Bug

CVE-2026-33575 Overview

OpenClaw before version 2026.3.12 contains a significant security vulnerability where long-lived shared gateway credentials are embedded directly in pairing setup codes. These codes are generated by the /pair endpoint and the openclaw qr command. Attackers who obtain access to leaked setup codes—whether from chat history, log files, or screenshots—can recover and reuse the shared gateway credential outside the intended one-time pairing flow.

This vulnerability falls under CWE-522 (Insufficiently Protected Credentials), representing a critical design flaw in how OpenClaw handles credential management during the device pairing process.

Critical Impact

Attackers can extract long-lived gateway credentials from exposed pairing codes, enabling unauthorized access to OpenClaw gateways without going through proper authentication channels.

Affected Products

• OpenClaw versions prior to 2026.3.12
• OpenClaw Node.js package (all versions before the fix)
• Systems using the /pair endpoint or openclaw qr command

Discovery Timeline

• 2026-03-29 - CVE-2026-33575 published to NVD
• 2026-03-30 - Last updated in NVD database

Technical Details for CVE-2026-33575

Vulnerability Analysis

The vulnerability stems from a fundamental design issue in OpenClaw's pairing mechanism. When users initiate device pairing through either the /pair REST endpoint or the openclaw qr CLI command, the generated setup codes contain embedded gateway credentials that are intended for long-term use.

The core problem is that these credentials persist beyond the initial pairing transaction. In a secure implementation, pairing codes should be ephemeral—valid only for a brief window and tied to a single-use session. Instead, OpenClaw embeds reusable gateway credentials that remain valid even after the pairing process completes.

This design flaw creates multiple exposure vectors: QR codes captured in screenshots, setup codes shared via messaging platforms, credentials logged by monitoring systems, and pairing information stored in chat histories all become potential sources of credential theft.

Root Cause

The root cause is the embedding of persistent, long-lived shared gateway credentials within pairing setup codes rather than using ephemeral, single-use tokens. The application fails to implement proper credential isolation between the pairing flow and the actual gateway authentication mechanism. This violates the principle of least privilege and secure credential handling best practices outlined in CWE-522.

Attack Vector

The attack requires network access and relies on user interaction to succeed. An attacker must first obtain a leaked pairing setup code through one of several means:

1. Chat History Mining: Intercepting or accessing messaging platforms where users shared pairing codes
2. Log File Analysis: Accessing application or system logs that captured pairing requests
3. Screenshot Recovery: Obtaining images of QR codes from device screens or shared screenshots
4. Network Interception: Capturing pairing codes transmitted over inadequately secured channels

Once the setup code is obtained, the attacker can extract the embedded gateway credential and use it to authenticate to the OpenClaw gateway, bypassing the intended one-time pairing flow entirely.

The attack mechanism involves decoding the pairing setup code format to extract the embedded credential, then using this credential directly against the gateway authentication endpoint. For technical details on the vulnerability mechanism, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-33575

Indicators of Compromise

• Unexpected gateway authentication attempts from unrecognized IP addresses or device fingerprints
• Multiple distinct sessions using the same gateway credential from different geographic locations
• Authentication activity outside normal user behavior patterns for paired devices
• Gateway access from devices that were never formally paired through the UI workflow

Detection Strategies

• Monitor gateway authentication logs for credential reuse patterns across multiple source IPs
• Implement anomaly detection for pairing code generation frequency and usage
• Track and alert on gateway connections from unexpected network ranges
• Audit authentication events for credentials used outside their original pairing context
• Review application logs for unusual /pair endpoint access patterns

Monitoring Recommendations

• Enable comprehensive logging for all /pair endpoint requests and openclaw qr command executions
• Implement real-time alerting on gateway authentication events with correlation to pairing records
• Deploy network monitoring to detect credential-based authentication attempts from untrusted sources
• Consider implementing device fingerprinting to detect credential reuse from unpaired devices

How to Mitigate CVE-2026-33575

Immediate Actions Required

• Upgrade OpenClaw to version 2026.3.12 or later immediately
• Rotate all existing gateway credentials that may have been exposed through historical pairing codes
• Review and purge any stored pairing codes from logs, chat systems, and documentation
• Audit access logs for signs of unauthorized gateway access using compromised credentials
• Notify users who may have shared pairing codes to revoke and regenerate their gateway credentials

Patch Information

OpenClaw has released version 2026.3.12 which addresses this vulnerability. The fix implements ephemeral, single-use tokens for the pairing flow rather than embedding long-lived gateway credentials. Users should upgrade immediately and rotate any credentials that may have been exposed.

For detailed patch information and upgrade instructions, see the GitHub Security Advisory GHSA-7h7g-x2px-94hj.

Additional technical context is available from the VulnCheck Advisory.

Workarounds

• Restrict network access to the /pair endpoint using firewall rules or API gateway policies
• Implement strict access controls on systems that generate or store pairing codes
• Establish policies prohibiting the sharing of pairing codes via messaging platforms
• Enable enhanced monitoring and alerting for gateway authentication events
• Consider disabling the pairing functionality entirely until the patch can be applied

# Example: Restrict /pair endpoint access via nginx
location /pair {
    # Allow only from trusted internal networks
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
    
    # Rate limit pairing requests
    limit_req zone=pairing burst=5 nodelay;
}