OCFT - OpenClaw File Transfer

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:49 AM UTC
• Version: 1.1.2

Overview

The skill is a coherent file-transfer helper, but its documented trust model exposes reusable secrets and can auto-accept files without human review.

Review before installing. Treat OCFT secrets like passwords, avoid sharing them in public or logged chat channels, keep auto-accept narrowly scoped or disabled unless you fully trust the peer, use a sandboxed download directory, avoid IPFS for sensitive files unless you control the provider, and prefer a pinned or locally reviewed package version instead of an unpinned global npm install.

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

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:21
• Finding: Unpinned Global Installation of an Unreviewed Third-Party Package<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:21-23`; `README.md:15-17` **Vulnerability Type**: Unpinned third-party executable and supply-chain exposure **Risk Level**: Medium ### Vulnerable Code `SKILL.md:21-23`: ```bash npm install -g ocft ``` `README.md:15-17`: ```bash npm install -g ocft ``` ### Technical Analysis The project directs users to install the latest available version of the external `ocft` npm package globally. The command does not pin an exact version or enforce a reviewed integrity value. Consequently, the code installed when the command is run can differ from the code that existed when this skill was audited. The audited project contains only documentation and registry metadata. It does not include the npm package's source code, a dependency manifest, a lockfile, or integrity hashes. The behavior of the installed executable and any npm lifecycle scripts therefore cannot be verified from this artifact. Global npm installation increases the affected scope because the package executable becomes available across the user's environment. Package lifecycle scripts can also execute during installation with the privileges of the user running npm. ### Attack Path 1. An attacker compromises the npm package, its publisher account, or a future package release. 2. The attacker publishes a modified `ocft` version containing a malicious lifecycle script or executable. 3. A user follows the documented `npm install -g ocft` instruction. 4. npm retrieves the current mutable package release rather than a previously reviewed version. 5. Malicious lifecycle code may execute during installation, or malicious behavior may execute when the user invokes `ocft`. 6. The payload operates with the privileges of the user who performed the installation. ### Impact Assessment Successful exploitation could provide arbitrary code execution under the installing user's account. Depending on that account's access, the package could read or modify ...[truncated 284 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the package to an exact, reviewed version, such as `ocft@1.0.0`, rather than installing the latest release. - Publish and verify package integrity hashes or signed provenance before installation. - Include the reviewed implementation, dependency manifest, and lockfile in the auditable project. - Prefer a project-local installation over a global installation to reduce system-wide exposure. - Run installation in a sandbox or constrained environment with minimal filesystem and credential access. - Disable npm lifecycle scripts with `--ignore-scripts` when they are not strictly required. - Establish an update-review process before changing the pinned package version. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: README.md:53
• Finding: Reusable Authentication Secrets Are Transmitted Through Message Channels<![CDATA[ ## Vulnerability Details **File Location**: `README.md:53-55`, `README.md:90-97`, `README.md:132-137`; `SKILL.md:98-100` **Vulnerability Type**: Plaintext credential exposure and replayable shared-secret authentication **Risk Level**: High ### Vulnerable Code `README.md:53-55`: ```text │── OFFER ─────────────────>│ (file metadata + secret + TTL) │<───────────── ACCEPT ─────│ (auto-accept if secret valid & not expired) ``` `README.md:90-97`: ```text When the sender knows the receiver's secret, files are automatically accepted without manual approval: 1. Bot A shares their secret with Bot B 2. Bot B adds Bot A as trusted peer with the secret 3. When Bot B sends a file to Bot A, it includes A's secret 4. Bot A verifies the secret (and TTL) and auto-accepts This enables trusted agent networks to share files seamlessly. ``` `README.md:132-137`: ```text OCFT messages use a `🔗OCFT:` prefix with Base64-encoded JSON: 🔗OCFT:eyJ2ZXJzaW9uIjoiMS4wIiwidHlwZSI6Im9mZmVyIi4uLn0= This allows file transfers over any text-based channel (Telegram, Discord, Slack, etc). ``` `SKILL.md:98-100`: ```text OCFT messages use a `🔗OCFT:` prefix with Base64-encoded JSON, allowing file transfers over any text-based channel. ``` ### Technical Analysis The documented protocol includes the receiver's reusable secret in an `OFFER` message. The message is represented as Base64-encoded JSON and transported through third-party text channels such as Telegram, Discord, or Slack. Base64 is an encoding mechanism, not encryption. Any party that can observe the message can decode the JSON and recover included values. Potential observers include channel participants, platform operators, logging integrations, moderation bots, message-export systems, compromised accounts, and applications with channel-history access. The secret is used to trigger automatic acceptance. A time-to-live limits the duration of trust but does not protect the secret while it remains valid. The docume ...[truncated 1508 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Never include reusable authentication secrets in transfer messages. - Replace shared-secret disclosure with challenge-response authentication. - Use a unique, cryptographically random nonce for every offer and reject reused or expired nonces. - Authenticate the sender and transfer metadata with a digital signature or an HMAC calculated over the complete canonical message. - Bind authentication to the sender identity, receiver identity, filename, file hash, size, timestamp, and transfer identifier. - Use end-to-end encrypted transport rather than relying on Base64 encoding or provider-level transport security. - Require explicit approval for unexpected transfers, even from previously trusted peers, unless a narrowly scoped policy authorizes them. - Rotate any secret that has already been transmitted using this protocol. - Maintain replay protection and rate limits for offers and authentication failures. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: README.md:143
• Finding: Authentication Secrets Are Documented as Plaintext Configuration Values<![CDATA[ ## Vulnerability Details **File Location**: `README.md:143-153` **Vulnerability Type**: Plaintext storage of authentication credentials **Risk Level**: Medium ### Vulnerable Code `README.md:143-153`: ```json { "nodeId": "ocft_abc123_xyz789", "secret": "your-secret-key", "secretTTL": 24, "trustedPeers": [ { "id": "peer-id", "secret": "peer-secret", "expiresAt": "2026-02-03T00:00:00Z" } ], "downloadDir": "~/Downloads/ocft" } ``` The documentation states that this configuration is stored at: ```text ~/.ocft/config.json ``` ### Technical Analysis The documented configuration format stores both the node's own secret and trusted-peer secrets directly in a JSON file. The documentation does not specify encryption at rest, operating-system credential-store integration, owner-only permission enforcement, or redaction from backups and diagnostic archives. Any process or user capable of reading the configuration file can recover the complete authentication material without needing to break encryption. Storing multiple peer credentials in one file also creates a single point of compromise. ### Attack Path 1. An attacker obtains read access to the user's home directory through local malware, a compromised process, permissive filesystem permissions, a backup, or a diagnostic archive. 2. The attacker reads `~/.ocft/config.json`. 3. The attacker extracts the local node secret and stored trusted-peer secrets. 4. The attacker uses the recovered credentials to impersonate a trusted participant or submit offers that satisfy secret-based acceptance checks. 5. The credentials remain useful until they expire or are manually rotated. ### Impact Assessment Credential disclosure can compromise the local node identity and every trusted-peer relationship represented in the configuration file. Within the documented protocol, recovered secrets may allow peer impersonation and unauthorized automatically accepted file transfers. The attainable operating- ...[truncated 231 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Store authentication credentials in the operating system keychain or a dedicated secret manager. - Prefer public-key identities so that only public verification keys need to be retained for peers. - If file-based storage is unavoidable, encrypt secrets at rest with a key that is not stored in the same file. - Create the configuration directory and file with owner-only permissions and verify those permissions on every startup. - Prevent secrets from appearing in logs, status output, crash reports, backups, and support bundles. - Separate credentials by peer and scope each credential to the minimum necessary actions and lifetime. - Implement credential revocation and rotation, including automatic rotation after suspected disclosure. - Document a secure migration procedure for existing plaintext configurations. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: The README documents commands to display and verify secrets, and the configuration example shows secrets stored in plaintext, but it provides only minimal caution. In a messaging-based P2P trust model, disclosure of these secrets can let an attacker impersonate trusted peers or trigger automatic acceptance paths.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The README explicitly promotes secret-based auto-accept, meaning files can be received and saved without human review once a peer is trusted. In an agent-to-agent file transfer context, that increases the chance of malicious, unexpected, or unsafe content being written to disk automatically, especially if a trusted peer is compromised or trust is configured too broadly.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The documentation includes commands such as showing the full secret and exporting/importing connection data without a strong warning that these values function as trust credentials and can be exposed through terminals, logs, screenshots, chat history, or shell history. Because this skill is designed for agent-to-agent sharing over message channels, normal usage increases the chance that secrets are copied into insecure places and then reused by unauthorized peers.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill advertises IPFS fallback as a convenience feature but does not clearly warn that using third-party IPFS providers or public gateways can place file content and metadata onto external infrastructure outside the local chat channel. In a file-transfer skill, users may reasonably assume transport remains peer-to-peer/private, so omission of this warning increases the risk of unintended disclosure of sensitive files.

Static analysis

No suspicious patterns detected.