OpenClaw Ecosystem Security Risk Analysis

作者: 360漏洞研究院 分类: AI 发布时间: 2026-05-19 10:05

I. Overview

The continuous maturation and broad accessibility of OpenClaw’s core capabilities have generated significant industry attention. Thanks to its flexible and highly extensible underlying architecture, OpenClaw has not only supported a large volume of secondary development projects built upon it, but has also inspired many teams to leverage its design philosophy for independent in-house development, propelling the ecosystem toward multi-polar growth.

This prosperity is accompanied by a fundamental shift in product capability. Current Claw-based applications are gradually breaking free from the traditional “passive response” model of conventional tools, transitioning toward agents with autonomous decision-making capabilities. This capability leap inevitably demands that systems grant increasingly complex interfaces and broader permission boundaries. When these high-privilege, highly autonomous entities operate in untrusted network environments or face potential malicious attacks, the risk of losing control is dramatically amplified. Traditional security testing methodologies often struggle to effectively cover the dynamic logic and blurred boundaries of these highly proactive new application targets.

Against this backdrop, this report documents a deep-dive “vulnerability mining agent practice.” The 360 Vulnerability Research Institute deployed a proprietary vulnerability-mining agent to conduct a systematic security analysis of OpenClaw ecosystem products using an innovative “Agent vs. Agent” paradigm. Leveraging the agent’s efficient, fully automated end-to-end vulnerability discovery capabilities, the team successfully broke through the testing bottlenecks of complex applications, uncovering more than 20 security vulnerabilities in total, covering high-risk vulnerability types including remote code execution, authentication bypass, privilege escalation, and information disclosure.

Figure 1-1: OpenClaw Ecosystem Overview

Following an in-depth categorization and analysis of the rich vulnerability data and attack chains captured by the agent in real-world testing, we found that due to the unique evolutionary characteristics of the OpenClaw ecosystem, its potential security risks exhibit diversity, universality, and propagability, deeply permeating various derivative products. This report combines the findings of this agent practice and categorizes the OpenClaw ecosystem into three core analytical dimensions: OpenClaw architectural characteristics and defensive failure, security debt propagation in secondary development, and security challenges of open-source independent development. Around these dimensions, this report systematically analyzes the latent security risks in different application scenarios, with the goal of reinforcing the security foundation for the sustainable, healthy, and positive development of the Claw ecosystem.

II. Vulnerability List

This research covered OpenClaw core and 10 Claw derivative products. A total of 23 independent security vulnerabilities were confirmed through systematic analysis. All vulnerabilities have been reported to the respective vendors and developers for remediation follow-up, and have been submitted to authoritative bodies including the China National Vulnerability Database (CNNVD) and the China National Vulnerability Sharing Platform (CNVD). The table below summarizes vulnerabilities by product and vulnerability type:

No.Product NameVulnerability TypeCNNVD IDSeverity
1OpenClawInformation DisclosureCNNVD-2026-50773322High
2OpenClawInformation DisclosureCNNVD-2026-45978429Medium
3OpenClawDenial of ServiceCNNVD-2026-18369523High
4OpenClawAuthorization BypassCNNVD-2026-24759492Medium
5LobsterAIRemote Arbitrary File ReadCNNVD-2026-71027986Medium
6LobsterAIPath TraversalCNNVD-2026-82655690High
7AutoClawRemote Command ExecutionCNNVD-2026-01108369High
8ClawXInformation DisclosureCNNVD-2026-31313202Medium
9CoPawRemote Command ExecutionCNNVD-2026-22285599Critical
10CoPawRemote Command ExecutionCNNVD-2026-43521646Critical
11NanobotPrompt InjectionCNNVD-2026-78883522Medium
12NanobotServer-Side Request ForgeryCNNVD-2026-20334794Medium
13NanobotAccess Control BypassCNNVD-2026-20084544Medium
14NanobotAccess Control BypassCNNVD-2026-96922764Medium
15NanobotServer-Side Request ForgeryCNNVD-2026-22577557Medium
16NanobotAccess Control BypassCNNVD-2026-68396869High
17NanobotPath TraversalCNNVD-2026-86246607High
18MoliliRemote Command ExecutionCNNVD-2026-55617819High
19PicoClawAccess Control BypassCNNVD-2026-99907553High
20PicoClawAccess Control BypassCNNVD-2026-83686554High
21QClawLogic FlawCNNVD-2026-78347890Medium
22WinclawAuthentication BypassCNNVD-2026-30781760Medium
23ZeroClawAuthentication BypassCNNVD-2026-86380766High

