OpenClaw Agent Mesh
WarnAudited by ClawScan on May 18, 2026.
Overview
The skill’s peer-messaging purpose is coherent, but its HTTP receive code can write files using peer-controlled IDs and appears to miss some promised message-safety checks.
Review this skill before installing or running the server. If you use it, bind the server only to a trusted interface, avoid exposing it to untrusted networks, and wait for fixes that sanitize peer-controlled filenames and fully enforce the documented verification rules.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If the HTTP server is running, a peer could choose IDs containing path separators or absolute paths to create or overwrite JSON files outside the intended request/message folders, potentially corrupting mesh state or other user-writable JSON files.
Received peer-controlled request_id and message_id values are concatenated into filesystem paths without validation, sanitization, or a check that the resolved path remains inside the intended state directories.
path = REQ_IN_DIR / f"{payload['request_id']}.json"
save_json(path, payload)
...
path = MSG_IN_DIR / f"{payload['message_id']}.json"
save_json(path, payload)Use locally generated safe filenames or strictly validate IDs with an allowlist; reject absolute paths, '..', and path separators; resolve the final path and verify it stays under the intended state directory before writing.
A trusted peer, or a replayed signed payload from that peer, could cause stale or incorrectly addressed messages to be persisted and acknowledged, weakening the trust boundary the skill advertises.
The visible receive-message logic accepts and acknowledges a message after signature verification, but does not show checks for message type, intended recipient, stale timestamp, duplicate/replayed message ID, or malformed envelope fields.
ok = verify_signature(unsigned, payload.get("signature", ""), peer["public_key"])
result = {"verified": ok, "message_id": payload.get("message_id")}
if ok:
path = MSG_IN_DIR / f"{payload['message_id']}.json"
save_json(path, payload)
result["ack"] = {"type": "ack", "message_id": payload["message_id"], "status": "received", "timestamp": now_iso()}Enforce the documented verification rules in code: validate required fields and type, check the recipient, reject stale timestamps, track message IDs to prevent replay, and fail closed on malformed envelopes.
Running the server makes the mesh node reachable on the configured interface and port until the process is stopped.
The skill includes a long-running HTTP server that defaults to all network interfaces. This is disclosed and aligned with discovery/messaging, but users should deliberately choose when and where to run it.
ap.add_argument('--host', default='0.0.0.0')
ap.add_argument('--port', type=int, default=8787)
...
httpd.serve_forever()Bind to 127.0.0.1 or a trusted interface unless LAN exposure is intended, use firewall rules where appropriate, and stop the server when not needed.
The skill may fail or behave differently depending on the user’s local openssl installation.
The script depends on the local openssl binary, while the provided registry requirements list no required binaries. This is an under-declared dependency rather than evidence of malicious behavior.
run(["openssl", "genpkey", "-algorithm", "Ed25519", "-out", str(priv)]) run(["openssl", "pkeyutl", "-sign", "-rawin", "-inkey", str(PRIVATE_KEY_PATH), "-in", str(in_file), "-out", str(sig_file)])
Declare openssl as a required binary and document supported versions; users should verify the installed openssl binary before using identity or signing features.