OpenClaw gives users yet another reason to be freaked out about security

Text settings Story text Size Small Standard Large Width * Standard Wide Links Standard Orange * Subscribers only Learn more Minimize to nav For more than a month, security practitioners have been warning about the perils of using OpenClaw, the viral AI agentic tool that has taken the development community by storm. A recently fixed vulnerability provides an object lesson for why. OpenClaw, which was introduced in November and now boasts 347,000 stars on Github, by design takes control of a user’s computer and interacts with other apps and platforms to assist with a host of tasks, including organizing files, doing research, and shopping online. To be useful, it needs access—and lots of it—to as many resources as possible. Telegram, Discord, Slack, local and shared network files, accounts, and logged in sessions are only some of the intended resources. Once the access is given, OpenClaw is designed to act precisely as the user would, with the same broad permissions and capabilities. Severe impact Earlier this week, OpenClaw developers released security patches for three high-severity vulnerabilities. The severity rating of one in particular, CVE-2026-33579 , is rated from 8.1 to 9.8 out of a possible 10 depending on the metric used—and for good reason. It allows anyone with pairing privileges (the lowest-level permission) to gain administrative status. With that, the attacker has control of whatever resources the OpenClaw instance does. “The practical impact is severe,” researchers from AI app-builder Blink wrote . “An attacker who already holds operator.pairing scope—the lowest meaningful permission in an OpenClaw deployment—can silently approve device pairing requests that ask for operator.admin scope. Once that approval goes through, the attacking device holds full administrative access to the OpenClaw instance. No secondary exploit is needed. No user interaction is required beyond the initial pairing step.” The post continued: “For organizations running OpenClaw as a company-wide AI agent platform, a compromised operator.admin device can read all connected data sources, exfiltrate credentials stored in the agent’s skill environment, execute arbitrary tool calls, and pivot to other connected services. The word ‘privilege escalation’ undersells this: the outcome is full instance takeover.” While fixed, the vulnerability means that thousands of instances may have been compromised without users having the slightest idea. Ever since OpenClaw rose to viral sensation, security professionals have warned of the dangers that come from an LLM—by its very nature unreliable and prone to the most basic of mistakes—gaining access to such a vast number of sensitive resources and acting autonomously. Earlier this year , a Meta executive said he told his team to keep OpenClaw off their work laptops or risk being fired. The executive said the unpredictability of the tool could lead to breaches in otherwise secure environments. Other managers have issued the same mandate. Security researchers, too, have issued warnings. Further adding to concern, the patches dropped on Sunday but didn’t receive a formal CVE listing until Tuesday. That means that alert attackers had a two-day headstart to exploit before most OpenClaw users would have known to patch. Making the chances of active exploitation more likely, Blink said that 63 percent of the 135,000 OpenClaw instances found exposed to the Internet in a scan earlier this year were running without authentication. The result is that attackers already had the pairing privileges required to gain administrative control with no credentials required. “On these deployments, any network visitor can request pairing access and obtain operator.pairing scope without providing a username or password,” Blink said. “The authentication gate that is supposed to slow down CVE-2026-33579 does not exist.” The vulnerability stems from the failure of OpenClaw to invoke any authentication during the request for administrative-level pairing. The core approval function—src/infra/device-pairing.ts—didn’t examine the security permissions of the approving party to check if they have the privileges required to grant the request. As long as the pairing request was well-formed it was approved. The guidance to assume compromise is well-founded. Anyone who runs OpenClaw should carefully inspect all /pair approval events listed in activity logs over the last week. Beyond that, users should reconsider their use of OpenClaw altogether. Whatever efficiency may be gained from using the tool could easily be undone in the event a threat actor obtains the keys to a network kingdom. Post updated to remove reference to Reddit post. Dan Goodin Senior Security Editor Dan Goodin Senior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 55 Comments