The OpenClaw Security Checklist: 7 Things Businesses Must Configure Before Going Live

OpenClaw is powerful. It is also, by default, insecure.

The project ships configured for developer convenience, not production safety. Authentication is disabled. Credentials sit in plaintext configuration files. Early versions bound the gateway to all network interfaces, including the public internet. And the project has accumulated over 400 published CVEs in under six months of existence.

SecurityScorecard's STRIKE team found 135,000+ exposed instances. 63% of observed deployments lacked authentication. Over 820 malicious skills were confirmed in the ClawHub marketplace. Infostealers including RedLine, Lumma, and Vidar have added OpenClaw file paths to their harvest lists.

If your business is deploying OpenClaw, these are the seven things you must configure before going live.

1. Lock down the network binding

The OpenClaw gateway listens on port 18789. Depending on your version and installation method, it may bind to 0.0.0.0 (all network interfaces, including public-facing addresses) or 127.0.0.1 (localhost only). SecurityScorecard identified this misconfiguration as the root cause of mass exposure across 135,000+ instances.

Verify your binding configuration immediately. Set it to 127.0.0.1. If you need remote access, route it through a reverse proxy with TLS termination or a VPN like Tailscale. Never expose port 18789 directly to the internet.

2. Enable authentication immediately

Authentication is disabled by default on new OpenClaw instances. The gateway is accessible without credentials the moment it starts. Anyone who discovers the port gets full control over your agent, your connected services, and any data the agent can access.

There is an additional risk with reverse proxy deployments: when deployed behind Nginx or Caddy without configuring trustedProxies, all traffic appears to originate from 127.0.0.1 and is treated as trusted. Enable gateway authentication before connecting any services. Rotate the default token. Set pairing codes to expire after a short window.

3. Move credentials out of plaintext

OpenClaw stores API keys, OAuth tokens, and bot credentials in plaintext JSON and Markdown files under ~/.openclaw/ (and legacy paths ~/.clawdbot/). Kaspersky confirmed in February 2026 that the RedLine, Lumma, and Vidar infostealers have added these file paths to their automated collection targets.

Lock down file permissions on the configuration directory so only the OpenClaw process user can read them. For higher-security deployments, use environment variables or a secrets manager to inject credentials at runtime. Note that OpenClaw v2026.4 introduced encrypted credential storage, so updating is also a mitigation.

4. Enable container isolation for skills

OpenClaw extends its capabilities through skills: modular plugins from the ClawHub marketplace. Over 820 malicious skills were found in ClawHub, including infostealers impersonating Gmail, Notion, Slack, and GitHub integrations. By April 2026 the confirmed count had grown to 1,400+.

Enable Docker sandboxing for all skill execution. Set strict resource limits. Disable host network access for containers. Audit every skill before installing it in a production deployment. CVE-2026-24763 demonstrated that command injection within the Docker execution environment is a real attack vector.

5. Disable mDNS broadcasting

OpenClaw broadcasts its presence via mDNS (Bonjour, _openclaw-gw._tcp on port 5353) by default. In full mode, the TXT records include your username, install path, display name, and LAN host address. CVE-2026-26327 showed that clients improperly trusted unauthenticated mDNS TXT records, enabling man-in-the-middle attacks by anyone on the same network segment.

Disable mDNS broadcasting in the configuration. If you need service discovery, use explicit configuration rather than broadcast protocols.

6. Set up monitoring and audit logging

Every action your OpenClaw agent takes should be logged: API calls, file access, network connections, skill executions, and authentication events. Without logging, you have no visibility into what the agent is doing and no ability to detect compromise.

Configure structured logging to a persistent store. Set up alerts for unexpected patterns: unfamiliar API endpoints, new network connections, authentication failures, or skill executions outside normal hours. The STRIKE team found 549 exposed instances correlated with prior breach activity in their initial scan alone, a number that later grew to 53,000+.

7. Keep OpenClaw updated

OpenClaw ships multiple releases per week. Security patches are frequent and critical. CVE-2026-25253 (CVSS 8.8) enabled one-click remote code execution through a browser-based WebSocket hijacking attack. CVE-2026-32922 (CVSS 9.9) allowed a single API call to escalate a pairing token into full admin control with remote code execution. As of May 2026, the project has 400+ published CVEs.

Running an outdated version is one of the most common risk factors. Establish a regular update schedule. Test updates in staging before applying to production. Subscribe to OpenClaw security advisories.

The compliance dimension

The EU AI Act general application date is August 2, 2026, though the Digital Omnibus agreement (reached May 7, 2026) may extend certain high-risk deadlines. Regardless of the specific timeline, businesses deploying autonomous AI agents in the EU need to meet requirements around data handling, transparency, and risk management.

A properly secured OpenClaw installation is not just a security measure. It is a compliance requirement for any business operating in or serving the European market.

The bottom line

These seven configurations are the minimum baseline for any business deployment. They are not advanced hardening. They are the equivalent of locking the front door.

98.6% of exposed OpenClaw instances run on cloud infrastructure. These are businesses, not hobbyists. The businesses that get the most value from OpenClaw are the ones that deploy it correctly from the start.