TL;DR
Silverfort’s security research team identified a critical vulnerability in ClawHub that enables any attacker to position their skill as the #1 skill in ClawHub. By doing so, an attacker can inject malicious code within what appears to be a legitimate and trusted skill, creating the foundation for a large-scale supply chain attack. As a result, large numbers of users and OpenClaw agents could download the compromised skill and execute malicious code on their machines, potentially with elevated privileges. In our POC, our skill jumped to the #1 download position in its category, resulting in 3,900 skill executions within 6 days in over 50 different cities around the world, including several public companies.
This issue was responsibly disclosed to the ClawHub team on March 16, 2026 and has since been successfully mitigated.
To reduce risk of such attack chains, our team developed ClawNet: a security plugin for OpenClaw that scans skills for malicious patterns during installation using the agent’s LLM, then informs the user and blocks suspicious installs.
What is ClawHub?
ClawHub is OpenClaw’s public skills registry, where anyone can publish a skill package for others to install. A skill might, for example, enable your OpenClaw agent to integrate with Google Calendar or perform optimized web searches on your behalf. It’s the npm of the OpenClaw agentic ecosystem. The ClawHub platform has been growing rapidly, with many skills already reaching massive download numbers (Want a primer on OpenClaw? You can read more here).
As ClawHub’s popularity grows, so does its appeal to attackers. The ability to publish skills into a marketplace that users actively browse and install creates a great supply chain opportunity.
A classic attack path would involve releasing a malicious skill and waiting for users to install it. But injecting malicious code into an innocent-looking skill isn’t sufficient—widespread installation requires the skill to appear trustworthy. In ClawHub, as in many public registries such as npm or the VS Code Marketplace, trust is often inferred from its popularity.
ClawHub code is almost entirely vibe-coded. While this approach has its advantages, it can also introduce critical security issues. By analyzing ClawHub’s implementation of the download action, we identified a vulnerability that allows download-based trust signals to be transformed into a scalable attack chain.
Finding a skill in ClawHub
Suppose you want to install a skill that allows your OpenClaw agent to assist with scheduling meetings in Google Calendar. To do that, you would head to ClawHub—either through the web interface or the CLI, and search for the appropriate skill package. Once you receive the search results, the first thing you notice is the skill’s download count. The more downloads a skill has, the higher it will appear in the search results.
Each skill package includes a SKILL.MD file. This file tells the agent the skill’s purpose, which dependencies it requires, and when and how it should be used. Some skills may include scripts that the agent can execute under certain circumstances.
Diving into the research
Digging into the download API
ClawHub code is open to the public (lucky for us). During our research, we found that it exposes a skill download API via a downloadZip function. In short, before a download is counted, the request must pass through several validation checks:
- Rate limiting: too many requests from the same IP or user and you get blocked.
- Deduplication: even if you pass the rate limit, the same IP or user hitting the same skill within the same hour won’t be counted again.
At first glance, it looks like a solid defensive design, until you dig a bit deeper into the implementation.
Bypassing the frontend API endpoint
ClawHub uses Convex as its backend framework. Looking at the ClawHub source code, two interesting endpoints were publicly accessible:
- The Convex site URL: serves the frontend HTTP API. Actions like skill download, user listing, and skill search all live behind it.
- The Convex deployment URL is a bit different. This one talks directly to the Convex backend RPC layer—no HTTP action middleware, no custom request handling. Just raw function calls against the backend.
A closer look at the Convex library
Convex is a backend framework built around a typed RPC (Remote Procedure Call) model. In an RPC model, instead of sending HTTP requests to REST or GraphQL endpoints, you call backend functions directly from the client. Every function you define is automatically registered and callable—think of each function as its own endpoint.
Convex draws a hard line between public and private callable functions:
- Internal functions:
internalQuery / internalMutation / internalAction
Private by design. Only invokable by other server-side Convex functions, completely invisible to the outside world. - Public functions:
query / mutation / action
Exposed over the Convex deployment URL and callable by anyone who knows or guesses the function name. According to Convex docs, if a function is defined as public, anyone can call it via HTTP request as follows:
These functions should of course be used very carefully. They must validate the client input and verify permissions to use the function before making any changes to the backend database.
Discovering the vulnerable function
Inside downloads.ts is a function called increment. While the legitimate download flow goes through a heavily guarded internal mutation that enforces rate limiting, deduplication, and permission checks, this function skips all of that entirely:
No authentication. No rate limit. No deduplication. No permission checks of any kind.
It was clearly meant to be an internal function but was defined as a public mutation instead of internalMutation. That single mistake exposes it as a callable RPC endpoint on the deployment URL, public to the world.
An attacker can call downloads:increment with a single curl request with any valid skillId, bypassing every protection in the download flow and inflating any skill’s downloads counter without limit!
This is how it looks:
Obtaining the deployment ID and skill ID is trivial, as both are exposed in the client’s network traffic and can be observed by inspecting the responses from the ClawHub server.
Forming the attack chain
Step 1: Crafting the malicious skill
The attack begins by building and publishing a skill that appears entirely legitimate. For this demonstration, we created an Outlook Graph Integration skill—a utility that enables an OpenClaw agent to schedule meetings, manage a user’s emails, and more.
Hidden within the skill’s script is a simple data-exfiltration payload. When the skill is invoked by OpenClaw, it collects the client’s username and FQDN and sends them to a server we control. For the sake of this research, the payload is intentionally low-impact and non-destructive.
The payload was embedded inside a seemingly legitimate “send_telemetry” function, and as a result, the skill was not identified as malicious.
Of course, a real attacker would make this payload far more sophisticated; they can harvest environment variables, local file paths, tokens stored in memory, or anything else accessible within the skill’s execution context.
Step 2: Inflating the downloads counter
This is where the attack becomes particularly interesting from a supply chain perspective. We already have a malicious skill on ClawHub, but a skill with zero downloads isn’t going to reach anyone. Who would want to install a skill nobody has ever tried? We needed it to look trustworthy.
So, we built a simple tool to do exactly that. By leveraging the vulnerable function we found in the codebase, we were able to flood the stats database with requests to insert a stat event, incrementing the download counter for our malicious skill. How many downloads? As many as we want! No rate limiting, no validation, nothing standing in our way.
Within a few minutes, the downloads counter for our skill climbed significantly—enough to push the skill to the top of search results in its category.
Step 3: Watching it land
After the download inflation, users began discovering and installing the skill. The result: About 3,900 skill executions within 6 days over 50 different cities around the world, including several public companies.
All of these executions triggered an HTTP request to our server that included the user’s domain name and username as part of the legitimate skill execution.
This demonstrates how powerful such attack chains can be. The skill runs on behalf of the highly privileged user operating the OpenClaw agent. In this case, we only collected the username and domain, but a real attacker could exploit this to perform far more harmful actions.
OpenClaw falls into the same trap
If human users can fall for the downloads trap, what happens when we delegate the decision to our OpenClaw agent?
When asked to find the best skill for a given requirement, the agent performs a ClawHub search via the ClawHub CLI and selects a skill from the results based on the skill’s name, slug, summary and score. Although the final decision of which skill to install is done by the LLM, the skill’s score—which influences that decision according to the codebase—is impacted by content semantics, and, well… the downloads count:
So, we asked our OpenClaw agent to choose a skill for managing email and calendar tasks, and unsurprisingly, it picked up the malicious skill we published. In its explanation, it said it chose that skill because it had the highest score (a result of the high downloads count).
Protecting your OpenClaw agent from malicious skills
As OpenClaw enables autonomous skill installation and execution, it’s essential to ensure that the skills you install are safe and trustworthy – as we’ve already seen.
To help reduce risk, we recommend installing our ClawNet security plugin for OpenClaw. ClawNet uses the OpenClaw agent loop to intercept the tool calls involved in installing skills. Before a skill is installed, ClawNet asks the agent’s LLM to review the skill’s contents and flag potentially malicious patterns. It then delivers the findings to the user and decides whether the installation should be blocked or allowed.
Our choice to implement this as a plugin rather than a skill is a security decision. A skill can be skipped or ignored by the LLM—whether due to incorrect inference or because the model isn’t reliable at consistently following the intended skill-handling flow. A plugin, on the other hand, integrates directly into the OpenClaw agent loop and intercepts skill installation attempts at the runtime level, ensuring the check runs regardless of the LLM’s behavior.
What can we learn from this?
Vibe-coding is not a security strategy
Vibe-coding enables rapid development, but it does not replace structured security practices. While AI can create remarkable systems, it remains prone to errors. Human oversight is still essential during development, as small implementation details can have significant security implications.
Download counts cannot be your only trust signal
While it may be tempting to trust something simply because others do, popularity is not a security guarantee. Download counts say nothing about code integrity, review processes, or safe behavior. When such signals are used as decision-making inputs—especially by automated systems—they can become a vector for manipulation. Instead, users/agents should verify the origin of any skill and use a dedicated skill scanner like our ClawNet plugin for OpenClaw, to ensure the files do not contain suspicious patterns before installation.
RPC development requires explicit security boundaries
Unlike REST APIs (where routes, middleware, and validation layers are typically separated by design), RPC-based frameworks such as Convex enable developers to expose callable functions directly from the backend code. This can increase the risk of insufficient authorization checks or input validation. Convex’s Best Practices explicitly emphasize this point, recommending to “Use some form of access control for all public functions”. While RPC architectures are not insecure by default, they require strict access control, careful validation, and adherence to documented best practices.
Your OpenClaw agent can become a security risk
OpenClaw’s power lies in its autonomy—its ability to search, evaluate, and install skills without human intervention. However, that same autonomy introduces risk. Without enforced verification and inspection mechanisms, our agent’s autonomous decision-making can unintentionally expand the attack surface.
AI agents are their own class of identity
AI agents are their own class of identity requiring the same level of discovery, real-time control, and posture hardening as traditional human users and non-human identities. Every agent must map to a human owner, and access policies must be defined and mapped. The result is that agents can only do what they’re explicitly permitted to do. No standing privileges. No bypass.
Disclosure and fix
The vulnerability was reported to the OpenClaw security team, including its impact and technical details. The team responded quickly and was highly collaborative throughout the process, resolving the issue in under 24 hours and deploying the fix to production (see commit by Peter Steinberger, the lead OpenClaw developer, here).