T09 · Insecure Skill Coding Practices
- Location
scripts/setup_agent.sh:84- Finding
Predictable Matrix Account Passwords
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill appears purpose-built for OpenClaw agent setup, but it handles Matrix credentials in ways that could expose or weaken them.
Review before installing. Use only against a trusted local Matrix server unless HTTPS is enforced, rotate any accounts created with the predictable password pattern, avoid logging access-token output, and restrict permissions on ~/.openclaw/openclaw.json because it stores bearer tokens.
scripts/setup_agent.sh:84Predictable Matrix Account Passwords
scripts/matrix_register.sh:4Matrix Credentials and Access Tokens May Be Transmitted over Plaintext HTTP
scripts/setup_agent.sh:110Matrix Access Token Exposed through Process Command-Line Arguments
scripts/config_manager.py:31Secret-Bearing Configuration File Is Written without Enforced Restrictive Permissions
This mismatch is more serious because the skill behavior includes generating/displaying credentials, persisting Matrix access tokens, and initializing/copying workspace files without clearly foregrounding those sensitive actions in the top-level declaration. Hidden credential handling and filesystem side effects materially increase risk of secret exposure and unintended local changes.
This mismatch is more serious because the skill behavior includes generating/displaying credentials, persisting Matrix access tokens, and initializing/copying workspace files without clearly foregrounding those sensitive actions in the top-level declaration. Hidden credential handling and filesystem side effects materially increase risk of secret exposure and unintended local changes.
The skill context explicitly involves obtaining and handling Matrix access tokens, which are high-value credentials. In this context, credential access is expected functionally, but it remains security-sensitive because exposed tokens can allow account takeover or unauthorized messaging/API actions if leaked via logs, console output, or insecure storage.
用于在 Matrix 服务器上注册新账号并获取 Access Token。
用法:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
fi
}
# 2. 获取 Access Token
get_token() {
local user="$1"
local pass="$2"
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
fi
}
# 2. 获取 Access Token
get_token() {
local user="$1"
local pass="$2"
The script prints the Matrix access token directly to stdout, which can leak credentials into terminal scrollback, shell history wrappers, CI logs, orchestration logs, or any parent process capturing output. In an agent-management context, this is especially dangerous because the token enables authenticated access to the Matrix account and may be consumed by automation in ways that broaden exposure.
The skill documents shell execution plus local file read/write behavior, but it does not declare any explicit tool scope or permission boundary. In an agent ecosystem, this weakens reviewability and allows a caller to invoke a skill with broader operational capability than users may reasonably expect, increasing the chance of unsafe configuration changes or command execution.
The documentation explains account registration and config updates but fails to warn that Matrix access tokens will be stored in the local configuration file. Storing bearer tokens on disk without clear notice can lead to accidental exposure through backups, source control, overbroad file permissions, or local compromise.
The script accepts Matrix access tokens on the command line and persists them in a JSON config file, which creates credential exposure risks. Command-line arguments may be visible via shell history, process listings, logs, or terminal recording, and the saved file is written without enforcing restrictive permissions, increasing the chance of token theft and account compromise.
Comments and runtime messages such as the usage string and status output are written only in Chinese, with no indication that the skill is region-specific or that users can choose another language. This can violate language/locale policy when a skill forces a single language without opt-in or justification.
The script transmits username and password to a homeserver URL that defaults to plain HTTP (http://localhost:8008), meaning credentials may be exposed if the service is not strictly local or if traffic is redirected, proxied, or container-network accessible. Because this skill manages agent lifecycle and account provisioning, credential transmission is expected, but the insecure default transport makes the operation materially riskier.
echo "--- 正在尝试注册: $user ---"
# 直接使用你提供的 v3 接口和 payload
local resp=$(curl -s -X POST "${HOMESERVER_URL}/_matrix/client/v3/register" \
-H "Content-Type: application/json" \
-d "{
\"username\": \"$user\",
This shell script performs a filesystem write by recursively copying a template workspace into a user-specific directory. Although the script describes its high-level setup flow, there is no user-facing disclosure immediately before this write operation and no confirmation prompt for an action that can overwrite or modify local files.
Natural-language policy requires avoiding forced language or locale constraints unless the user opts in or the restriction is documented as necessary. This skill presents all operational instructions in Chinese only, which can exclude users who have not selected that language.
User-facing strings, help text, and module description are all in Chinese, which effectively forces a specific language for interaction. The file does not offer an opt-in language choice or explain that the tool is intentionally limited to a Chinese-speaking audience.
The usage text says bindings remove <agentId> <accountId> and error messages for bindings mention account userId, while account removal help says accounts remove <name>. In code, remove_binding matches against match.accountId and remove_matrix_account searches by info.name, so the documentation and prompts mix up userId, accountId, and name in a way that can mislead operators about what identifier the command actually uses.
Natural-language strings in comments and help/output messages consistently force a specific language locale. Under the stated policy, this is a language/locale constraint without an explicit user opt-in or documented justification.
No suspicious patterns detected.