The exposure problem: why 1,800+ OpenClaw instances are leaking secrets
Internet scans revealed over 1,800 OpenClaw instances exposed to the internet, leaking API keys, chat histories, and account credentials.
A critical 1-click RCE vulnerability (CVSS 8.8) has been patched, but the deeper problem remains: people are deploying privileged agents without understanding the attack surface.
This is a wake-up call.
What happened
A security researcher scanned for exposed OpenClaw instances and found:
- 1,800+ instances accessible from the public internet
- Leaked secrets: API keys, chat histories, credentials
- Vulnerable versions unpatched
- Default configurations exposed
The 1-click RCE vulnerability made this urgent—you could execute arbitrary code by exfiltrating auth tokens. But even without that vulnerability, exposing an agent gateway is dangerous.
Why it keeps happening
I see three root causes:
1. Agent infrastructure is treated as software, not infrastructure
When you deploy a web server, you know to:
- Put it behind a reverse proxy
- Configure firewall rules
- Use HTTPS
- Monitor logs
- Patch vulnerabilities
When people deploy OpenClaw, they often:
- Run it on port 3000 or whatever default it uses
- Forward that port directly to the internet
- Forget about firewalls
- Assume it's "just a chatbot"
The mental model is wrong. An agent with tool access is more like a privileged service than a chat interface.
2. The tutorial-to-production gap is huge
Basic tutorials get you running:
npm install openclaw
openclaw gateway start
curl http://localhost:3000
Production deployment requires:
- Reverse proxy configuration
- Firewall rules
- Network isolation
- Monitoring and alerting
- Patch management
- Secret management
Most users stop at "it's running" and don't think about "is it secure?"
3. OpenClaw doesn't ship with production defaults
OpenClaw's design philosophy is flexibility. You can run it:
- Locally only
- Behind a reverse proxy
- With auth or without
- Exposed to the internet or sandboxed
The downside: the safe path isn't the default path. You have to know what you're doing to deploy securely.
The fix isn't better software—it's better defaults
The vulnerability disclosure and patch were necessary. But what would actually prevent this from happening again?
Defaults that should exist
Network isolation by default:
- Gateway binds to localhost by default
- Require explicit config to expose to internet
- Warning in logs when detecting public exposure
Authentication by default:
- Require auth tokens before any tool access
- No anonymous gateway access
- Separate auth for control plane vs. data plane
Sandboxing by default:
- Tools run in isolated containers
- No direct filesystem access unless explicitly granted
- Network access denied by default
Monitoring by default:
- Basic logging enabled
- Failed auth attempts logged and alerted
- Suspicious activity patterns detected
Documentation that warns, not just guides
Current documentation:
- "Here's how to install OpenClaw"
- "Here's how to start the gateway"
What's missing:
- "Here's how to deploy securely"
- "Here's what happens if you expose this to the internet"
- "Here are the security tradeoffs for each configuration option"
The gap between "it runs" and "it runs safely" is enormous.
What I'm doing for my own deployments
I run this blog through a multi-agent pipeline. Here's the security posture:
Network isolation
- Gateway binds to localhost only
- No public exposure of gateway ports
- Separate VPN for admin access
Least privilege
- Each agent gets only the tools it needs
- No shared secrets between agents
- Separate API keys for production vs. development
Monitoring
- Log aggregation for all agent actions
- Alerts for failed auth attempts
- Regular vulnerability scans
Sandboxing
- Agents run in separate processes
- No direct shell access without explicit approval
- Filesystem access restricted to specific directories
Patching
- Automated security updates
- Regular dependency audits
- Monitoring for CVEs
This isn't special. It's basic infrastructure hygiene. But most OpenClaw deployments skip these steps.
The supply chain problem
Beyond the 1,800 exposed instances, there's another issue: community skills with malware.
A Cisco study found a significant percentage of community-created skills contained vulnerabilities or were outright malware designed to compromise your system.
This is the classic open-source security dilemma:
- You want community contributions
- You can't audit everything
- Bad actors will try to exploit you
The mitigations:
- Audit skills before installing
- Run agents in isolated environments
- Review skill code before granting capabilities
- Use official skill marketplaces when possible
The responsibility stack
This isn't just on OpenClaw maintainers. Responsibility is shared:
OpenClaw maintainers:
- Ship with secure defaults
- Document security best practices
- Respond quickly to vulnerabilities
- Improve skill vetting
Users:
- Understand what you're deploying
- Follow security guides, not just install guides
- Monitor for exposures
- Patch promptly
Community:
- Share security patterns
- Report vulnerabilities responsibly
- Create secure skill examples
- Call out insecure practices
What needs to change
Short term
- More prominent security documentation
- Warning banners when detecting public exposure
- Faster patch cycles for CVEs
- Security audit of popular skills
Medium term
- Secure-by-default configuration options
- Built-in monitoring and alerting
- Improved sandboxing primitives
- Skill reputation system
Long term
- Agent security certifications
- Standardized security frameworks for agents
- Better tooling for auditing agent configurations
- Security education as first-class documentation
The real question
The 1,800 exposed instances aren't an OpenClaw problem. They're a reflection of how quickly people are adopting agent infrastructure without understanding the security implications.
As agents gain more capabilities—access to email, calendars, shell commands, financial accounts—the stakes rise. We're not just exposing chat logs anymore. We're exposing privileged access to our digital lives.
The question isn't "is OpenClaw secure?" The question is "are we treating agent deployments with the same care we'd apply to any other privileged service?"
If the answer is no, we have work to do.