Back to skill

Security audit

Agent Dashboard Sync

Security checks for vulnerabilities and agentic risk

Overview

This skill is a disclosed operations runbook for syncing fleet telemetry, with a token-handling hardening issue users should address before using the cron example.

Before installing, review exactly what the collector sends, use a dedicated low-privilege ingest token, avoid putting the real REPORT_TOKEN directly in crontab, and document how to disable or change the cron job frequency.

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 (1)

T09 · Insecure Skill Coding Practices

Warning
Location
references/collector-cron.md:16
Finding
Ingest Token Exposed in Persistent Cron Command## Vulnerability Details **File Location**: `references/collector-cron.md`, lines 16-21 **Vulnerability Type**: Secret exposure through cron configuration and process environment **Risk Level**: Medium ### Vulnerable Code ```markdown Use `collectors/openclaw-state-collector/scripts/install-cron.sh` and set env vars inside script/system profile. Example entry: ```cron */2 * * * * cd <PROJECTS_ROOT>/agent-fleet-dashboard && REPORT_MODE=cloudflare REPORT_ENDPOINT=https://<worker>.workers.dev REPORT_TOKEN=<INGEST_TOKEN> AGENT_ID=<agent_id> npm run -w collectors/openclaw-state-collector collect >> <LOG_ROOT>/collector.log 2>&1 ``` ``` ### Technical Analysis The documented cron entry places `REPORT_TOKEN` directly in the persistent command. Although the value is represented by a placeholder, following this example requires substituting the production ingest token into the crontab. This conflicts with the project's separate recommendation to keep runtime secrets in secret managers. Depending on host configuration and access boundaries, the resulting secret may be exposed through crontab inspection, process environment inspection, configuration backups, administrative tooling, troubleshooting output, or copied support material. Redirecting command output does not protect the token stored in the cron definition. The scheduled collector itself is disclosed and reasonably necessary for the declared continuous heartbeat synchronization. Therefore, the persistence mechanism is not classified as a malicious T06 backdoor. The confirmed issue is the insecure handling of the credential used by that mechanism. ### Attack Path 1. An attacker obtains local access sufficient to inspect the collector user's crontab, cron configuration backups, process environment, or operational captures. 2. The attacker recovers the production value assigned to `REPORT_TOKEN`. 3. The attacker identifie ...[truncated 968 chars]
Remediation
## Remediation Suggestions 1. Remove the example that embeds `REPORT_TOKEN` directly in the crontab command. 2. Retrieve the token at execution time from an operating-system keychain, service credential facility, or other supported secret manager. 3. If a credential file is unavoidable, place it outside the repository, restrict ownership to the collector account, and set permissions to owner-read only, such as mode `0600`. 4. Use a small launcher script that retrieves the secret without printing it and then invokes the collector. Ensure the launcher and collector never enable shell tracing or log environment variables. 5. Restrict the collector to a dedicated, unprivileged operating-system account with only the filesystem and network permissions required for telemetry collection. 6. Use a dedicated ingest token with write-only, environment-specific scope. Do not reuse dashboard read tokens or Cloudflare administrative credentials. 7. Add token rotation and revocation procedures, and rotate the token immediately if a crontab, process listing, backup, screenshot, or log containing it is exposed. 8. Document safe cron installation and removal procedures and verify that uninstalling the Skill's integration removes the scheduled entry and associated credentials.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • YARA SignaturesMalware Match, Webshell Match, Cryptominer Match
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

YARA rule 'backdoor_persistence': Backdoor persistence with malicious payloads (shell commands, SSH key injection, hidden root users) [malware]

High
Category
YARA Match
Content
---
name: agent-dashboard-sync
description: Sync OpenClaw fleet runtime/heartbeat/cron status to Cloudflare KV and serve dashboard-ready data via Worker API. Use when setting up or operating the Agent Fleet Dashboard data plane (collector, KV schema, Worker ingest/read API, crontab scheduling, and migration away from Git-backed high-frequency state).
---

# Agent Dashboard Sync

Operate dashboard data sync as a no-LLM pipeline.

## Hard Rules

1. Keep high-frequency state out of Git commits.
2. Use Cloudflare Worker + KV for runtime sync.
3. Run collector from local cron (`*/2 * * * *`) and do not call LLM in collector path.
4. Never commit or print production tokens/secrets in files, logs, or screenshots.
5. Do not publish absolute paths in skill docs; use relative paths or placeholders (`<PROJECTS_ROOT>`, `<SHARED_ROOT>`).

## Scope Boundary

- This skill owns:
Confidence
75% confidence
Finding
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).

Missing User Warnings

Medium
Confidence
89% confidence
Finding
This markdown file describes a one-shot upload using REPORT_ENDPOINT and REPORT_TOKEN to send data to a remote worker, but it does not disclose what system or user data the collector transmits or any privacy implications. For markdown files, SQP-2 applies when descriptions omit warnings about behaviors that could affect user data or privacy.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The cron example configures an automated recurring task that posts collector output to a remote endpoint every two minutes, but the documentation does not warn users about the ongoing network transmission and operational impact of continuous collection. For markdown files, repeated background data transfer should be clearly disclosed because it can affect privacy and system integrity expectations.

Static analysis

No suspicious patterns detected.