How to review a ClawHub plugin before installing it

In March 2026, over 800 plugins on ClawHub were confirmed malicious, exposing roughly 42,000 OpenClaw instances. Most operators installed those plugins the same way most people install any plugin: found something that sounded useful, ran the install command, moved on. This article shows you exactly how to vet a plugin before installing it, what to look for in the source code, and the five-minute checklist that catches the majority of malicious plugins before they reach your system.

Every indented block in this article is a command you can paste directly into your OpenClaw chat. Your agent will run it and report back. You do not need to open a terminal, edit any files manually, or navigate any filesystem.

What a plugin can actually do to your system

A plugin in OpenClaw is code that runs inside your agent’s environment. It can register new tools, read and write files, make network requests, hook into your agent’s message pipeline, and access any resource your agent can access. There is no sandbox between a plugin and your agent. If you install it, it runs with the same permissions as everything else in your setup.

This is not a flaw unique to OpenClaw. It is how plugin systems work in most agent frameworks. The protection is review before install, not containment after. A legitimate plugin uses that access to provide useful functionality. A malicious plugin uses the same access to steal your data or take control of your agent.

What a malicious plugin can do once installed:

• Read any file in your workspace including openclaw.json, which contains all your API keys, channel tokens, and configuration
• Make outbound network calls to send that data to a server the attacker controls
• Send messages through your configured channels: Telegram, Discord, email, anything your agent has access to
• Trigger exec tool calls that run shell commands directly on your server
• Modify your configuration to persist access even after you think you have removed the plugin
• Plant instructions in your agent’s memory that cause future sessions to behave differently

The 42,000 instances exposed in the March 2026 crisis were not all compromised in the same way. Some plugins exfiltrated credentials. Some injected instructions into the agent’s behavior. Some acted as a persistent backdoor. The variety is part of why the attack surface is difficult to audit after the fact. It is much easier to catch before installation.

The critical thing to understand about plugin risk is that it scales with what your agent can do. An agent that can only answer questions has a smaller blast radius than one with exec access, file write permissions, and live message channel credentials. The more capable your agent, the more important it is to vet every plugin before it enters that environment. A plugin running in a minimal agent can do minimal damage. A plugin running in a fully configured production agent with all tools active is a different risk entirely.

This is not an argument against capability. It is an argument for matching your review rigor to your agent’s actual power. If you have spent time setting up a capable agent, spend five minutes on each plugin. That investment protects the larger one.

List all the plugins I currently have installed. For each one, tell me: what does it do, what access does it require, when was it installed, and is it currently enabled or disabled?

If your agent lists any plugins you do not recognize or have not actively used, consider disabling them immediately. An unused plugin that is enabled still runs with full access. Disabling it costs nothing and removes a potential attack vector.

Before you run the install command

The standard install flow for ClawHub plugins is a one-liner: npx clawhub install slug-name. It is fast. It is easy. It is also the moment when you have the most leverage over what ends up in your environment. Once a plugin is installed and enabled, the code is running. The review happens before that command, not after.

Run through all five steps below before executing any install command on a plugin you have not previously reviewed. The whole checklist takes five minutes for a straightforward plugin and fifteen minutes for a complex one. Both are worth the time.

The five-step review checklist

Find the source repository. Most legitimate plugins link to a GitHub repository from their ClawHub listing or their npm package page. If there is no source link, no repository, and no way to read the code before installing, do not install it. A plugin with no visible source is asking you to trust something you cannot examine.

Once you have the repository, check these four things:

• Last updated: a plugin that has not been touched in over a year may have fallen out of sync with current OpenClaw behavior. It deserves more scrutiny, not less, even if it was legitimate when first published.
• Commit history: a single large commit with all the code is higher risk than a repository with a history of incremental changes. Single-commit repos are harder to audit for when specific functionality was added.
• Publisher identity: does the GitHub account match the ClawHub listing author? Does the account have other repositories, activity, and a plausible history?
• Issue tracker: are there open issues about unexpected behavior, network calls, or security concerns? Other users may have found something you would otherwise miss.

