Why Enterprise Orgs Should Care
Moltbot a.k.a Clawdbot, an open-source personal AI assistant accessible via text messages,has blown up across the tech world in recent weeks. With tens of thousands of GitHub stars and thousands of forks in a matter of weeks, people are installing it faster than most teams can review its code.
But that rapid adoption comes with a hidden price: serious software vulnerabilities and license risks that most users aren’t thinking about, being willingly downloaded to their computers and phones.
What’s the Hype About?
Moltbot is a powerful AI assistant that integrates with major chat tools, can listen in on computer audio, and more. People are sharing videos, screenshots, and success stories on social media about how they’re using Moltbot to automate everyday tasks,from scheduling meetings to fetching information, all by chatting through WhatsApp, Telegram, or Slack.
Moltbot’s appeal mirrors that of the value of using Large Language Models (LLMs) and Generative AI-powered apps to automate common workflows: it’s easy to install, it’s easy to access, and it brings the power of AI right to people’s fingertips.
However, Moltbot’s clear value and buzzing popularity has distracted users from some very serious security risks - that they just installed on their devices.
The Risk of Using Moltbot
When an assistant can read messages, store context, call APIs, and execute workflows, it becomes a concentration point for risk. A single weakness, whether from a dependency, a configuration, or an unreviewed plugin, can have outsized impact.
The attack surface is already in the wild: thousands of internet-facing Moltbot interfaces have been found, some even allowing remote configuration. But external exposure is only part of the story.
Manifest assessed moltbot/moltbot to understand the inherited risk in the codebase and dependency graph. Here’s what showed up.
1) Overall risk: High
Manifest classified the repo as High Risk, driven by two major categories:
- Open critical and high vulnerabilities
- Forbidden license issues
This is the kind of snapshot that’s useful early: it gives security and engineering a shared view of “what we inherit the moment we adopt this.”
2) Vulnerabilities: critical and high findings in common components
Manifest identified 18 total vulnerabilities in the current inventory, including findings with Critical and High CVSS severities, across common npm dependencies.
Two practical observations matter here:
- Severity isn’t the whole story: CVSS is useful, but exploitability depends on reachability and context. That’s why you want an assessment output that supports prioritization (e.g., “mitigate” vs “monitor”), not just a long list.
- Transitive risk is real risk: many security incidents don’t come from your code—they come from the dependency graph you shipped by default.
In other words: even if Moltbot’s core is well-intentioned and actively maintained, you’re still inheriting the state of the ecosystem beneath it.
3) Licensing: “open-source” doesn’t mean “safe to ship”
Manifest flagged 7 forbidden license categories, including multiple GPL/LGPL variants and MPL-2.0.
While license risk is less relevant for everyday users of open-source tools, it can be if,and inevitably, when someone tries to commercialize the tool or incorporate it into their own internal products.
License risk is often treated as “legal’s problem,” but it becomes an engineering and security problem fast:
- It can block releases late in the cycle.
- It can force last-minute component swaps (which are risky and error-prone).
- It can create hidden compliance debt that’s expensive to unwind after adoption.
If you’re deploying a high-privilege automation tool, the last thing you want is to discover you can’t legally distribute or operationalize key pieces of the dependency chain.
4) Configuration matters, but you shouldn’t rely on perfect configuration
A lot of teams think about assistant risk primarily as “don’t expose it” or “run it locally.” Those are good instincts, but they’re not enough on their own.
A stronger posture assumes the uncomfortable truth: someone will misconfigure something. A secure deployment should be resilient even when:
- a service is reachable in ways you didn’t intend,
- credentials are broader than they should be,
- plugins are installed because they’re convenient, not because they’re reviewed.
That’s why dependency risk, patch posture, and governance controls matter just as much as network placement.
Disclaimer: This assessment reflects our review of the public moltbot/moltbot GitHub repository as analyzed using Manifest at the time of review. It is not a guarantee of security and should not be treated as a substitute for a full security audit. Risk can vary materially depending on how Moltbot is deployed, configured, integrated, and customized, including the specific packages, plugins, dependencies, and infrastructure used in an individual environment. Organizations should independently assess the complete deployed system—including all included packages and transitive dependencies—to identify additional risks.
Why You Should Assess OSS You Use it
Open source can be excellent, and often is. But “popular” and “safe to adopt” are not the same thing. In high-privilege categories like agent gateways, you need a repeatable way to answer:
- What are we inheriting on day one? (vulns, licenses, maintenance signals)
- What do we need to fix immediately vs. track?
- What’s our acceptable risk threshold for this class of tool?
- What controls reduce blast radius if something goes wrong?
A lightweight, practical pre-adoption checklist for tools like Moltbot:
- Inventory and SBOM: Know what you’re running (including transitive dependencies).
- Vulnerability triage: Patch what’s patchable; document reachability and compensating controls for what isn’t.
- License policy: Identify forbidden / restricted licenses early, before usage spreads internally.
- Least privilege by default: Scope tokens, isolate connectors, and separate “read” vs “act” capabilities where possible.
- Operational guardrails: Logging, alerting, and “break-glass” controls for credential rotation and connector disablement.
Closing: Viral Tools Don’t Get a Security Exception
Moltbot’s momentum is a signal: the “self-hosted agent” category is here, and teams will keep adopting it. The right response isn’t panic, it’s discipline.
Manifest’s assessment makes the core point visible: risk shows up in the dependency graph and in licensing long before an incident ever happens. If you assess early, you can make an informed decision: patch, constrain, replace components, or choose an alternative, before the tool becomes a privileged part of your environment.
Learn more about how Manifest can help you assess OSS risk before it enters your endpoints, CI/CD pipelines, or production code.