The vulnerabilities shown above cover types including remote code execution, authentication and access control flaws, unauthorized file operations, prompt injection and information disclosure, and denial of service. This distribution is consistent with the characteristics of OpenClaw and its derivative products: multiple entry points, high privileges, heavy reliance on local services, and weak inter-component isolation.

To prevent security risk spillover and potential malicious exploitation, all specific vulnerability cases referenced in this report have been anonymized.

III. OpenClaw Architectural Characteristics and Defensive Failure Analysis

In the OpenClaw open-source repository, equally notable alongside its 370,000 GitHub Stars is the persistently high volume of security advisories. As of May 11, 2026, OpenClaw’s GitHub had cumulatively disclosed more than 535 security advisories, placing it at a conspicuously high level among comparable open-source projects during the same period. This objectively reflects a fact: while OpenClaw’s feature set has grown increasingly comprehensive, its attack surface has been rapidly expanding in parallel, with deep-seated security risks accumulating simultaneously.

Figure 3-1: OpenClaw Ecosystem Security Advisory Growth Curve

From a temporal perspective, the exposure of these security risks is displaying a clear acceleration trend. In the project’s early stages, security advisories were mostly published sporadically on a weekly basis; however, entering Q1 2026, the disclosure frequency has surged to an average of more than 4 per day. The underlying cause of this shift from sparse to dense disclosure lies in the pervasive “capability expansion over security constraints” development tendency prevalent throughout the current ecosystem. Aggressive feature iteration combined with comparatively lagging security integration has ultimately given rise to an increasingly severe systemic risk.

3.1 Architectural Characteristics

To better understand the root causes of vulnerabilities and attack scenarios reflected in these security advisories, analysis must be conducted in conjunction with OpenClaw’s core operational architecture. As an AI Agent gateway designed around the philosophy of local resource control, OpenClaw’s operation depends on three mutually nested foundational components:

Local Tool Calling Layer: Responsible for translating large model decisions into actual operations on local resources, including file reading/writing, command-line execution, browser automation, and dynamic code compilation. This layer directly interfaces with the operating system core and must strictly verify the identity of operation subjects and restrict the scope of operational permissions.

Network Layer: Supports bidirectional data exchange between the Agent and the external world. On one hand, the Agent needs to proactively fetch web pages, call external APIs, and download resources; on the other hand, the system exposes HTTP services, WebSocket connections, and RPC ports locally to receive external requests. This layer must ensure that entry points are legitimate and exit points are controllable.

Control Plane: Uses a large language model as the hub to translate natural language instructions into task plans and orchestrate tool execution. This layer continuously receives and comprehends multi-source inputs (user instructions, web content, tool feedback) and must ensure that instruction sources are trustworthy and decision processes are tamper-proof.

The interaction relationships among these three component layers determine that OpenClaw’s security defense cannot rely on single-point mechanisms; a defense-in-depth system covering four dimensions must be constructed: the authentication boundary (who has the right to access local services), the network boundary (which network surfaces are permitted to be reached), the execution boundary (how high-privilege operations are physically isolated), and the control boundary (how decision instructions are verified). Ideally, these four boundary layers should advance progressively and serve as mutual backstops: the authentication boundary blocks unauthorized accessors, the network boundary reduces the attack surface, the execution boundary confines breaches within isolated environments, and the control boundary ensures that even if the first three layers are breached, core decisions cannot be hijacked.

3.2 Defensive Boundary Failures

Despite the architecture’s well-designed defensive blueprint, in OpenClaw’s actual code implementation and complex operating environment, the ideal defense-in-depth system often proves difficult to sustain. The breakdown of one layer frequently opens gaps in other boundaries, meaning any single-point breakthrough can laterally spread into systemic loss of control. This section classifies attack paths based on specific issues disclosed in security advisories and analyzes the real security vulnerabilities that have occurred at each defensive boundary.

