Vaultline

• Outcome: Review
• Latest audit: Sep 16, 2026 · 8:44 AM UTC
• Version: 0.1.2

Overview

The skill is coherent for Vaultline file storage, but it gives agents payment, public upload, private-auth, and delete workflows without enough guardrails for user confirmation and confidentiality defaults.

Install only if you intend to use Vaultline. Before uploads, explicitly choose open or private; use private for sensitive data. Confirm the exact target before deletes, confirm amount and operation before signing x402 payment retries, and treat wallet headers/signatures as sensitive. Review or pin the npm SDK dependency if reproducibility matters.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:8
• Finding: Unpinned npm Dependency Creates a Supply-Chain Risk## Vulnerability Details **File Location**: `SKILL.md:8-15` **Vulnerability Type**: Unpinned third-party package installation **Risk Level**: Medium **Vulnerable code snippet:** ```yaml metadata: openclaw: homepage: https://github.com/BuiltByEcho/vaultline requires: bins: - node - npm install: - id: vaultline-sdk kind: node package: "@builtbyecho/vaultline-sdk" bins: [] label: Install Vaultline SDK from npm ``` ### Technical Analysis The installation configuration identifies `@builtbyecho/vaultline-sdk` without an exact version or package integrity hash. Consequently, the package version installed may vary over time according to registry state and package-manager resolution behavior. This creates a supply-chain trust boundary that is not fixed to the version reviewed with the Skill. If the npm account, package, organization namespace, publishing credentials, or registry resolution process is compromised, a modified release could be delivered during a later installation. Depending on npm configuration, package lifecycle scripts may execute during installation. The audit found no evidence that the named package is currently malicious. The vulnerability is the absence of controls that ensure installations reproduce a specifically reviewed artifact. ### Attack Path 1. An attacker compromises the package publisher, publishing credentials, organization namespace, or relevant package-distribution channel. 2. The attacker publishes a modified version of `@builtbyecho/vaultline-sdk`. 3. A user or agent installs the Skill dependency using the unversioned package declaration. 4. npm resolves the dependency to the attacker-controlled release rather than a previously reviewed version. 5. Malicious package code or an installation lifecycle script executes with the privileges of the account running npm. 6. The package may access files, e ...[truncated 558 chars]
• Remediation: ## Remediation Suggestions - Pin the SDK to an exact, reviewed version rather than relying on a floating package reference. - Use a lockfile with package integrity metadata and verify it during installation. - Configure npm to use an explicitly trusted registry and reject unexpected registry substitutions. - Review the pinned package's source, transitive dependencies, and lifecycle scripts before release. - Disable lifecycle scripts during installation when they are not required, such as through an appropriate `ignore-scripts` policy. - Automate dependency vulnerability and provenance checks while requiring manual review before updating the pinned version. - Run installation and subsequent SDK operations in a least-privileged, isolated environment without unnecessary wallet secrets or host filesystem access.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:37
• Finding: Implicit Open Storage Tier Can Cause Accidental Public Data Exposure## Vulnerability Details **File Location**: `SKILL.md:37-42` **Vulnerability Type**: Unsafe confidentiality default **Risk Level**: Medium **Vulnerable code snippet:** ```markdown ## Core rules - Default to `open` if no tier is specified. - Require `x-storage-tier: private` for private uploads. - Require wallet-auth headers for private upload, read, head, delete, and any list call that should reveal private objects. - Treat open files as readable by anyone who knows the path and satisfies any payment requirement. - Keep the original request intact when retrying after `402` payment negotiation. - Preserve `content-type` and `content-length` on uploads. ``` ### Technical Analysis The Skill explicitly defaults an upload to the `open` tier when the caller does not specify a storage tier. The same rules state that open files are readable by anyone who knows the path and satisfies any applicable payment requirement. This is a fail-open confidentiality policy. An omitted, misspelled, dropped, or incorrectly propagated tier selection silently produces an object with weaker access controls. Knowledge of an object path is not equivalent to authentication or authorization, and a payment requirement does not establish that the requester is permitted to access the data. The risk is especially significant because the Skill is intended to handle both shared and sensitive files. A caller may reasonably expect an omitted optional parameter to retain privacy, reject the operation, or prompt for a choice rather than make the object public by key. ### Attack Path 1. A user or upstream agent requests an upload but omits the storage tier, or an integration fails to propagate the intended `private` value. 2. Following the documented rule, the Skill uploads the object using the `open` tier. 3. The object receives no wallet-based private access restriction. 4. An unauthorized party obtains or guesses the path through logs, shared prom ...[truncated 697 chars]
• Remediation: ## Remediation Suggestions - Require callers to select `open` or `private` explicitly and reject uploads when the tier is absent or invalid. - If an automatic default is operationally necessary, use `private` as the fail-safe default. - Require explicit user confirmation before uploading an object as open, with a warning that anyone possessing the path may retrieve it. - Validate the final outgoing `x-storage-tier` header immediately before dispatching the upload. - Do not treat object names, paths, or payment as authorization mechanisms. - Use high-entropy, non-sensitive object keys as defense in depth, while retaining proper access control. - Add tests covering omitted, misspelled, empty, and stripped tier values to verify that they cannot result in unintended open storage. - Prevent sensitive values from appearing in object paths, logs, prompts, telemetry, and error messages.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (6)

Credential Access

High

• Category: Privilege Escalation

Content

Example:

```http
PUT /v1/files/workspace/secret.txt
content-type: text/plain
content-length: 20
x-storage-tier: private

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High

• Category: Privilege Escalation

Content

Example:

```http
PUT /v1/files/workspace/secret.txt
content-type: text/plain
content-length: 20
x-storage-tier: private

• Confidence: 70% confidence
• Finding: Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Vague Triggers

Medium

• Confidence: 87% confidence
• Finding: The skill description is broad enough to activate on many generic file-storage requests, which can cause an agent to select this skill in contexts where Vaultline-specific behavior, payment flows, or private-wallet auth are inappropriate. Over-broad activation increases the chance of unintended external data transfer or use of destructive/storage-modifying actions when a simpler or safer local/file-handling path was intended.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill explicitly includes delete capability but provides no requirement for confirmation, dry-run behavior, scope validation, or user warning before destructive actions. In an agent setting, this raises the risk of accidental or prompt-induced deletion of remote files, especially because the same skill also covers broad storage tasks and could be invoked in ambiguous contexts.

Missing User Warnings

Medium

• Confidence: 85% confidence
• Finding: This markdown file shows required authentication headers for private operations, including wallet identity and signature data, but does not include any user-facing warning about the sensitivity of those values or the security implications of exposing or logging them. Because SQP-2 applies to markdown files when descriptions omit warnings about behaviors affecting privacy or system integrity, this is a valid documentation gap.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The pay-and-retry pattern instructs users to create/sign a payment payload and retry the request, but it does not warn that this step can trigger billable operations. For markdown skills, SQP-2 requires warnings when behavior can affect user data, privacy, or system integrity; unexpected payment impact is a material user warning omission.

Static analysis

No suspicious patterns detected.