Forty-two thousand. That is how many OpenClaw instances security researchers found running on the public internet with zero authentication earlier this year. No password. No token. No gateway lock. Just an open door to a system that can read files, execute commands, and talk to the internet on your behalf.
And every single one of those deployments was someone who thought they were being smart by self-hosting.
The Default Problem
OpenClaw ships with authentication disabled. The docs say to enable it. The setup guide mentions it. And 42,000 people did not read the docs.
This is not an OpenClaw problem. This is a pattern as old as software itself. MongoDB had the same issue in 2017. Redis had it. Elasticsearch had it. Every tool that ships with "authentication: off" as the default eventually generates a headline about thousands of exposed instances, followed by a patch that turns it on by default, followed by complaints from developers who liked it the old way.
The cycle is so predictable it should have its own RFC.
Convenience Is the Enemy
The reason defaults ship insecure is always the same: developer experience. Nobody wants to deal with auth tokens during local testing. Nobody wants to configure TLS before their hello-world tutorial works. The friction of security slows down the getting-started guide, and the getting-started guide is how you win adoption.
So the trade-off gets made. Ship it open, document the lockdown steps, assume responsible adults will read the documentation before deploying to production.
They will not.
They will follow a YouTube tutorial that ends at "and now it's running!" and never click through to the security hardening section because the thing works and there is always something else to do. Six months later, a Censys scan finds their instance and someone is reading their files through an unauthenticated WebSocket.
The Real Lesson
If you build infrastructure tools and your default configuration is insecure, your software is insecure. Full stop. It does not matter what the documentation says. It does not matter that the responsible user would have changed the setting. The default is the product.
OpenClaw fixed this in their February patch. Auth tokens are now auto-generated if you do not set one. Good. That should have been day one.
But the broader lesson is older and simpler: every system you deploy is one lazy default away from being somebody else's system. The internet does not care about your intentions. It only cares about your configuration.
The number of people who read security documentation before deploying to production is always smaller than you think, and the number of bots scanning for open ports is always larger.
Forty-two thousand. That is not a bug report. That is an audit of human nature.