3.2.1 Authentication Boundary: Multi-Path Authentication and Authorization Gaps

The core responsibility of the authentication boundary is to verify the “legitimacy of the operating subject.” To accommodate diverse interaction requirements, OpenClaw has designed a complex permission system ranging from device pairing to multi-level management, and has opened multiple access channels including local CLI, WebUI, and API calls. Ideally, each access entry point should complete permission verification at its corresponding entry, forming rigorous authentication control.

Figure 3-2: Authentication Boundary Bypass Vulnerability via gatewayUrl

However, security advisory data shows that authentication and access control vulnerabilities account for an extremely high proportion of OpenClaw security advisories. The root cause lies in the fact that the multi-layered permission model and the intersecting access channels, when combined, tend to create verification blind spots in code implementation. Attackers can breach the first line of defense at relatively low cost through locally unauthenticated interfaces, WebSocket authentication bypasses, and cross-platform credential reuse, gaining opportunities for subsequent lateral movement.

3.2.2 Network Boundary: Bidirectional Data Flow and Uncontrolled Exposure Surface

If the authentication boundary governs access subjects, the network boundary governs the “legitimate flow direction of data and connections.” As a highly interactive Agent, OpenClaw needs to both proactively reach outward (fetching web pages, calling third-party APIs) to obtain context, and must provide local service listeners to receive external commands.

Figure 3-3: SSRF Vulnerability Breaching Network Boundary

This conflict between “maintaining high-frequency external awareness” and “constraining one’s own exposure surface” causes traditional boundary defenses to become blurred at this point, with network-layer risks such as SSRF (Server-Side Request Forgery) and protocol bypass appearing repeatedly. More critically, once the upstream authentication boundary has verification blind spots, OpenClaw’s built-in powerful external resource acquisition toolchain becomes a pivot for internal network reconnaissance and lateral penetration. At this point, network boundary defense is no longer simply blocking external malicious traffic, but evolves into addressing the problem of system attack surface expansion.

3.2.3 Execution Boundary: Fragmented Isolation and Sandbox Penetration

The execution boundary is responsible for solving “the physical and logical isolation of high-privilege operations.” OpenClaw’s design philosophy grants the Agent extremely high system-level control capabilities, which compels the system to rely on sandbox mechanisms to limit potential damage. This constitutes the most fundamental challenge of the execution boundary: approaching the core capabilities of the operating system as closely as possible while limiting the scope of damage.

Figure 3-4: Low-Privilege User Privilege Escalation Vulnerability

In the actual architecture, OpenClaw’s tool calling layer allows the Agent to autonomously trigger external executables, browser instances, script interpreters, and even container runtimes based on task requirements. However, sandbox implementation exhibits obvious fragmentation characteristics: Docker containerized isolation, host elevated privilege execution, and pure logical policy constraints coexist in three modes, with dynamic switching by session/proxy/sharing. The lack of a unified mandatory connection mechanism between different isolation levels enables attackers to find escape paths in the gaps between layers of defense.

The frequently appearing sandbox escape, privilege escalation, and indirect command execution via tool chain stitching problems in security advisories indicate that as long as the Agent retains the privilege to execute underlying commands, any oversight in input filtering or misconfiguration of the runtime environment will be acutely detected by attackers, converting restricted tool calls into absolute system-level control.

3.2.4 Control Boundary: Instruction Trustworthiness and Task Hijacking

The goal of the control boundary is to ensure that “the user’s core intent is not tampered with.” This boundary must ensure that instruction sources are trustworthy, that decision processes do not violate user intent, and that malicious instructions are intercepted.

However, unlike traditional software that relies on static code to determine execution paths, OpenClaw’s behavioral trajectory depends entirely on the large language model’s non-deterministic reasoning over multi-source information. Under this paradigm, “data is instruction.” User inputs, residual web content, installed Skills, tool return results, and even file metadata can all act as components of the Prompt to directly influence model decisions. This open-ended input mode makes it fundamentally impossible for the system to block malicious intent through simple blacklists and whitelists. For example, as a key component for extending Agent capabilities, the supply chain security of Skills directly relates to the security of the control flow. The large-scale supply chain poisoning incident of Claw Havoc in February of this year directly demonstrated that this attack method has been widely deployed against this class of Agent.

