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## 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: ## 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## 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: ## 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

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.

Missing User Warnings

Medium

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.

Missing User Warnings

Low

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.

Static analysis

No suspicious patterns detected.