T03 · Remote Payload Retrieval and Execution
- Location
README.md:14- Finding
Mutable Remote Installer Is Downloaded and Executed Without Verification
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill has a clear directory-submission purpose, but it documents unverified install and self-update paths that can replace local executable code while storing auth tokens on disk.
Review this before installing. Avoid running the curl-to-bash installer or ship self-update unless you trust the upstream repository and can verify the downloaded code or release asset. Treat ~/.config/ship/config.json as sensitive because it contains reusable service tokens; protect it from sharing, backups, logs, and source control, and revoke or remove tokens when no longer needed.
README.md:14Mutable Remote Installer Is Downloaded and Executed Without Verification
SKILL.md:130Self-Update Replaces the Local Executable Without Documented Authenticity Verification
SKILL.md:54Bearer Tokens Are Persisted in Plaintext Without Documented Local File Protections
Mentioning self-update in a CLI skill is not inherently malicious, but in this context it signals a capability for self-modification that can change the installed binary or scripts after initial trust is established. For an agent-facing tool, that expands attack surface because future behavior may differ from the reviewed version, especially if update provenance and verification are not documented.
- Browser-based login with token persistence
- Submit a URL to a supported directory
- Preview site metadata without creating a record
- Check CLI version and self-update
- Keep tokens separated per site
## Install
The explicit ship self-update command advertises a code-modifying operation without any nearby warning or provenance details. In a security-sensitive agent context, encouraging self-update from the terminal is risky because it can cause execution of newly fetched code and undermine assumptions made during prior review.
ship submit https://example.com --site aidirs.org ship fetch https://example.com --json ship version --latest ship self-update
## Typical Results
The skill metadata explicitly advertises self-update capability, which is a self-modifying action that can replace a local executable. In an agent context, exposing update functionality broadens the attack surface because an agent could be induced to alter its own tooling or install a compromised binary.
name: dirs-submit
description:
CLI tool for the `ship` command wrapping aidirs.org and backlinkdirs.com submission APIs. Use when the user
needs to login, submit a URL, preview site metadata, check CLI version, or self-update the CLI from terminal.
Supports browser login, per-site token storage, submit/fetch commands, version checks, and self-update.
version: 0.1.0
metadata:
The description reiterates support for self-update, normalizing local executable replacement as a standard action. In security-sensitive agent workflows, this is dangerous because self-modification can be socially engineered or abused to swap trusted tooling for untrusted code.
description:
CLI tool for the `ship` command wrapping aidirs.org and backlinkdirs.com submission APIs. Use when the user
needs to login, submit a URL, preview site metadata, check CLI version, or self-update the CLI from terminal.
Supports browser login, per-site token storage, submit/fetch commands, version checks, and self-update.
version: 0.1.0
metadata:
openclaw:
The main usage summary tells the agent to use ship for self-update alongside routine operations, making a high-risk action appear equivalent to low-risk actions like version checks. This weakens safety boundaries and can lead to unnecessary or unreviewed executable replacement.
# dirs-submit
Use `ship` to login, submit URLs, preview metadata, check versions, and self-update.
## Structure
The command list directly includes ship self-update, providing actionable instructions for a self-modifying operation. In an agent-executable skill, directly exposing such a command is risky because it enables local code changes from documentation-level invocation alone.
ship version ship version --latest ship version --json ship self-update ship self-update --json
Including a JSON-mode variant of self-update further operationalizes automated update behavior, making it easier to script or chain executable replacement. Automation of self-modification materially increases the chance of unintended or adversarial updates.
ship version --latest ship version --json ship self-update ship self-update --json
说明:
This line explicitly states that self-update downloads a platform-specific release asset and replaces the local executable. That is a direct self-modification pathway and represents a substantial supply-chain risk if release provenance, integrity, or invocation intent are not tightly controlled.
说明:
- `version --latest` 会检查 GitHub latest release
- `self-update` 会下载当前平台对应的 release asset 并替换本地可执行文件
- Windows 当前不做自动覆盖更新,会提示用户手动下载最新版本
## Result Interpretation
The examples section includes self-update as a normal example command, reinforcing unsafe normalization of self-modifying behavior. In context, this makes the skill more dangerous because it presents executable replacement as a routine supported action rather than a privileged exception.
ship submit https://example.com --site aidirs.org ship fetch https://example.com --site backlinkdirs.com --json ship version --latest ship self-update
The README explicitly describes token persistence and later shows tokens stored in a local config file, but it does not warn users that long-lived authentication secrets are being written to disk. In an agent or shared workstation context, silent local token storage increases the risk of credential exposure through weak filesystem permissions, backups, logs, or accidental disclosure of the config file.
The installation instructions use bash <(curl ...), which directly executes remotely downloaded shell code, and the README also promotes self-update without warning that it will fetch and run code that modifies the local system. This is dangerous because users or agents may execute unreviewed code from the network, creating a supply-chain compromise path if the upstream source, transport, or update channel is tampered with.
The manifest description says to use the skill whenever the user 'needs to login, submit a URL, preview site metadata, check CLI version, or self-update the CLI from terminal,' which is a broad natural-language activation condition rather than a narrowly defined trigger. It does not provide explicit trigger phrases, scope boundaries, or negative examples to distinguish when this skill should or should not be invoked.
The skill explains token storage and overwrite behavior, but only after introducing the login flow, and it does not prominently warn before login that browser-based auth stores bearer tokens locally and may replace prior credentials for that site. This can lead to unintended credential persistence or account/context confusion on shared systems.
The skill documents a self-update command that downloads a release asset and replaces the local executable, but it does not include an explicit safety warning or verification guidance. Any workflow that encourages in-place binary replacement without strong authenticity checks increases supply-chain and execution risk.
The example explicitly states that an authentication token is stored in a persistent file under the user's home directory, but it does not warn that this is sensitive credential material or mention file-permission and local compromise risks. In a CLI skill focused on login and submission workflows, this omission can lead users to leave reusable tokens on disk without understanding the security implications.
Several headings and explanatory lines are written in Chinese, and the document does not indicate that language selection is optional or based on user preference. This can violate language/locale policy when the skill effectively forces one locale without opt-in.