The large volume of prompt injection and session pollution vulnerabilities addressed in security advisories reveals an as-yet-unresolved architectural contradiction: needing to fully accept multi-source inputs to maintain intelligent emergence while also ensuring the absolute security of every implicit instruction. When attackers infiltrate the system through the aforementioned boundary vulnerabilities, the Agent’s own advanced reasoning and autonomous planning capabilities actually become attack amplifiers. Attackers need only pollute the input context to “legitimately” hijack the Agent’s execution logic, rendering all underlying physical and network isolation defenses moot.

Figure 3-5: Approval Authorization Bypass Vulnerability

This high-severity authorization bypass vulnerability was discovered by the 360 vulnerability-mining agent. Leveraging its built-in attack surface analysis module, the agent was able to quickly understand OpenClaw’s complex architectural characteristics, effectively construct threat models, and conduct in-depth mining of its weak points. After analyzing OpenClaw’s script approval and execution workflow, the agent found that the system only verified the approval status of scripts without performing integrity verification to check whether script content had been tampered with. Attackers can exploit this flaw to maliciously replace code after a script has been approved, thereby executing illegal operations on the target endpoint, leading to information theft, file tampering, or even complete system compromise.

3.3 Summary

Based on the above analysis, OpenClaw’s security posture exhibits the classic characteristic of “capability expansion overriding boundary constraints.” The 535 security advisories that surged in just a few months are not only the derivative cost of aggressive feature iteration, but also expose the systemic fragility of its underlying architecture when facing complex threats.

The most severe challenge lies in the “domino effect” of defensive boundaries: the authentication, network, execution, and control boundary layers are highly coupled and mutually dependent, meaning any breach in a single dimension will trigger a cascading collapse of the protection system. These hazards rooted in the architectural depths are destined to be fundamentally unsolvable through conventional single-point patch-style fixes. Of even greater consequence is the fact that as OpenClaw is widely deployed as a core technology foundation, these inherent architectural deficiencies are inevitably propagating as a heavy security debt throughout the entire downstream ecosystem. Whether through direct code inheritance or independent development, derivative products in the Claw ecosystem all face the systemic risk of having hazards inherited and spread.

IV. Security Debt Propagation in Secondary Development

Technological accessibility is often accompanied by a lowering of barriers to entry. Although OpenClaw possesses powerful native capabilities, its complex configuration options once limited its audience primarily to technically sophisticated users. To make the convenience of AI Agents accessible to a broader general audience, many vendors and developers have re-encapsulated it, polishing out-of-the-box Claw-like products.

However, this user-friendly delivery that “black-boxes” complex underlying technology has also inadvertently concealed deep-seated systemic risks. When products race ahead at breakneck speed driven by agile development to seize market share, security defenses are often left behind. To clarify how these risks have spread throughout the entire ecosystem, we need to return to the source code: on one hand, examining how OpenClaw’s development model has imperceptibly accumulated “security debt”; on the other hand, deeply analyzing how these hazards are inherited and compounded in secondary development code chains, ultimately evolving into real threats that end users must confront.

4.1 Feature-First: The Hidden Cost Behind “Vibe Coding”

OpenClaw developers have stated in multiple public interviews that the project’s rapid iteration has relied heavily on “Vibe Coding” — a development paradigm in which large models assist or even lead code generation. While this model has greatly unleashed productivity, it has also imprinted inherent security genetic defects. Current AI, when generating code, focuses primarily on getting features to work (implementation efficiency and correctness) rather than on defending against malicious attacks.

In the project’s early stages, developers can easily fall into a pragmatic trade-off: every added capability of the Agent directly translates into improved user experience and market attention, while underlying security hardening is a defensive engineering effort that is invisible, intangible, and difficult to quantify. Under a feature-first product orientation, security design is naturally deferred. When this massive “technical debt” must eventually be settled as the project matures, the cost of underlying refactoring grows exponentially.

4.2 Internal and External Pressures in Secondary Development

Thanks to the permissive MIT open-source license, developers can easily conduct secondary development based on OpenClaw. However, as code is widely copied and distributed, the source’s security hazards are also propagating downstream through the software supply chain.

