ClawHub
Back to skill

Security audit

cifer

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent CIFER SDK guide, but users should review it because it can route plaintext files/messages through an external encryption service without clearly explaining that trust boundary.

Review this carefully before installing or using it with real data. Avoid uploading confidential files, credentials, regulated records, or production wallet material through the blackbox service unless you understand and accept the service operator, retention, logging, and access controls. Prefer pinned dependency versions and protected wallet key storage for production use.

A.I.G

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:17
Finding

Unpinned Security-Critical Third-Party Dependencies

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:17-20, 213
Vulnerability Type: Supply-chain exposure through unpinned npm dependencies
Risk Level: Medium

Vulnerable Code

bash
npm install cifer-sdk ethers dotenv

The document later provides only a minimum version requirement:

text
- **Minimum SDK version**: Use `cifer-sdk@0.3.1` or later. Earlier versions had incorrect function selectors.

Technical Analysis

The installation command does not pin exact versions of cifer-sdk, ethers, or dotenv. It therefore resolves mutable versions based on the npm registry state at installation time. The instruction to use version 0.3.1 or later does not provide an upper bound, integrity verification, or protection against a compromised future release.

These dependencies execute in a security-sensitive process that loads process.env.PRIVATE_KEY, signs authentication messages, reads local files, communicates with remote services, and submits blockchain transactions. A malicious or compromised package version could consequently access those resources with the privileges of the Node.js process.

Attack Path

  1. An attacker compromises the npm account, publication pipeline, or upstream repository of one of the named packages.
  2. The attacker publishes a malicious version that still satisfies the unconstrained installation command.
  3. A user follows the documented npm install cifer-sdk ethers dotenv instruction.
  4. Malicious code executes through an installation lifecycle script or when the dependency is imported.
  5. The package reads process.env.PRIVATE_KEY, local files, or plaintext supplied for encryption.
  6. The package exfiltrates the data or modifies transaction recipients, calldata, RPC endpoints, or signing requests.

Impact Assessment

Malicious dependency code would execute with the same operating-system privileges as the integrating application. It could access envi ...[truncated 347 chars]

Remediation
View remediation

Remediation Suggestions

  • Pin every dependency to an exact, reviewed version rather than using unconstrained package names or open-ended minimum versions.
  • Commit a lockfile and direct users to install with npm ci so dependency resolution is reproducible.
  • Verify package provenance, maintainers, release signatures, and links to the authoritative source repository.
  • Use npm integrity hashes and enable registry provenance verification where available.
  • Audit transitive dependencies and installation lifecycle scripts before deployment.
  • Run the integration in a restricted environment with only the minimum filesystem and network access required.
  • Isolate wallet signing from dependency code through a dedicated signer service or hardware wallet.
  • Document an explicit upgrade and security-review process instead of automatically accepting future releases.

other

Warning
Location
SKILL.md:29
Finding

Sensitive Plaintext and Files Are Submitted to an External Encryption Service

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:29-33, 101-109, 130-139
Vulnerability Type: External sensitive-data disclosure risk
Risk Level: Medium

Vulnerable Code

The SDK is configured to use an externally operated endpoint:

javascript
const sdk = await createCiferSdk({
  blackboxUrl: 'https://cifer-blackbox.ternoa.dev:3010',
});

Plaintext messages are passed to that endpoint for encryption:

javascript
const encrypted = await blackbox.payload.encryptPayload({
  chainId,
  secretId,
  plaintext: 'Your secret message',
  signer,
  readClient: sdk.readClient,
  blackboxUrl: sdk.blackboxUrl,
});
// Returns: { cifer, encryptedMessage }

Complete file contents are similarly supplied to the remote encryption workflow:

javascript
const buffer = await readFile('myfile.pdf');
const blob = new Blob([buffer], { type: 'application/pdf' });

// Start encrypt job
const job = await blackbox.files.encryptFile({
  chainId, secretId, file: blob, signer,
  readClient: sdk.readClient, blackboxUrl: sdk.blackboxUrl,
});

Technical Analysis

The documented workflow is not purely local encryption. Unencrypted messages and complete files are supplied to an SDK operation configured with the external Blackbox URL. The guide does not prominently explain the remote plaintext-processing trust boundary, obtain explicit consent, or document service-side retention, logging, deletion, jurisdiction, or confidentiality guarantees.

TLS protects data in transit but does not prevent the destination service from accessing plaintext while processing it. A service operator, compromised server, malicious insider, or vulnerable logging and monitoring system could obtain the content before encryption. This conflicts with a likely user expectation that an encryption SDK protects plaintext from infrastructure operators.

Attack Path

  1. A user follows the guide and configures th ...[truncated 1069 chars]
Remediation
View remediation

Remediation Suggestions

  • Clearly disclose before integration that plaintext messages and files are processed by an external service.
  • Require explicit user or administrator consent before sensitive content is uploaded.
  • Document the service operator, data-flow architecture, retention period, logging behavior, deletion guarantees, backup handling, jurisdiction, and subprocessors.
  • Prefer audited client-side encryption so plaintext never leaves the user-controlled environment.
  • If remote processing is unavoidable, offer a self-hosted Blackbox deployment and support endpoint allowlisting.
  • Apply data minimization and prohibit submission of credentials, private keys, regulated records, or other highly sensitive material unless the deployment has been explicitly approved.
  • Establish contractual and technical controls for encryption-service access, retention, monitoring, incident response, and secure deletion.
  • Ensure application logs, progress callbacks, errors, and telemetry never record plaintext or decrypted content.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

Vague Triggers

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The trigger description is broad enough to activate on generic encryption, secret creation, or encrypted file requests that may not specifically require the CIFER SDK. This can cause the agent to select this skill in the wrong context, leading to irrelevant blockchain-specific guidance, unnecessary exposure to wallet/private-key handling patterns, or execution of actions with unintended external dependencies.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The file encryption and decryption examples show users passing File or Blob contents to blackbox.files.* APIs and later downloading results, but they do not clearly warn that plaintext file contents are uploaded to a remote blackbox service for processing. In a security-sensitive encryption SDK, this omission can mislead developers into assuming processing is local, causing accidental disclosure of sensitive documents to a third-party service and creating privacy, compliance, and trust-boundary risks.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low
Category
Not specified by scanner
Confidence
85% confidence
Finding

The server-side signer examples read process.env.PRIVATE_KEY without any caution about secret management, which can normalize unsafe handling of wallet credentials in production deployments. While using environment variables is common, omitting warnings in cryptographic and blockchain documentation increases the chance that developers will store long-lived hot-wallet keys insecurely, log them accidentally, or reuse them without access controls.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.