What Happened
OpenClaw, a self-hosted AI platform, had a vulnerability that allowed malicious websites to hijack local instances through brute-force password attacks. The attack was simple: a user visits a compromised website, and JavaScript code on that page connects to the OpenClaw WebSocket interface running on localhost. The attacker could then brute-force the management password at hundreds of attempts per second, gain control of the local instance, and exfiltrate sensitive data or manipulate the AI platform's behavior.
Oasis Security discovered and disclosed the vulnerability. OpenClaw released a fix in version 2026.2.26.
Timeline
The exact discovery and disclosure dates are not public, but the sequence is more important:
- Oasis Security researchers identified the WebSocket interface exposure.
- They demonstrated the brute-force capability.
- Responsible disclosure to OpenClaw.
- Patch released in version 2026.2.26.
- Public disclosure after patch availability.
The patch was released quickly, demonstrating effective vulnerability disclosure when both parties act responsibly.
Which Controls Failed or Were Missing
Authentication rate limiting: The WebSocket interface accepted password attempts at hundreds per second without throttling or account lockout. A six-character alphanumeric password has 56 billion combinations, but at 500 attempts per second, a four-character space can be exhausted in hours.
Origin validation: The WebSocket interface didn't verify that connection requests came from legitimate sources. Any website loaded in the user's browser could attempt to connect to localhost:port. Localhost services should authenticate the requesting origin, especially when they expose management functions.
Default credentials or weak password policy: The platform allowed passwords weak enough to brute-force quickly. Strong passphrases or minimum entropy requirements would make such attacks computationally infeasible.
Network binding: The service was accessible to browser JavaScript. Some localhost services bind to 127.0.0.1 in ways that prevent cross-origin access or require additional authentication tokens.
What the Standards Require
OWASP ASVS v4.0.3, Section 2.2 (Authentication): Requirement 2.2.1 mandates anti-automation controls to prevent credential stuffing and brute force attacks. Hundreds of authentication attempts per second with no throttling violate this requirement. Rate limiting is needed at the application layer.
OWASP ASVS v4.0.3, Requirement 4.2.2: WebSocket connections must implement the same authentication and authorization controls as HTTP endpoints. The localhost WebSocket interface needed to verify the origin header and reject connections from unexpected sources.
NIST 800-53 Rev 5, IA-5(1): Password-based authentication must enforce minimum complexity requirements. Accepting four-character passwords does not meet baseline controls. The control specifies enforcing "minimum password complexity" and protecting against "commonly used, expected, or compromised" passwords.
ISO/IEC 27001:2022, Annex A.9.4.3: Password management systems must force users to select quality passwords and protect them during storage and transmission. The control objective is clear: password authentication must resist automated attacks.
PCI DSS v4.0.1, Requirement 8.3.4: After six failed authentication attempts, lock the account for at least 30 minutes or until an administrator unlocks it. This principle is universal for systems handling sensitive data.
Lessons and Action Items for Your Team
Implement rate limiting on all authentication endpoints. Start with a rule: after five failed attempts from the same source within 60 seconds, introduce a 30-second delay. After ten attempts, lock the account or IP for 15 minutes. This applies to WebSocket interfaces, REST APIs, and web forms.
Validate WebSocket origins. Check the Origin header when accepting a WebSocket connection. For localhost services, maintain an allowlist of acceptable origins (usually just file:// and http://localhost). Reject everything else.
Bind localhost services to 127.0.0.1 with authentication tokens. If your service must expose a management interface locally, don't rely on password authentication alone. Generate a random 256-bit token at installation, store it securely, and require it with every request.
Enforce password complexity at setup. Require passwords to be at least 12 characters long. Use a library like zxcvbn to estimate password strength and reject weak passwords. Consider defaulting to token-based authentication.
Audit all localhost interfaces. Run netstat -tuln or ss -tuln on your systems. Document every listening port. For each one, determine who can connect, what authentication is required, and what happens after multiple failed passwords.
Test your rate limiting. Write a script that attempts 100 authentication requests per second against your staging environment. If it doesn't trigger a lockout or rate limit within 10 seconds, your controls need improvement.
Review third-party AI platforms before deployment. If evaluating OpenClaw or similar tools, ask the vendor about localhost hijacking prevention, rate limiting, and WebSocket origin validation. Verify fixes in version 2026.2.26 or later before deployment.
The ClawJacked vulnerability exploited basic authentication failures. Your team can prevent such attacks with focused work on rate limiting and origin validation.