Moreover, code inheritance is not the only pathway for risk spread. Through a survey of 5 typical derivative products on the market, we found they commonly adopt an architecture of “using OpenClaw as the core runtime with new product-side features layered on the periphery.” This integration approach constitutes a dual source of threats: on one hand, derivative products inevitably carry the historical security debt of upstream projects; on the other hand, new features introduced to pursue competitive differentiation often lack rigorous security audits, creating new attack surface openings.

In this regard, the 360 vulnerability-mining agent has demonstrated powerful analytical capabilities. Leveraging built-in Software Composition Analysis (SCA) and historical vulnerability database comparison, the agent can efficiently locate unfixed upstream vulnerabilities; simultaneously, relying on its reusable and continuously evolving security expert knowledge base, the agent can acutely detect potential hazards in new feature code. The following provides an in-depth analysis of the specific manifestations of these two types of risks, combining the agent’s research findings.

(1) Internal Pressures: Version Discrepancies Under Native Inheritance

This is the most common and hardest-to-avoid propagation mode. Seeking extreme simplicity in deployment, some derivative products choose to directly bundle OpenClaw’s core components in binary form within their installation packages. In this approach, OpenClaw’s own deficiencies are synchronized to downstream products along with the distribution. When security issues arise in the OpenClaw project, downstream developers often lack advance warning channels and also struggle to independently patch OpenClaw. Only after the upstream open-source community releases a patch, followed by a lengthy cycle of packaging, testing, and deployment, can a vulnerability be remediated. Claw products running during this patch time gap are left in an unprotected and vulnerable state.

Case: Certain Claw1 Canvas Authentication Bypass

Certain Claw1 is an enterprise-grade secondary encapsulation product that includes an OpenClaw component as its core runtime. Research found that the OpenClaw component in the then-latest version contained an unpatched Canvas authentication bypass vulnerability (ZDI-CAN-29311).

Figure 4-1: Certain Claw1 Containing ZDI-CAN-29311 Old Version Vulnerability

This vulnerability stems from a defect in the authentication fallback mechanism for IP addresses in the authorizeCanvasRequest function. After a WebSocket client authenticates via a private IP address, all subsequent HTTP requests from that IP are granted Canvas access permissions without requiring independent identity verification. More seriously, attackers can also bypass authentication by forging proxy headers (X-Forwarded-For), thereby gaining unauthorized control over the entire system. This vulnerability fully inherits defects from OpenClaw’s native code; downstream developers failed to update to the patched version in time when packaging, exposing users to the risk of remote unauthorized access.

Beyond the delayed patching problem caused by the asynchronous development pace of derivative products and upstream security fixes, if derivative products have made other deep customizations to OpenClaw, directly upgrading versions may introduce compatibility issues, which to some degree further delays the application of security patches.

(2) External Pressures: Attack Surface Expansion from Differentiated Features

Some products that encapsulate OpenClaw, while retaining core functionality, add new feature modules to pursue competitive differentiation. These new features often involve independent network interfaces, special file handling logic, or script execution mechanisms, but may not have been sufficiently considered from a security design perspective, creating security vulnerabilities.

Case 1: Certain Claw2 External Page Controls Browser

Certain Claw2 added a browser automation control feature (browser-agent) during encapsulation, giving the Agent the ability to autonomously operate web pages. However, the relay service for this feature exposed an unauthenticated WebSocket port when running locally, allowing any external page to connect and control the running browser.

Figure 4-2: Principle Diagram of Certain Claw2 External Malicious Page Controlling Browser

In this scenario, an attacker lures a user to visit a malicious webpage, which connects to the relay service via the fetch API and sends malicious instructions to control the browser launched by Certain Claw2 to visit the address http://127.0.0.1:<port>/get_token, allowing token theft. This token can subsequently be used for user authentication, inference requests, and file upload operations, causing serious account takeover issues. The fundamental cause of this vulnerability is that the newly added browser control feature did not implement appropriate identity verification and origin validation for its communication channel, enabling a service intended to run only locally to be directly accessed and interacted with by external web pages.

Case 2: Certain Claw3’s Email and Web Search SKILL Defects

