T09 · Insecure Skill Coding Practices
- Location
SKILL.md:137- Finding
Gateway Credentials and Agent-Control Traffic Transmitted over Plaintext HTTP
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill matches its LAN peer-collaboration purpose, but it exposes an agent-control gateway and passes gateway tokens over plain HTTP, so users should review it carefully before use.
Use this only on a trusted, isolated LAN. Prefer binding the gateway to a specific LAN IP, restrict firewall rules to exact peer IPs, require gateway authentication, and use TLS or an encrypted tunnel before sending tokens or sensitive tasks. Do not run the sudo/admin firewall commands blindly, and rotate gateway tokens if they may have been exposed.
SKILL.md:137Gateway Credentials and Agent-Control Traffic Transmitted over Plaintext HTTP
SKILL.md:43Gateway May Be Exposed on All Network Interfaces
The skill instructs the agent to edit configuration files, create peer config files, and run shell/network commands, but it declares no explicit tool scope or permission boundaries. That increases the chance an agent platform will invoke file-write and shell capabilities implicitly, enabling broader-than-expected host changes during routine use.
The trigger phrases are broad enough to match ordinary collaboration requests, which could cause the skill to activate unexpectedly in contexts where network exposure and peer connectivity were not intended. That raises the risk of an agent proposing or performing network reconfiguration, file creation, or remote message routing under an ambiguous prompt.
The skill includes a privileged command that modifies the local firewall, which can materially change host network exposure. Even though the example restricts access to a trusted subnet, use of sudo in a broadly-triggered skill is dangerous because it can normalize privileged execution and lead to unintended opening of the gateway service.
Linux (ufw):
# Replace 192.168.1.0/24 with your trusted subnet
sudo ufw allow from 192.168.1.0/24 to any port 18789
Linux (iptables):
The iptables example requires root privileges and permanently alters packet-filtering behavior unless carefully managed. In the context of this skill, that is risky because it enables remote reachability of the gateway and may be applied incorrectly on systems where rule order, persistence, or broader accept rules create more exposure than the user expects.
Linux (iptables):
# Replace 192.168.1.0/24 with your trusted subnet
sudo iptables -A INPUT -s 192.168.1.0/24 -p tcp --dport 18789 -j ACCEPT
Windows:
Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
### "Connection timed out"
1. **Firewall blocking.** The most common issue.
- Linux: `sudo ufw allow from <trusted-subnet> to any port 18789`
- Windows: `New-NetFirewallRule -DisplayName "OpenClaw" -Direction Inbound -LocalPort 18789 -Protocol TCP -Action Allow -RemoteAddress <trusted-subnet>`
2. **Wrong subnet.** Both machines must be on the same subnet (or have routing between subnets).
The guide explicitly shows how to retrieve and pass a peer gateway auth token, but does not label the token as a sensitive secret or warn against exposing it in logs, screenshots, shell history, or shared notes. In a LAN peer-agent skill, that omission is meaningful because possession of the token appears sufficient to authenticate to the peer gateway, enabling unauthorized agent interaction if the token leaks.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
"""Try to detect the local LAN IP address."""
# Try ipconfig on Windows
try:
result = subprocess.run(
["ipconfig"],
capture_output=True, text=True, timeout=5
)
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
# Try ip on Linux/macOS
try:
result = subprocess.run(
["ip", "route", "get", "1.1.1.1"],
capture_output=True, text=True, timeout=5
)
The manifest frames the skill as enabling direct LAN collaboration between two OpenClaw agents. While network reachability is relevant, the documented capability extends into host firewall administration across Linux and Windows, which is broader than the core collaboration function and grants system-level network access changes not explicitly justified by the manifest.
No suspicious patterns detected.