Back to skill

Security audit

Web Dashboard Optimizer

Security checks for vulnerabilities and agentic risk

Overview

This is a dashboard template, but it needs review because its sample server and helper scripts can expose monitoring data and keep a local service running without enough safeguards.

Review and harden the generated code before using it with real monitoring data. Bind the server to 127.0.0.1 unless intentionally exposing it, remove wildcard CORS, add authentication for sensitive data, avoid innerHTML for untrusted content, use a private runtime directory, and do not run the documented kill -9 port command unless you have verified the target process.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:262
Finding
DOM-based cross-site scripting through unsafe modal content rendering<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 262-274 **Vulnerability Type**: DOM-based cross-site scripting (DOM XSS) **Risk Level**: High ### Vulnerable Code ```javascript function openModal(title, content) { if (isModalOpen) return; isModalOpen = true; // Save scroll position const scrollY = window.scrollY; document.body.style.top = -scrollY + 'px'; document.body.classList.add('modal-open'); document.getElementById('modalTitle').textContent = title; document.getElementById('modalBody').innerHTML = content; document.getElementById('modal').classList.add('show'); } ``` ### Technical Analysis The `openModal()` function assigns its `content` argument directly to the `innerHTML` property. Unlike the title, which is safely assigned through `textContent`, modal content is interpreted as HTML without sanitization or an allowlist. If monitored data, API responses, database records, filenames, task descriptions, or other attacker-controlled values are passed to `openModal()`, an attacker can inject executable markup. Payloads can use event-handler attributes or other browser-supported HTML execution mechanisms. The template also does not define a restrictive Content Security Policy that could mitigate inline script execution. This creates a reusable unsafe rendering primitive that is likely to become exploitable when users customize the dashboard to display real data. ### Attack Path 1. A user customizes the dashboard to display task descriptions or records obtained from an API, database, or monitored file. 2. An attacker gains control over one of the values displayed in a modal. 3. The application passes the attacker-controlled value to `openModal()` as `content`. 4. The function assigns the value to `modalBody.innerHTML`. 5. The browser parses the supplied value as markup and executes an injected event handler or equivalent active content. 6. The payload runs with the dashboard origin's b ...[truncated 810 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Use `textContent` when modal content is intended to be plain text: ```javascript document.getElementById('modalBody').textContent = content; ``` - If formatted HTML is a requirement, sanitize it with a maintained, allowlist-based HTML sanitizer before inserting it. - Do not construct HTML by concatenating API or user-controlled strings. Build DOM nodes and assign untrusted values through `textContent`. - Add a restrictive Content Security Policy, such as one that disallows inline scripts and event handlers. - Trace every call to `openModal()` and validate whether its content can originate from an API, database, file, URL parameter, or user-controlled record. - Add automated tests containing HTML event-handler payloads to verify that input is rendered as inert text. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:344
Finding
Unauthenticated dashboard API exposed on network interfaces with wildcard CORS<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 344-366 **Vulnerability Type**: Insecure network exposure and missing access control **Risk Level**: High ### Vulnerable Code ```javascript const server = http.createServer((req, res) => { // CORS res.setHeader('Access-Control-Allow-Origin', '*'); if (req.url === '/' || req.url === '/index.html') { res.writeHead(200, { 'Content-Type': 'text/html' }); res.end(html); return; } if (req.url === '/api/data') { res.writeHead(200, { 'Content-Type': 'application/json' }); res.end(JSON.stringify(getData())); return; } res.writeHead(404); res.end('Not Found'); }); server.listen(PORT, () => { console.log(`📊 监控面板已启动`); console.log(` 访问地址:http://localhost:${PORT}`); console.log(` API: http://localhost:${PORT}/api/data`); }); ``` ### Technical Analysis The server does not implement authentication or authorization for either the dashboard or `/api/data`. Calling `server.listen(PORT)` without specifying a host generally binds Node.js to an unspecified address, making the service available through non-loopback interfaces where network policy permits it. The response additionally sets `Access-Control-Allow-Origin: *`, allowing scripts hosted by any origin to read the API response when they can reach the service. Although the example data is synthetic, the Skill explicitly instructs users to replace `getData()` with database, API, or file-backed data. That customization can turn the endpoint into an unauthenticated information-disclosure interface. Wildcard CORS is not the cause of direct network reachability, but it expands exposure by allowing an arbitrary website loaded in a victim's browser to read responses from the dashboard. ### Attack Path 1. A user follows the Skill and replaces `getData()` with monitoring information from a database, API, or local file. 2. The server is launched wi ...[truncated 1108 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Bind to the loopback interface by default: ```javascript server.listen(PORT, '127.0.0.1', () => { console.log(`Dashboard available at http://127.0.0.1:${PORT}`); }); ``` - Require explicit configuration before exposing the service on external interfaces. - Add authentication and server-side authorization before returning monitoring data. - Replace wildcard CORS with a strict allowlist of trusted origins, or omit CORS entirely when cross-origin access is unnecessary. - Place remotely accessible deployments behind a hardened reverse proxy that provides TLS, authentication, request limits, and security headers. - Avoid returning secrets, credentials, or unrestricted file contents through `getData()`. - Document firewall requirements and make clear that logging a `localhost` URL does not ensure loopback-only binding. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:379
Finding
Predictable shared temporary files permit symlink and PID-file manipulation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 379-415 **Vulnerability Type**: Unsafe temporary-file handling **Risk Level**: Medium ### Vulnerable Code ```bash SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" LOG_DIR="/tmp/openclaw-monitor" PID_FILE="$LOG_DIR/monitor.pid" LOG_FILE="$LOG_DIR/monitor.log" mkdir -p "$LOG_DIR" # Check whether already running if [ -f "$PID_FILE" ]; then PID=$(cat "$PID_FILE") if ps -p $PID > /dev/null 2>&1; then echo "✅ 监控面板已在运行 (PID: $PID)" exit 0 fi fi # Start service with automatic restart echo "🚀 启动监控面板..." cd "$SCRIPT_DIR" ( while true; do node server.js >> "$LOG_FILE" 2>&1 echo "⚠️ 服务意外停止,5 秒后重启..." >> "$LOG_FILE" sleep 5 done ) > /dev/null 2>&1 & echo $! > "$PID_FILE" sleep 3 if ps -p $(cat "$PID_FILE") > /dev/null 2>&1; then echo "✅ 监控面板已启动" echo " 访问地址:http://localhost:18790" echo " 日志文件:$LOG_FILE" echo " 进程 PID: $(cat $PID_FILE)" ``` ### Technical Analysis The startup script stores logs and process state in the fixed, predictable directory `/tmp/openclaw-monitor`. Shared temporary directories are commonly writable by multiple local users. The script does not verify the directory's owner or permissions and does not protect the log and PID files against symbolic links. Shell redirection to `"$LOG_FILE"` and `"$PID_FILE"` follows symbolic links. If the script is run under a more privileged account than an attacker, a pre-created symlink may redirect writes to another file writable by that account. The script also trusts PID-file contents and supplies them to `ps` without validating that the value is a single positive integer. This can permit local denial of service, unreliable process detection, or option-like input being interpreted by the invoked command. ### Attack Path 1. A local attacker predicts that another user or administrator will run the dashboard script. 2. Before startup, the attac ...[truncated 1203 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Store runtime state in a private per-user directory such as `$XDG_RUNTIME_DIR`, not a globally predictable shared `/tmp` path. - If temporary storage is required, create it securely with `mktemp -d` and restrictive permissions. - Verify directory ownership and reject directories or files owned by another user. - Set a restrictive umask before creating runtime files: ```bash umask 077 ``` - Refuse symbolic links and create files atomically. Prefer a service manager or language API capable of no-follow file creation. - Validate PID-file content before use: ```bash PID="$(cat "$PID_FILE")" if [[ ! "$PID" =~ ^[1-9][0-9]*$ ]]; then echo "Invalid PID file" >&2 exit 1 fi ``` - Quote all PID expansions and use an option terminator where supported. - Verify that a PID belongs to the expected dashboard process rather than treating any existing PID as authoritative. - Prefer a supervised service manager with a protected runtime directory and native restart policy instead of a custom PID file. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:522
Finding
Troubleshooting instructions forcibly terminate every process using the configured port<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 522; duplicated in `README.md`, line 145 **Vulnerability Type**: Unsafe process termination command **Risk Level**: Medium ### Vulnerable Code ```bash lsof -ti:18790 | xargs kill -9 ``` ### Technical Analysis The troubleshooting command obtains every process identifier associated with port `18790` and immediately sends each process `SIGKILL`. It does not verify whether the process belongs to the dashboard, whether it belongs to the current user, or whether it is safe to terminate. `SIGKILL` gives a process no opportunity to flush buffers, commit pending data, release application resources cleanly, or perform shutdown handlers. If an unrelated service legitimately uses the port, following the documentation terminates that service as well. The command may have wider impact when executed with elevated privileges because it can kill processes belonging to other users. ### Attack Path 1. A legitimate but unrelated application is already listening on port `18790`. 2. The dashboard fails to start because the port is occupied. 3. The operator follows the documented troubleshooting command, potentially with elevated privileges. 4. `lsof` returns every PID associated with that port. 5. `xargs kill -9` forcibly terminates all returned processes without identity validation or graceful shutdown. 6. The unrelated application experiences abrupt termination and may lose in-memory or partially written data. ### Impact Assessment The command can cause local denial of service against any application using the selected port. Potential effects include: - Immediate termination of an unrelated service. - Loss of unsaved or buffered application data. - Corruption of state that requires graceful shutdown. - Broader cross-user service disruption if the command is run with administrative privileges. This command does not grant new privileges to an attacker. Its security impact is destructive misuse of the o ...[truncated 56 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Do not automatically kill every process associated with a port. - First display process details and require the operator to verify the executable, owner, and command line: ```bash lsof -nP -iTCP:18790 -sTCP:LISTEN ``` - Stop only the validated dashboard PID stored in a securely managed PID file. - Send `SIGTERM` first and wait for graceful shutdown before considering stronger signals: ```bash kill -TERM "$PID" ``` - Use `SIGKILL` only as a documented last resort after confirming process identity and failure to stop gracefully. - Avoid recommending elevated execution unless it is strictly necessary. - Configure the dashboard to accept an alternative port instead of terminating an existing service. ]]>
Vulnerability Patterns
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (5)

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The README instructs users to run `lsof -ti:18790 | xargs kill -9`, which forcefully terminates whatever process is bound to that port without warning, confirmation, or guidance on verifying ownership. In a skill intended for local monitoring/dashboard use, readers may copy-paste the command and unintentionally kill unrelated services, causing local denial of service or data loss if the process was not this dashboard.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
The troubleshooting step `lsof -ti:18790 | xargs kill -9` forcefully terminates any process bound to port 18790 without confirming ownership, graceful shutdown, or warning about side effects. In a shared or repurposed environment, this can kill unrelated services and may cause data loss or corruption because `kill -9` bypasses cleanup handlers.

Natural-Language Policy Violations

Low
Confidence
94% confidence
Finding
The skill documentation is written entirely in Chinese, including usage instructions and safety-relevant operational guidance, with no indication that this is a China-specific or Chinese-only skill. That imposes a language choice on users without opt-in or justification, which matches the language/locale policy concern.

Natural-Language Policy Violations

Low
Confidence
89% confidence
Finding
The document presents all user-facing instructions in Chinese and the sample page sets `lang="zh-CN"`, which imposes a specific language/locale by default. There is no indication that users may choose another language or that the locale is intentionally limited to a region-specific use case.

Vague Triggers

Low
Confidence
89% confidence
Finding
This is a manifest file, so vague-trigger review applies. The description lists general capabilities like "Web dashboard optimization best practices" and "auto-restart service" but does not define when the skill should be invoked, what requests should trigger it, or any exclusions, making invocation scope ambiguous.

Static analysis

No suspicious patterns detected.