Certain Claw3 provides additional Skills beyond OpenClaw’s foundation to enhance Agent capabilities. The download attachment feature in its email service Skill (email-skill) does not filter email attachment filenames. Attackers can overwrite critical system executables by sending malicious attachments with path traversal filenames.

Figure 4-3: Certain Claw3 Email Skill Directory Traversal Related Code

Additionally, its built-in web_search feature runs by default listening on local port 8923. This feature has incorrect CORS configuration, resulting in request origins not being effectively verified, enabling attackers to trigger web_search via malicious web pages to search local files and return content to the attacker.

Figure 4-4: Certain Claw3 web_search Related Dangerous Code

The above cases illustrate typical characteristics of the “feature introduction” pattern: in the process of secondary developers pursuing product differentiation, newly added feature modules often bring new attack surfaces. These overlap with OpenClaw’s native network, authentication, and other boundaries, forming more complex exploitation chains.

4.3 Summary

OpenClaw’s security hazards, as they spread downstream through the ecosystem, exhibit a clear risk compounding effect. Historical vulnerabilities directly carried by underlying core components, and vulnerable interfaces exposed by peripheral new business logic, often coexist and interact in actual operating environments. This combination of internal deficiencies and external openings causes derivative products to face attack paths far more complex than those of the native project.

This situation reveals the practical difficulties facing current ecosystem security governance. Given the objective premise that legacy issues in underlying infrastructure cannot be completely resolved in the short term, relying solely on downstream developers’ security awareness is already insufficient to effectively block risk propagation. To truly sever this systemic threat diffusion, it is necessary to transcend the traditional thinking of relying solely on code patching and instead build, from the underlying architecture level, a system-level defense framework that can effectively operate even when local components or specific features are compromised.

V. Security Challenges of Open-Source Independent Development

Unlike secondary development that directly encapsulates the native framework, some developers choose to independently reconstruct systems by absorbing OpenClaw’s core architectural philosophy. Such projects typically streamline redundant modules, customize features for specific business needs, and attempt to strengthen underlying protection during the rewriting process. From a code provenance perspective, this completely independent rewriting path does indeed sever the direct propagation chain of upstream historical vulnerabilities.

However, risks have not ended there. We used the 360 vulnerability-mining agent to conduct systematic security audits of multiple independently developed products. Leveraging the agent’s semantic-level code understanding, cross-file data flow tracking, and AI-driven logical reasoning capabilities, we successfully discovered security issues in these products.

Audit results indicate that departing from the native codebase has not truly eliminated systemic risks. The security challenges these products face are primarily concentrated at two levels: first, convergence in underlying design paradigms leading to recurrence of vulnerability patterns; second, new defensive mechanisms introduced to compensate for native deficiencies, which, due to imprecise global design assumptions or deviations in boundary code implementation, instead become unintended new attack entry points.

5.1 Continuity of Vulnerability at the Design Paradigm Level

Open-source independently developed products, in terms of their core positioning, still follow the same fundamental assumptions as OpenClaw: emphasizing local execution priority, maintaining complex network communications, possessing deep system resource control capabilities, and supporting multi-channel real-time interaction. This underlying architectural requirement determines that the system must handle extremely complex permission partitioning and data flow logic.

When developers replicate this complex operational logic into an entirely new codebase, the accompanying defensive boundary conflicts will inevitably migrate along with it. Typical vulnerability patterns identified in OpenClaw continue to appear at high frequency in these completely independently rewritten products. This reveals a critical engineering fact: abandoning the native codebase cannot circumvent vulnerability recurrence across implementations caused by architectural commonality. The same underlying design paradigm ultimately leads to highly similar security protection blind spots.

To specifically illustrate this continuity of architectural vulnerability, we use an open-source independently developed Claw as an example for comparative analysis. In handling its core business logic, this project precisely reproduces typical vulnerabilities that have appeared historically in OpenClaw.

Case:

External Request Handling and SSRF Risk

When executing tasks, Agents inevitably need to initiate external network requests. How to accurately intercept malicious URLs targeting internal networks is a common security challenge that all such products must address. In OpenClaw’s historical records (such as multiple security advisories including GHSA-8cp7-rp8r-mg77), cases of Server-Side Request Forgery (SSRF) caused by filtering logic failing to cover special formats such as IPv6-to-IPv4 transition addresses are extremely prevalent.

