OpenClaw: The AI that actually does (malicious) things
Article originally posted on Exaforce Substack: https://theforcemultiplier.substack.com/p/openclaw-the-ai-that-actually-does
OpenClaw, as a tool, is bringing something new to people. A way to have a personal assistant that helps them with their day to day tasks, manages their day, their calendar, messages, and basically every facet of life, if it has access to do so.
OpenClaw works as a digital butler, managing different tools that help with tasks. And I think I speak for a lot of people when I say we all wanted a JARVIS-like assistant that would manage everyday mundane tasks, while we do more interesting things. Yet, I cannot help but be concerned about the risks this tool can bring to the individuals and entities using it.
This article is not throwing shade on OpenClaw, nor recommending people not to use it. Quite the contrary, as stated before, I see OpenClaw as a very valuable resource. This is a practical guide to the risks it introduces and how to use it more securely, so you can get the benefits without the exposure.
OpenClaw as an AI Assistant
OpenClaw uses a simple architecture in which it creates a gateway that manages all connections from other nodes. Initially built as an AI Assistant that would get installed on your machine, it has quickly developed into an all-in-one AI assistant that is offered as a pre-built machine by cloud providers like DigitalOcean or AWS Lightsail.
It allows connection to different AI Agents and management through either operators (Web Browser, Terminal UI, etc.) or channels, which utilize different IRC and chatting tools, such as Discord and Telegram, to send questions and requests to the gateway, which in turn sends and receives them to and from the LLM Agents configured to be used by it.
To extend the functionalities of OpenClaw, skills, plugins, and commands are installed and enabled, with different features added to the gateway. Skills and plugins can be custom developed and installed. The main hub for Skills is ClawHub, with the option to install them through a GitHub repository, while Plugins can be installed through the npm package registry.
All the configuration made through any operator is saved on the OpenClaw configuration file, which by default resides in the OpenClaw directory on the user’s home folder. The config file contains configuration about the LLM model used and its authentication methods, channels, plugins, tools, commands, and gateway configuration, amongst other things.
$ cat openclaw.json | jq “keys”
[
“agents”,
“auth”,
“channels”,
“commands”,
“gateway”,
“messages”,
“meta”,
“plugins”,
“session”,
“tools”,
“wizard”
]There are several LLM models allowed to be configured, each one requiring a token to be provided, which will allow the usage of the agent.
To allow remote access to OpenClaw, operators (or channels) are configured. These are chat platforms connected to OpenClaw, and by sending messages to the platform, OpenClaw will execute tasks.
OpenClaw Risks
"If it's easy for you, it's easy for an attacker" is a mantra I stand by when it comes to any tool or feature. If the user can come up with some hack to make their job easy, that can become a tool for an attacker.
Everything from authentication bypasses or “Remember Me” checkboxes, to autonomous tools that gather information and parse it into other formats, to IDE libraries, can be great tools that an attacker can utilize to gain access to the system or data controlled by you.
OpenClaw uses the same trust as any other trojanized app, as it is considered a trusted app, installed and managed by the identity using the machine, allowing attackers to utilize it as a malware deployment tool, evasion bypass, and botnet.
Plaintext credentials stored on the machine
The first issue I found was credentials stored on files inside the gateway endpoint, unencrypted. These credentials, usually part of the config file, contain tokens of channels, which allow remote access using known chat platforms, such as Telegram, Discord, and WhatsApp, along with LLM Agent access tokens, using which requests can be sent to the agents that process the information.
In the config file, the channels that are configured will require a credential to be generated, usually in the form of a bot, which will have access to the channel that is allowed to execute the tasks.
Having both the credentials of the operator and the model allows us to take control of the model and use it for our own purposes.
I saw what you asked yesterday
Each time a question is made to the model, OpenClaw stores it, the thought process, and the response to the agent’s sessions directory (~/.openclaw/agents/<agent>/sessions/<session file>.jsonl).
Using these files, we can gather potentially important information regarding the user of OpenClaw and information regarding the tasks they will be executing.
Look at this old config file
When openclaw config is executed and the configuration is changed, OpenClaw will keep a copy of the old config file on the machine. This config file can contain information about other configurations, such as old keys or tokens that are still valid, which can be abused by the attacker.
OpenClaw as a malware delivery tool
This article is definitely not the first one touching the subject of OpenClaw’s misuse by attackers as a malware delivery tool, and its users rushing to install the latest feature in the form of plugins and skills, without first making sure what they are installing is legitimate.
The skill and plugins are where things get particularly interesting from an attacker’s perspective. Skills are just markdown files sitting in a local workspace directory, and because OpenClaw loads and executes them with essentially no verification, coercing the user into installing a malicious skill will allow the attacker to gain execution on both the agent and the system. It becomes worse when skills can contain dependencies that may contain malicious code being installed on the machine.
Plugins make this even worse. Plugins are essentially TypeScript code used by OpenClaw on the machine. It will get executed on the machine, using the permissions of the identity executing OpenClaw, and run the code containing anything in its body. This means that an attacker can inject malicious code into the plugin and make the code execute each time the gateway starts with the elevated permissions of the user.
Skills
Skills are user input commands that teach OpenClaw how to combine tools to accomplish tasks. OpenClaw offers 50+ official skills covering notes, email, social media, development, and more.
Every skill is a directory containing at a minimum a SKILL.md file. The SKILL.md explains which environment variables are required and when the agent should call the associated script. At the next startup, the agent reads the SKILL.md and knows, for example: “When I need to interact with ClickUp, use this skill.”
Skills use agent skills as a technology, where the SKILL.md file will contain all the instructions for the agent to run, and then have scripts, documentation, and other assets to assist with the task required.
Each skill will contain some headers, such as name, description, and homepage, but OpenClaw also adds the OpenClaw Metadata, which adds other elements used by OpenClaw. One of these elements is the path of installation for dependencies. This JSON block will contain the source of the installed module, the runtime, and the binaries that will be installed on the machine.
Prefer `--json` for scripts. Confirm the target before making changes.
This is the injection point. An attacker who controls the skill can specify a malicious binary in the install block. When the user installs the skill, that binary runs, giving the attacker execution on the machine.
Plugins
Where skills teach the agent what to do, plugins extend what the gateway itself can do. They are Node.js modules that hook directly into the gateway and offer new features, like registering new channels, adding event listeners, or wiring up new transport layers.
By default, OpenClaw comes with a list of stock plugins that are stored in the extensions directory of the OpenClaw Node module directory.
$ openclaw plugins list
OpenClaw offers the possibility of creating custom plugins, written in TypeScript, which can offer basically any feature that is possible to be coded, such as new channels, connection to external services, and potentially a Command and Control beacon. This becomes a problem for security, as an attacker can coerce the user into installing a plugin, infect a legitimate one, or even modify one residing on the machine for persistence.
Aside from installing, plugins also need to be enabled in the config file in the plugins section. A plugin not enabled will not be executed by OpenClaw.
OpenClaw as a persistence mechanism
Local machine persistence was covered in the malicious plugins section, but it is not the only goal an attacker might have. Some attackers are only interested in the agent itself, such as using it for unethical content creation, attacking other targets, or exploiting the knowledge and access the agent holds over the user’s life, information, and work.
Modifying the config file to tamper with the gateway
OpenClaw offers the command openclaw configure, which allows configuration of the gateway using an interactive terminal GUI. This command updates the config file and even puts a metadata timestamp of the config file’s update time. The metadata timestamp is confirmed not to be used as a logging mechanism, just metadata. Later on, in the logs section, we can see how to actually detect a config file update.
One other thing I noticed is that updating the config file directly, without using `openclaw configure`, and restarting the gateway will still apply those configuration changes on the gateway. The config file resides on the home directory of the user executing it, in the .openclaw directory, and is readable and writable from the user running it. No special permissions are required.
At the same time, the gateway is restartable by the identity running OpenClaw. And in cases when OpenClaw is installed on the user’s machine, it will be the user who will have those privileges.
That means an attacker can update the config file, as allowed, restart the gateway as allowed, and set a channel to access the AI agent, maintaining persistence.
Add a new channel
Extending on the previous section, if an attacker wants access to OpenClaw, they can add a new channel, such as a Telegram bot, to the config file and restart the gateway. This will configure the gateway to be accessed by that channel, which will allow the attacker remote access to OpenClaw.
Before the channel can be allowed to be used, it needs to be allowed to pair on the gateway, and the configuration is done and ready for remote access.
Accessing the LLM model directly
When we talked about credentials being stored as plaintext on the machine, one of the credentials we spoke about was the LLM model’s token. The token is needed as OpenClaw does no more than programmatic access on the model, sending and receiving prompts.
An attacker with those credentials stolen can create a simple prompt request-response script that will send questions and receive answers from the model and abuse the target’s model and money for any activity they need to execute.
OpenClaw as a botnet
Between February 21 and March 2, 2026, a hacking bot calling itself hackerbot-claw started targeting vulnerable GitHub Workflows, an incident we also wrote about. The bot was taken down, and the repository it was using was as well, but while it was up, it managed to breach several repositories, access their workflow credentials, and even push unauthorized code.
Botnets are not new. Compromised machines being used for DDoS attacks or as pivot points is a well-understood threat. But the model assumes dumb bots executing fixed instructions. What happens when the bots are autonomous agents that can target environments, adapt to defenses, execute attacks, and cover the attacker’s tracks?
And what happens when that agent is actually your agent? We looked at how we can get access to the agent either through stealing credentials of the agent stored on the OpenClaw gateway or persisting using another operator. An attacker with this access can utilize the agent, make it the bot as part of the botnet, cost you money, and indirectly make you a complice on a specific attack.
Don’t get me wrong, this is not an OpenClaw only issue. Gaining access to an LLM-powered project and abusing the agent’s tokens to utilize it can happen to anybody with that setup, but OpenClaw is another project that allows this attack. That means constant monitoring of changes to the gateway configurations and prevention of unwanted access to the gateway will need to be a high priority.
Detecting if a user is using OpenClaw
Since OpenClaw has its own attack surface, it is important to know which identities are using it and how. That means, what plugins and skills are they installing, what skills tools are they enabling, and what channels are they configuring. There are several ways to know if OpenClaw is installed and running on a machine, but they depend on whether the target is installing OpenClaw as a gateway locally or using a remote gateway with the machine being a node.
OpenClaw is a NodeJS module, whose source code can be found in Node’s NPM modules directory. There lies the source code of the actual package that will be executed. The package will also contain the terminal tool openclaw that can be used to configure the gateway and operate the agent.
If the gateway is installed locally, the gateway’s files, such as the config files, skills, plugins, credentials, prompts for the agent, etc, will be stored in the home directory of the user running OpenClaw, in the directory .openclaw.
The gateway by default runs on ports `18789`, where `18789` is also used as the web service for the browser based controller.
Lastly, in the temporary directory, there will be two OpenClaw directories, one containing the gateway logs and another a metadata file for the gateway.
Detecting OpenClaw misuse by an attacker
This step is a bit long, as we will need to look for several angles, to find if an attacker is misusing OpenClaw or has attempted to misuse it. We will need to look for skills and plugins installed, config file tampering, prompt and gateway logging, as well as cost as a monitoring metric.
Use gateway information messages
One feature I like from OpenClaw is the verbosity the gateway has on restart. It will list channels, plugins, bad practices, and even warnings on misconfigurations. This is an important feature for initial detection methods, as gateway restart might be more common than many other commands being executed on the gateway.
Finding new plugins installed
There are two good ways to know if a plugin is installed and enabled. One is to look into the config file, under the plugins section. This is a section that contains the list of plugins and their status.
The other one is to run openclaw plugins list. It will generate a list of plugins installed, enabled, and those failing due to errors in the plugin.
New skills installed on the machine
OpenClaw offers the command openclaw skills list as a way to list the skills installed. It will list the current skills, both stock and custom, and will show their status.
We can also check the source code of the custom installed skills in the skills directory under the workspace directory (.openclaw/workspace/skills), to check what instructions or dependencies they will have and install on the machine.
New channels configured on the gateway
This is the same as any other command we’ve seen so far. OpenClaw offers a stock command that lists configured channels on the gateway. Check them for new channels that can have been configured on the gateway, which can allow access to manage the gateway remotely.
May I also recommend the old config file?
Attackers are not the only ones who can read old config files. If an attacker has modified the config file for the gateway and left the old one on the machine, a defender can check to see what configuration changes were made by the attacker.
Though attackers are more careful in these cases, as they are supposed to be the ones trying to hide activity, it is not uncommon to see mistakes happening from them.
I saw what you asked yesterday again
The prompt logging mentioned earlier as an enumeration technique was initially built to be a monitoring mechanism. We can utilize this mechanism to read malicious prompts and how the agent responded to them, so we can detect misuse of OpenClaw and potential attempts to maliciously utilize the agent.
Use logging
OpenClaw uses JSON logging to give you visibility into what the gateway is doing at runtime. Logs are written to ~/.openclaw/logs/ by default and are invaluable for diagnosing config reload issues, plugin failures, and unexpected agent behavior.
Some events of interest include config change, provider attachment, and tool enabling. In the logs below, for example, OpenClaw detected a config file change and started evaluating which parts of the gateway needed to react (contextPruning, heartbeat, channels.telegram, plugins.entries.telegram, tools.exec.safeBinTrustedDirs). After evaluation, it determined that the plugins.entries.telegram change is not applied and requires a gateway restart. This is a common pattern when editing openclaw.json while the server is running.
Lastly, if a tool is enabled, it will be listed. Always check for new tools that were not enabled by you.
Defending from misuse of OpenClaw
OpenClaw, like any software, has vulnerabilities. Code injection, memory corruption, vulnerable dependencies, and architectural weaknesses have all been found before, and more will be. Some of those will be discovered by threat actors before they are found and patched.
One of those vulnerabilities was found and fixed in February 2026 by Oasis Security, and it is neither the first nor the last vulnerability to be found. So, always consider that an app is code and code can be vulnerable.
Use the malware scanners
One feature that is important to look into is the skill scanner from ClawHub. ClawHub will utilize VirusTotal to scan for malicious skills uploaded to it and provide a response to how benign or malicious something can be.
It should be noted that writing malware that bypasses all antivirus solutions currently scanning for VirusTotal is not impossible. There is a whole sub-field in Red-Teaming of malware writers specializing in bypassing security solutions to execute malware on machines with antivirus and EDR, but it is still a good idea to look into the scanning it provides, as an initial awareness.
You shall not be used
OpenClaw’s config file supports allow and deny lists for tools and plugins. Anything not explicitly enabled is loaded but blocked from executing. Review the config regularly for tools and plugins you did not configure, and disable anything unfamiliar.
Use the source, Luke
While speaking with more technical users, getting comfortable reading and understanding the source code of skills and plugins, before installing or enabling them, can help a lot with security.
Skills themselves are easier than plugins, as they are just directories containing a SKILL.md file and accompanying scripts, while plugins are Node.js modules wired into the gateway, they’re generally readable even without deep programming experience. SKILL.md describes what the skill is ordered to do, in human readable text, and what tools it exposes to the agent. Then look at the actual script files to verify that what the code does matches what the description says. Pay particular attention to any outbound network calls (fetch, axios, http.request), file system access (fs.readFile, fs.writeFile), and shell executions (exec, spawn), as these are the three actions that can cause real harm if a skill is malicious or poorly written.
For plugins, check what channels or hooks they register into and whether they read from sensitive config fields like API tokens or credentials. You don’t need to understand every line, as you’re mostly looking for anything that sends data somewhere unexpected or touches parts of your system that the skill has no legitimate reason to access. Given that we are seeing that a significant portion of community skills and plugins contain vulnerabilities or malicious code, spending some time on a quick code read can save you from a serious security incident.
Use sandboxing as much as possible
OpenClaw’s sandbox is a contained environment wrapped around tool execution. When you enable it, things like exec, file reads/writes, and browser automation run inside this contained sandbox instead of directly on your host. That distinction is huge. Without it, anything the agent does, whether instructed by you or maliciously by an attacker, runs as whatever user is running the gateway. On most setups, that’s your own user machine, with full access to their directory, where your API tokens live, and everything else. With the sandbox enabled, that same malicious exec call lands inside a container with no network by default, a constrained filesystem, and no persistent state.
Run security audits periodically
OpenClaw offers a built-in audit command (openclaw security audit) that scans your local configuration, filesystem permissions, and channel policies for common misconfigurations. It covers over 50 checks across config, channels, plugins, gateway exposure, browser control, and the exec permission model, without making any changes to your system.
In case an extended scan needs to be done, the --deep flag can be used, which extends the baseline scan with a live gateway probe, browser control exposure checks, and static code-safety analysis of installed plugins and skills. The command will not make any change to the system again.
If we want to apply changes, we can use the flag --fix , which applies automatic remediations for the misconfigurations it finds.
It is recommended to execute it at least daily to see if any changes have happened, which might affect you, or if any configuration is not considered safe anymore. Also, since new vulnerabilities have been and will be found for OpenClaw, it is recommended to scan for them using the audit command.
The AI that does things (securely)
New technology always introduces new risk. That is not a reason to avoid OpenClaw. It is a reason to run it with your eyes open.
OpenClaw delivers something many of us have wanted for a long time, a capable, autonomous agent that manages the mundane parts of work and lives. That same capability is what makes a compromise serious. The access you grant it is the access an attacker inherits.
This article covered how OpenClaw can be abused, how to detect it, and how to reduce your exposure. No configuration makes it perfectly safe, but the practices outlined here make it meaningfully harder to exploit.
Last updated