T09 · Insecure Skill Coding Practices
- Location
dashboard/server.py:57- Finding
Unauthenticated Dashboard Exposes Private Orchestration Data on All Network Interfaces
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is mostly coherent as a local project-orchestration helper, but its dashboard can expose private orchestration data over the network without authentication.
Install only if you are comfortable with persistent local records of projects, sessions, model/provider details, prices, and possible copied context. Do not store secrets, API keys, database URLs, or confidential prompts in the generated planning or session files. Avoid starting the dashboard on untrusted networks unless it is changed to bind to 127.0.0.1, remove wildcard CORS, and require authentication or a token.
dashboard/server.py:57Unauthenticated Dashboard Exposes Private Orchestration Data on All Network Interfaces
dashboard/index.html:101Stored Cross-Site Scripting Through Unescaped Dashboard Data
| ID | Provider | Speed | Context | Status | Cost | Notes |
|---|---|---|---|---|---|---|
| ${model.id} | ${model.provider} | ${'★'.repeat(typeof model.speed === 'number' ? model.speed : 0)}${'☆'.repeat(Math.max(0, 5 - (typeof model.speed === 'number' ? model.speed : 0)))} | ${model.context >= 1000000 ? (model.context/1000000).toFixed(0)+'M' : model.context >= 1000 ? (model.context/1000).toFixed(0)+'K' : model.context} |
The README explicitly instructs storing environment variables and database URLs in .planning/CONFIG.md, a human-readable document likely to live inside the project tree. This creates a direct path to credential leakage, internal endpoint disclosure, and accidental source-control exposure, especially in existing repositories or shared workspaces.
The code does not perform orchestration tasks such as routing models, managing coding workflows, running scripts, or tracking decisions. Instead, it passively reads files from a data directory and serves them through HTTP endpoints for debugging/dashboard purposes. While session logging and price-check visibility are partially represented by reading existing logs, the primary behavior is a dashboard/data-serving service, which is materially narrower and different from the declared 'complete project orchestration' purpose. Additionally, it exposes this information via a network server, which is a notable capability not reflected in the description.
The declared description promises a broad orchestration capability spanning multiple functions, but this code chunk is a narrow shell script that parses an optional age threshold and prints instructions for manually checking stale subagents inside an OpenClaw session. It does not automate inspection, does not interact with project workflows, and does not implement the listed orchestration features. This is a material description-to-behavior mismatch because the actual primary purpose is operational guidance for subagent/session inspection, which is substantially different from the declared end-to-end orchestration role.
The declared description presents a broad orchestration skill with multiple capabilities across workflow management, routing, logging, tracking, and price checks. The supplied code chunk is much narrower: it parses an optional timeout argument and prints informational instructions about which OpenClaw tools to use manually to inspect long-running or stuck subagents. It does not carry out orchestration or any of the listed core functions, nor does it access resources beyond stdout and argument parsing. This is a material description-behavior mismatch because the actual primary purpose is manual diagnostic guidance for stuck subagents, not complete project orchestration.
The declared description presents a broad orchestration capability set, including model routing, workflow control, logging, decision tracking, and price checks. The actual code only scaffolds planning documentation files (CONFIG.md, STATE.md, ROADMAP.md, REQUIREMENTS.md, ADRs/) and creates a project registry markdown entry. While this is loosely related to project setup/scripts, it does not implement most of the declared capabilities. Therefore the description materially overstates and misrepresents the code's actual behavior.
The declared description claims broad project orchestration capabilities across multiple domains, but this code chunk only implements one specific function: decision tracking via ADR file creation. While decision tracking is included in the description, the overall declared purpose materially overstates what this supplied code actually does. There are no signs of model routing, workflow management, session logging, or price checking in the provided code. Therefore the description does not accurately represent this code chunk's actual behavior.
The declared description presents a broad orchestration skill with multiple responsibilities across routing, workflow management, logging, tracking, and pricing. The supplied code chunk instead implements a single-purpose utility script for testing model endpoint reachability and inventory/listing presence. While model-related checking is loosely adjacent to 'model routing,' this code does not actually orchestrate projects or implement the other listed functions. This is a material description-behavior mismatch in primary purpose and scope.
Skill contains instructions that could directly expose system prompts, internal rules, or hidden instructions to users or external parties.
| `bash {baseDir}/scripts/resume-session.sh <id>` | Resume a previous session (id = filename, partial match, or 'last') |
| `bash {baseDir}/dashboard/serve.sh` | Start orchestration dashboard |
### Guidance Scripts (print instructions for OpenClaw session tools)
| Script | What it does |
|--------|-------------|
| `bash {baseDir}/scripts/show-tree.sh` | Show data dir state + OpenClaw tool guidance |
The documentation states that session, project, model, and pricing data are stored persistently in an external orchestrator-data directory, but it does not present this as a privacy/security boundary or require informed consent. Because the skill is designed to capture cross-session state, users may unknowingly accumulate sensitive operational history on disk in predictable locations.
The README instructs the agent to probe local and remote providers using web and curl commands, but it does not require explicit user consent, explain what metadata may be sent, or define safe handling for API keys and endpoint details. In an orchestration skill, automatic provider discovery can expose local service presence, machine characteristics, and credential-related information to external services or logs.
The onboarding flow instructs the agent to collect and persist user-supplied operational details, model preferences, spend information, and project metadata without defining strict minimization or redaction boundaries. In a long-lived orchestration system, this creates unnecessary retention of potentially sensitive business and usage data that could later be exposed through local compromise, sharing, or accidental check-in.
The skill directs persistent registration of projects and session logging in a central orchestrator directory, enabling cross-session tracking of project activity and user workflows. While useful operationally, this persistence expands the attack surface by creating durable records of project names, paths, tasks, and activity history that may be sensitive in some environments.
Log the project to the orchestrator:
→ Update $ORCHESTRATOR_DATA_DIR/projects/<name>/
→ Add entry to project index if tracking multiple projects
Register the project for session logging:
bash scripts/log-session.sh <project> "Project onboarding" "-" complete
The skill advertises and instructs use of shell commands, network access via curl, and environment-dependent behavior, but it does not declare any explicit tool scope such as permissions or allowed-tools. That increases the chance an agent will run with broader-than-necessary privileges and makes operator review harder, especially because the skill can launch scripts, probe providers, and start a dashboard server.
The skill explicitly instructs storing sessions, projects, prices, and model data in a persistent directory outside the skill, but it does not warn that these logs may contain sensitive prompts, project details, architecture decisions, or provider information. Because the feature is cross-session by design, accidental long-term retention and unintended exposure become more likely.
The dashboard exposes potentially sensitive orchestration data such as session logs, pricing logs, model metadata, and status information over HTTP without any user-facing warning or consent flow. In this skill context, the data is operationally sensitive rather than public, so silent disclosure from a debugging interface is more dangerous because users may not realize project details and local paths are being served.
The dashboard serves orchestration data over unauthenticated HTTP and explicitly enables Access-Control-Allow-Origin: *, allowing any website a local user visits to read sensitive dashboard responses from the service if it is reachable from the browser. Because the server binds to 0.0.0.0, the exposure is not limited to localhost and can leak session history, model inventory, operational status, and filesystem paths to other hosts on the network as well.
This script explicitly persists full session state and optionally the entire contents of an arbitrary context file to disk, which can capture prompts, credentials, internal notes, tokens, or other sensitive project data. In a project orchestration skill, cross-session logging increases the likelihood that secrets or confidential context will be retained longer than intended and exposed through local compromise, backups, or accidental sharing of the generated markdown files.
The script writes files into a computed data directory and automatically executes another shell script if present, all without an explicit confirmation step. In a skill context where users may run helper scripts with broad trust, this increases the chance of unintended local changes or execution of modified companion scripts, especially if the repository or data-path configuration is untrusted.
The onboarding flow includes cron setup for nightly price checks but does not clearly warn users that this creates automated background network activity. Users may unknowingly enable recurring tasks that contact external providers, consume resources, or leak metadata about their environment and usage patterns.
This file implements a network-accessible debugging dashboard that is not reflected in the skill description, increasing the chance operators deploy it without understanding that it opens an HTTP service. Hidden or undocumented services are risky because they expand the attack surface and can expose internal state to users or nearby network attackers without informed consent.
The header says the script is only a helper and that onboarding is LLM-driven, yet the script independently creates data directories, writes discovery state, optionally invokes another discovery script, and initializes session logging. That does not merely 'handle the technical bits' in a minimal sense; it performs meaningful onboarding state changes on its own.
The manifest describes project orchestration tasks like model routing, workflow, logging, decision tracking, and price checks, but this helper also actively probes external network endpoints, localhost services, installed CLIs, and GPU hardware to inventory the host environment. While adjacent to orchestration, this level of host and network reconnaissance is a broader capability than simple onboarding/setup and is not explicitly justified by the manifest text itself.
No suspicious patterns detected.