Open-source independently developed Claw4 has fallen into the same trap. Despite its code being completely rewritten and detection logic for local and private network addresses being added in the request module, it still misses some edge cases. Attackers need only craft a request like http://[::ffff:127.0.0.1] to directly bypass the existing detection mechanism, causing the Agent to initiate reconnaissance and attacks toward the local loopback interface of the running environment.

Figure 5-1: Open-Source Independently Developed Claw4 Request IP Detection Related Code Implementation

External Message Flow and Path Traversal Risks

Supporting integration with various instant messaging platforms has become a standard configuration for current Claw-type products. However, the diverse external message carriers greatly increase the security difficulty of input processing. OpenClaw once had an arbitrary file read vulnerability (GHSA-f6pf-4gjx-c94r) caused by failing to filter filenames of media-type files in external requests, resulting in path traversal.

In the independent implementation of open-source independently developed Claw5 handling Feishu platform user messages, we detected similar security issues. The system, when receiving message attachments, directly performs file path concatenation without executing strict character normalization validation of filenames. As shown in Figure 5-2, attackers can send malicious files with directory traversal characters via Feishu to exceed the working directory limits set by Claw5, writing files directly into higher-level directories of the operating system rather than Claw5’s working directory.

Figure 5-2: Open-Source Independently Developed Claw5 Feishu Implementation Path Traversal Demonstration

It can be seen that code refactoring lacking a systematic defensive perspective will ultimately only cause the same security vulnerabilities to recur repeatedly in different product implementations.

5.2 Logic Gaps in New Security Mechanisms

Based on awareness of historical vulnerabilities in the native architecture, some open-source independently developed products introduce customized security hardening mechanisms for key defensive boundaries when rewriting code. The original intent of such improvements is to patch known weaknesses in underlying defenses. However, the basic laws of systems security engineering indicate that any layering of security mechanisms will inevitably increase the overall complexity of the code.

In agile development processes lacking global threat modeling, these newly added defensive logic tend to focus on only a single attack dimension. Interception rules written by developers to defend against specific threats are easily prone to design disconnects when interacting with other basic system functions (such as network parsing and file operations). This causes mechanisms originally intended to raise the security baseline to instead become entirely new attack entry points due to their own implementation deviations.

Case 1: Authentication Mechanism Reinforcement Causing Defense Penetration

Open-source Claw6 is a lightweight cross-platform AI assistant independently developed in Rust. To circumvent the vulnerability of the native architecture in authentication, its developers adopted a minimal interface exposure strategy and introduced a dynamic credential generation mechanism based on a six-digit numeric pairing code.

When Claw6 is deployed on the public internet, it exposes 3 unauthenticated API endpoints. Among these, /api/pair generates subsequent request authentication tokens based on the pairing code generated at Claw6 startup. The pairing code range is [0, 1,000,000), presenting the possibility of being maliciously brute-forced by unauthorized requests. Considering the small pairing code space and the risk of exhaustion, the system also deploys an anti-brute-force strategy on the server side, which intercepts and locks clients making overly frequent requests.

In-depth research revealed that the server’s sole basis for identifying independent clients is only the X-Forwarded-For field in HTTP request headers, without combining it with the underlying real socket IP for joint verification. This shallow identity recognition logic enables attackers to simulate multiple clients by forging HTTP request headers to bypass the anti-brute-force defense mechanism, easily exhausting the computational space of pairing codes, thereby obtaining administrator tokens with the ability to modify configurations or execute commands.

The figure below demonstrates bypassing rate limiting and obtaining token values through brute force within acceptable time costs:

Figure 5-3: Claw6 Token Value Brute Force

After obtaining the token, it can be used to successfully access the WebUI page:

Figure 5-4: Claw6 Unauthorized WebUI Access via Token

It is worth noting that because modern browser engines at the underlying level strictly limit the ability of frontend web scripts to tamper with specific network request headers, this type of attack primarily poses a real threat to server endpoints directly exposed to the public internet environment.

Case 2: Bypass of Control Boundary Scanning Mechanism

Open-source Claw7 is a personal assistant tool developed based on a specific large model ecosystem. Given the frequently occurring supply chain security incidents involving third-party extension components, its developers introduced a dedicated security scanner for the control boundary. This mechanism performs mandatory static auditing of the execution environment and dependency scripts of any external component before it is activated and called, to prevent malicious instructions from interfering with core business logic.

The problem is that the local security hardening did not keep pace with the overall functional design. The Claw7 system simultaneously retains a compressed file upload interface for restoring workspace data. This business interface, when handling file decompression, only performs basic filtering of illegal directory traversal characters, without deep auditing of file content. Attackers can pre-construct zip archives containing malicious execution scripts, legally upload them through the data recovery interface, and overwrite the scripts/run.py file in an activated Skill directory, thereby bypassing the SkillScanner security scanning mechanism and executing arbitrary code when the Skill is called.

The attack flow is illustrated below:

Figure 5-5: Claw7 Malicious SKILL Overwrite Achieving RCE Flow Diagram

5.3 Summary

Open-source independent development is by no means the end of underlying security hazards, but rather an implicit transformation of the risk form. On one hand, without reflection on core architectural design, mere code rewriting fundamentally cannot block the cross-project propagation of inherent vulnerabilities. On the other hand, local defensive hardening that departs from a global perspective will instead catalyze entirely new attack openings due to the increased complexity of code interaction logic.

Therefore, scattered patching and feature trimming targeting single nodes cannot achieve ecosystem-level security evolution. The challenges faced by current independently developed products are essentially not implementation defects at the code dimension, but the passive continuation of classical upstream architectural design DNA. If security mechanisms are always positioned as supplementary constraints after feature expansion rather than as non-negotiable foundational prerequisites, then any level of technical reconstruction can only remain superficial.

VI. Conclusion

The explosive evolution of the OpenClaw ecosystem is a classic microcosm of AI Agent technology transitioning from theoretical conception to engineering implementation. Regardless of how the market attention of a single underlying framework evolves, the related derivative products have already deeply penetrated high-value scenarios including code development, data processing, and endpoint operations and maintenance. The user base is rapidly expanding from professional R&D personnel to ordinary users seeking to leverage AI to enhance life and work efficiency. When such highly automated systems broadly acquire permissions for local file reading/writing, network service calls, and critical system command execution, their potential security radiation has completely transcended the physical boundaries of personal devices, directly posing substantive threats to enterprise core internal networks and critical business processes. The actual combat exercise of the vulnerability-mining agent in this research is a real-world confirmation of this grave threat landscape.

Based on in-depth auditing of OpenClaw’s native architecture and 10 derivative products by the proprietary vulnerability-mining agent, this report organizes the real threats currently facing the Claw ecosystem across three dimensions: underlying architectural defense failure, supply chain code inheritance hazards, and architectural commonality challenges in open-source independent development. The complex attack chains constructed by the agent in automated offensive and defensive operations indicate that the field is not facing a fragmented set of vulnerability remediation challenges, but rather a comprehensive proliferation of systemic security legacy issues under a “feature-supremacy” orientation. Inherent deficiencies in underlying frameworks are being passively inherited downstream through static code bundling; peripheral new business logic continuously tears open new attack surface openings; even independently developed products that have departed from the native codebase are inadvertently reproducing the same categories of issues by following the same underlying design paradigms.

Faced with this cross-boundary risk propagation, traditional governance mechanisms relying on post-hoc patch distribution and passive response have already failed. The long-term healthy development of the ecosystem urgently requires the entire developer community to complete a cognitive leap from local patching to systemic defense. Security mechanisms must no longer continue to serve as supplementary constraints after feature expansion, but must become the absolute cornerstone of product development. Only by strictly adhering to the engineering principles of security-by-default, least privilege, and defense-in-depth across the four core boundaries of authenticated access, network flow, execution isolation, and control decision-making can the unknown challenges posed by highly autonomous Agent systems be effectively addressed.

This report, based on the vulnerability distribution patterns and risk evolution paths accumulated through the vulnerability-mining agent practice, represents not only a comprehensive security health check of the current Claw ecosystem, but is also intended to provide engineering references with real-world value and defensive support for the future more broadly-based intelligent application ecosystem.