Skill flagged — suspicious patterns detected
ClawHub Security flagged this skill as suspicious. Review the scan results before using.
S2G - General Purpose Workflow Engine
v1.0.0Connect to S2G (s2g.run) visual workflow automation platform over WebSocket. Execute workflow nodes as tools — password generators, hash functions, date math...
⭐ 2· 507·0 current·0 all-time
byHelmuts Reinis@helmutsreinis
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The name/description match the code: it is a WebSocket bridge that discovers S2G workflow nodes and exposes them as local tools. However the included docs and reference material also show REST management operations (X-API-Key examples) and many node types (databases, cloud connectors, Knowledge Base, AI providers). While these capabilities are consistent with an S2G bridge, they mean the agent will be able to trigger workflow nodes that can access external systems and potentially sensitive data — this is expected functionally but elevates risk and should be intentionally limited in workflows.
Instruction Scope
SKILL.md instructs the agent / operator to copy and run a local Node.js bridge which: (a) maintains an outbound WSS connection to s2g.run and auto-discovers nodes; (b) accepts pushed data from workflows (Input Forwarding), which can contain arbitrary upstream data; and (c) exposes a local HTTP API that allows executing arbitrary nodes by name or ID. The docs also include examples that encourage reading local credential files (e.g., ~/.config/s2g/credentials.json) for X-API-Key use. These instructions do not ask for unrelated system credentials, but they explicitly enable workflows to push data into the agent and to run nodes that may perform DB queries, cloud access, or file operations — all of which can surface sensitive data. Additionally, the bridge logs incoming messages, which may persist sensitive payloads.
Install Mechanism
There is no remote download/install: the skill is instruction-only and bundles the bridge script. Installation steps are local (copy script, npm install ws). This is low-to-moderate risk from an install perspective because nothing is fetched from an untrusted URL in the install spec; the only external install is the standard 'ws' npm module.
Credentials
The skill declares no required env vars but supports optional S2G_SECRET, S2G_NODE_ID, S2G_WS_HOST and allows S2G API usage elsewhere in docs (X-API-Key). The reference docs include snippets that read a local credentials file, which could encourage access to user secrets not required by the bridge runtime. Requested environment access (node id, optional secret) is proportionate to the bridge function, but the broader documentation implicitly expects API keys for REST management — review and limit where those keys live and who/what can read them.
Persistence & Privilege
The skill does not force 'always: true'; it runs on demand. However the documentation explicitly recommends running the bridge as a long-lived service (systemd/pm2/nohup), which gives it persistent presence and automatic reconnection. Persistent autostart is normal for a bridge, but combined with the local HTTP API and the potential to expose many powerful remote nodes, persistence increases the blast radius if misconfigured or if local network access is not restricted.
What to consider before installing
Key things to consider before installing:
- Network exposure: By default the bridge's HTTP API is documented as binding to the host network (docs note 0.0.0.0) and sets Access-Control-Allow-Origin: *. Ensure the service is bound to localhost only (127.0.0.1) or protected by firewall rules so other machines cannot call /execute or /reconnect. If you must use 0.0.0.0, restrict access via host firewall.
- Authentication: Set an Auth Secret on the OpenClaw node and start the bridge with --secret (or S2G_SECRET). Do not leave the OpenClaw node unauthenticated if the workflow exposes privileged nodes.
- Limit workflow node exposure: When designing the S2G workflow that the bridge connects to, only wire the OpenClaw node to the specific, minimal set of tool nodes you trust. Avoid exposing DB, cloud connectors, or file-write nodes unless explicitly needed.
- Secrets & credentials: The docs show examples using an X-API-Key and even reading a local ~/.config/s2g/credentials.json — avoid placing other service credentials in widely readable files, and do not let the bridge or workflows access unrelated secrets. Prefer short-lived keys and least privilege for any API keys configured in S2G.
- Logs & data retention: The bridge writes logs (logs/s2g-bridge.log) and may record incoming payloads. Ensure log directories are protected and rotated, and that sensitive payloads are not retained longer than necessary.
- Run as an unprivileged user: If you run the bridge as a service, run it under a dedicated, restricted user account, and avoid giving it access to unrelated files or system credentials.
- Review the workflow node list and schemas: Before executing unfamiliar nodes, query the node schema (catalog) to understand exact parameters and what the node can do. Be particularly careful with Knowledge, Database, Cloud connector, and Custom_ nodes that may execute arbitrary code or access external systems.
- If unsure, test in an isolated environment: Run the bridge from an isolated VM or container with no sensitive network access until you are confident about the workflow and its behavior.
If you want, I can: (a) point to the exact lines in the bridge script that open sockets, bind the HTTP server, and write logs; (b) suggest a minimal patch to force the HTTP server to listen on localhost only; or (c) highlight which node types (from the provided catalog) are highest-risk.Like a lobster shell, security has layers — review code before you run it.
latestvk971aymzhzyk57rgw1w97bfces81qt0x
License
MIT-0
Free to use, modify, and redistribute. No attribution required.