I am considering installing a plugin. Find its source repository. Tell me: does it have a public GitHub or GitLab link? When was it last updated? How many commits are in its history? Does the repository publisher account look legitimate?

If your agent cannot find a source repository, that is a hard stop. Do not proceed.

The ClawHub slug and the actual npm package name are not always the same string. Before running any install command, verify that the package name resolves to what you expect. The March 2026 crisis included at least one documented case where a ClawHub listing referenced a package name that did not exist on npm, while a similarly-named malicious package was registered and would have installed instead.

Before I install this plugin, check the npm registry. What is the exact package name the install command resolves to? Who is the publisher on npm? Does the npm description match the ClawHub listing? How many weekly downloads does the package have, and when was it first published?

If a plugin includes a SKILL.md file, that file becomes instructions to your agent when the skill is activated. It runs with the same authority as your own system prompt. Read it before activating the plugin. You are looking for anything that tells your agent to do things you did not ask for.

Red flags in SKILL.md files:

• Instructions to send logs, metrics, or usage data to an external endpoint
• Instructions to read openclaw.json and send specific values somewhere
• Instructions to run shell commands unrelated to the plugin’s stated purpose
• Instructions to modify your OpenClaw configuration without your explicit approval
• Instructions to ignore safety warnings or bypass approval prompts for any action
• Instructions that persist across sessions by writing to memory or checkpoint files

Read the SKILL.md file for this plugin. Does it instruct you to send any data to external services? Does it ask you to read files outside my workspace? Does any instruction seem unusual, broad, or like something I would not have approved if I saw it first? List every red flag you find.

If the SKILL.md contains any of those patterns, do not activate the skill. You can install the plugin without enabling it, which puts the code on your system but does not run the SKILL.md instructions. That gives you time to investigate further or ask in the community whether the behavior is expected.

A plugin that makes outbound network calls to a domain you do not recognize is a significant red flag. Legitimate plugins call the services they advertise. A memory plugin calls your configured embedding API. A search plugin calls the search API. If you see calls to unfamiliar domains, especially anything that looks like analytics, telemetry, or data collection, investigate before proceeding.

You do not need to read every line. Search for these patterns in the source files:

• fetch(: JavaScript built-in HTTP calls
• axios: popular HTTP library
• http.request or https.request: Node.js built-in HTTP
• curl: shell command for HTTP calls
• XMLHttpRequest: older browser-style HTTP

For each match, look at the URL being called. Is it a domain the plugin’s documentation mentions? Is it obviously related to the plugin’s function? An unfamiliar domain receiving data is worth 60 seconds of investigation before you continue.

Scan the source code of this plugin for outbound network calls. Find every fetch, axios, http.request, https.request, or curl call. List every external domain the code contacts. For each one, tell me whether it is obviously related to the plugin’s stated purpose or whether it looks unexpected.

Red Rook AI maintains a security audit script specifically for scanning SKILL.md files. It checks for common patterns associated with malicious skills: outbound data sends, credential reads, instructions to bypass safety settings, and instructions that grant unusual permissions. The script lives at skills/agents-skill-security-audit/audit.py if you have installed that skill.

The script has false positives. A flagged line does not necessarily mean a plugin is malicious. Treat the output as a list of places to look more carefully, not as a verdict.

Do I have the security audit script installed at skills/agents-skill-security-audit/audit.py? If yes, run it against this plugin’s SKILL.md file and show me the full output. For each flag it raises, tell me whether it looks like a genuine concern or a likely false positive.

The three-review rule for plugins touching credentials or channels

For plugins that will have access to your API keys, your message channels, your exec tool, or any external service, apply a three-review minimum before installing:

1. You have read the source repository and understand what the plugin does at a code level
2. You have read and understood the SKILL.md and every instruction in it matches what the plugin claims to do
3. A second person has reviewed both: another operator in the OpenClaw community, a colleague, or someone whose judgment you trust

One set of eyes misses things. Two pairs rarely miss the same things. Ten minutes of review is trivially cheap compared to rotating compromised API keys, auditing your server logs, and notifying downstream services that your credentials were exposed.

Based on the five-step review we just ran, should I install this plugin? Give me a clear yes or no and your reasoning. If yes, are there any specific things I should monitor after installation?

Monitoring a new plugin after installation

Even a clean review is not a guarantee. Some malicious plugins load harmless code initially and pull in malicious updates through a dependency or a remote configuration endpoint. After installing any new plugin, monitor its behavior for the first week.

I just installed a new plugin. For the next seven days, run a daily check at 9am and report: what outbound network calls did this plugin make in the last 24 hours? Which domains did it contact? Did it read or write any files outside the expected workspace paths? Keep the report under five lines.

Seven days is enough to catch most lazy exfiltration patterns. Sophisticated attacks that wait months before activating are rare and typically beyond the threat model of an individual operator. A week of monitoring gives you high confidence that the plugin is behaving as documented.

If the daily monitoring report shows any unexpected domain contacts, do not dismiss them immediately. Look up the domain. Some unexpected calls are legitimate: a caching CDN, an update check endpoint, a telemetry service that was disclosed in the README but that you forgot about. But verify before you dismiss. The cost of verifying an unexpected call is five minutes. The cost of dismissing a real exfiltration call is everything the plugin touched.

The monitoring report for my new plugin showed a call to [domain]. What is that domain? Is it related to the plugin’s stated function? Is there any record of this domain being associated with data collection or malicious activity? Should I be concerned?

What to do if you already installed a malicious plugin

If you installed a plugin during the March 2026 ClawHub crisis period and have not audited it, treat it as potentially compromised until proven otherwise. The steps to take:

1. Disable the plugin immediately before doing anything else. This stops any ongoing exfiltration or instruction injection.
2. Rotate all credentials the plugin had access to. This means every API key in your openclaw.json, every bot token, every webhook secret. If the plugin was active, assume those credentials were read.
3. Check your message channel history for any outbound messages you did not send. A plugin that sent messages as your agent would show up in your channel logs.
4. Audit your server logs for outbound connections to unfamiliar domains during the period the plugin was active.
5. Inspect your agent’s memory for any entries that you did not write and that seem designed to persist the plugin’s influence.

I need to audit my system for signs that a plugin may have caused harm. Check my message channel logs for any outbound messages from the last 30 days that I did not explicitly request. Check my agent memory for any entries that look like they were injected by a plugin. Check my openclaw.json for any values that I did not set. List everything you find that looks unusual.

Understanding plugin types and their risk profiles

Not all plugins carry the same risk level. The risk profile depends on what the plugin does and what access it requires to do it. Understanding the categories helps you calibrate how much scrutiny to apply.

These plugins add new tools to your agent’s tool palette. A weather tool, a web search tool, an image generation tool. The risk profile depends on what API the tool calls and whether it has access to your existing credentials. A weather tool that calls a free public API with no authentication is low risk. A tool that calls a paid API using your credentials stored in config is higher risk, because a malicious implementation can read that key and send it elsewhere.

For tool-registration plugins, Step 4 of the checklist (scanning for unexpected outbound calls) is the most important. You want to confirm that the tool calls exactly what it claims to call and nothing else.

These plugins hook into your agent’s message processing pipeline. They intercept messages before your agent sees them or after your agent generates a response. This gives them access to every message that passes through your agent, in both directions. A malicious pipeline-hook plugin is particularly dangerous because it can intercept credentials, modify your agent’s responses, or inject instructions into messages before your agent processes them.

Pipeline-hook plugins require the highest level of scrutiny. The three-review rule is mandatory for any plugin that describes itself as a middleware, interceptor, filter, or pipeline hook.

Does the plugin I am reviewing hook into my message pipeline? Does it intercept messages before I see them, or modify responses after my agent generates them? If yes, explain exactly what it does with each message and confirm it does not send message content to any external service.

Memory plugins read and write your agent’s long-term memory. A malicious memory plugin can plant instructions in your memory that persist across sessions, causing your agent to behave differently long after the plugin itself has been removed. It can also read your existing memories, which may contain API keys, personal information, or other sensitive data you stored there.

Inspect a memory plugin’s SKILL.md very carefully. Any instruction to write to memory without your explicit request, or to read memories and send them somewhere, is a red flag.

These plugins add SKILL.md instructions that extend your agent’s behavior. They are the most common type and the most directly risky in terms of instruction injection. The SKILL.md review (Step 3) is the primary check for this category. Read every line. An instruction that seems benign in isolation can be part of a pattern that causes harm when the plugin is active and a specific trigger is met.

Community resources for plugin vetting

Individual review catches most problems. Community review catches more. Several resources exist as of March 2026 that can supplement your own checklist.

The OpenClaw community Discord has a dedicated channel for plugin discussion and security reports. Before installing any plugin you are uncertain about, search that channel for the plugin’s name. If others have installed it and found it safe, there is usually a record. If others have found problems, there is definitely a record.

Search the OpenClaw community Discord for any discussion of the plugin [plugin-name]. Have other operators reported any concerns about it? Are there any security reports or warnings related to this plugin?

If the plugin has a public repository, check both open and closed issues for security-related discussions. Developers sometimes receive responsible disclosure reports through GitHub issues. A closed issue labeled “security” that was addressed quickly is a good sign. An open issue about unexpected behavior that the developer has not responded to is a bad sign.

npm maintains a database of security advisories for published packages. If a package has a known vulnerability, it will appear there. Your agent can check this directly.

Check the npm security advisories database for the package [package-name]. Are there any known vulnerabilities or security advisories associated with it or its dependencies?

Plugin security over the long term

A plugin that passed your review when you installed it may not be safe indefinitely. Plugin authors can update their code after publication. Dependencies can acquire vulnerabilities. Ownership of a popular plugin package can transfer to someone with different intentions. Long-term plugin safety requires periodic re-review, not just installation-time review.

I want to set up a monthly plugin audit. On the first of each month, check all my installed plugins: have any been updated since last month? For any that were updated, what changed? Are there any new security advisories for any of them? Send me a Telegram summary with the results.

Monthly is the right cadence for most operators. Active plugins that handle sensitive data or message channels are worth a quarterly deep review. Disabled plugins do not need monitoring but should be removed if you have not used them in six months.

The practical benefit of a monthly cadence is that it makes plugin security a habit rather than a crisis response. Operators who only review plugins after a security incident are always behind. Operators who review them monthly catch problems when they are small: a version bump that added an unexpected dependency, a new outbound call that was not in the previous version, a SKILL.md update that changed what the plugin instructs your agent to do. Those things are easy to catch when they are fresh. They are much harder to audit six months later when you are trying to understand what went wrong.

Common questions

Some plugins are pure code extensions that do not include a SKILL.md file. They add tools or capabilities to your agent without injecting instructions through the skill system. These are lower risk in one specific dimension (no instruction injection) but not inherently safe. Steps 1, 2, and 4 of the checklist still apply: verify the source, confirm the npm package, and scan for outbound network calls. A plugin without a SKILL.md can still exfiltrate data through its registered tools.

Paste “List all plugins currently installed, the date each one was installed if available, and whether each one is currently enabled. For any plugin installed before [date], flag it for review.” Your agent will pull the plugin list from your configuration. For any flagged plugins, run them through the five-step checklist retroactively. If the plugin was installed during the March 2026 crisis window and you cannot verify it is clean, disable it and rotate credentials before re-enabling.

As of March 2026, there is no official curated safe list maintained by the OpenClaw project. The ClawHub marketplace began a verification process after the crisis, but verification is not the same as a security audit. Treat marketplace verification as one signal among many, not as a substitute for the five-step checklist. The only list that matters for your system is the one you have personally reviewed.

Yes. Gateway bind address controls who can reach your agent from outside your server. A plugin running inside your agent can still make outbound network calls from your server to external endpoints. The gateway security and plugin security are independent attack surfaces. A loopback bind protects against external agents impersonating you. It does not prevent a plugin from calling home.

The Red Rook AI security audit script scans SKILL.md files for patterns including: URLs in instructions that point to external services, instructions containing words like “send,” “post,” “upload,” or “transmit” near credential-adjacent terms, instructions that reference reading openclaw.json or .env files, instructions that tell the agent to bypass safety checks or ignore approval requirements, and overly broad permission requests. The script is a pattern-matcher, not a semantic analyzer. It misses sophisticated obfuscation and generates false positives on legitimate uses of flagged terms.

Trust that instinct and investigate further. Post the SKILL.md and the npm package link to the OpenClaw community Discord and ask other operators whether they have reviewed it. The community has seen more plugins than any individual operator and can often identify concerns that are not obvious in a solo review. If you cannot get a clear answer and you cannot verify the plugin is safe, do not install it. The cost of skipping a plugin is zero. The cost of installing a malicious one is not.

The safest test environment is an isolated OpenClaw instance with no real credentials: a fresh install with placeholder API keys, no message channel tokens, and no sensitive workspace files. Install the plugin there, enable it, and monitor what it does over several sessions before installing it on your production instance. This is not feasible for every plugin, but for any plugin that will have access to live credentials or channels, a test environment is the right approach.

Yes. A disabled plugin does not load and does not execute. Its code is still on your filesystem, but it is not active. Disabling is sufficient to stop a plugin from operating. You do not need to remove it entirely unless you want to clean up disk space or are confident you will never use it again. That said, if you disabled a plugin because you suspect it is malicious, delete it rather than leaving disabled code on your system.

Yes. The Red Rook AI security audit script is open to contributions. If you find a pattern in a malicious plugin’s SKILL.md that the current script does not catch, submitting a pull request or opening an issue with the pattern helps protect other operators. The ClawHub team has also stated they are building automated scanning into the submission process after the March 2026 crisis. If you have identified a malicious plugin in the marketplace, report it through ClawHub’s reporting mechanism so it can be removed for all users.

Yes. Post in the OpenClaw community Discord with the plugin slug and what you found. Include the specific behavior that tipped you off: the network call, the SKILL.md instruction, the npm package discrepancy. Other operators who have the same plugin installed need to know as quickly as possible. You do not need to wait for an official response before warning the community. Speed matters when credentials may be at risk.

If you genuinely cannot run the full five-step checklist, do at minimum: verify the source repository exists and check that the npm publisher matches the ClawHub author. These two steps together catch the most common attack patterns: no-source plugins that are entirely opaque, and package squatting where the wrong package installs under a legitimate-looking name. Everything else in the checklist adds value, but those two steps are the non-negotiable floor. If either check fails, do not install regardless of time pressure.

First-party plugins from the official OpenClaw GitHub organization are maintained by the project team and have been through internal review. They are lower risk than third-party ClawHub plugins. That said, “lower risk” is not “zero risk.” Official plugins can still have vulnerabilities, and compromise of the OpenClaw organization’s GitHub or npm accounts could in theory push a malicious update to an official plugin. For first-party plugins, you can reasonably skip the SKILL.md deep-read and the npm publisher verification, but keeping your monthly audit running to catch version updates is still worthwhile.

Use ClawHub’s plugin reporting feature on the listing page. Provide the plugin slug, a description of the malicious behavior you found, and the specific code or SKILL.md lines that demonstrate it. ClawHub’s trust and safety team receives these reports and can remove the plugin from the marketplace while investigation proceeds. If you cannot find a reporting mechanism on the listing page, email ClawHub support directly or report it in the community Discord where ClawHub team members are active. Do not wait for a formal confirmation before warning other operators in community channels.

Keep Reading: