T08 · Insecure Dependencies
- Location
package.json:27- Finding
Unbounded Production Dependency Allows Unreviewed Supply-Chain Code
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a clearly payment-oriented skill, but it deserves Review because it combines real fund-transfer authority with raw sensitive argument logging, persistent payment credentials, and an unbounded production SDK dependency used during credentialed setup.
Review this carefully before installing in any account that can move real funds. Use only low spending limits, rotate/revoke Oris credentials if logs or the config file may have been exposed, avoid untrusted launch environments that can set ORIS_BASE_URL, and prefer a release that pins oris-sdk, redacts financial logs, validates endpoints, initializes the usage gate correctly, and adds explicit human confirmation for transfers, withdrawals, fiat funding, and marketplace purchases.
package.json:27Unbounded Production Dependency Allows Unreviewed Supply-Chain Code
oris_mcp/server.py:183Sensitive Financial Tool Arguments Are Written to Application Logs
oris_mcp/server.py:85Unvalidated API Base URL Can Redirect Credentials and Financial Requests
oris_mcp/server.py:116Unreachable Initialization Leaves the Usage Gate Undefined and Terminates Tool Handling
Undeclared zero-knowledge proof generation and cryptographic proof handling are not inherently malicious, but they are security-sensitive and materially different from a simple payment skill. When advanced cryptographic functionality is bundled without clear disclosure, operators cannot properly assess native-module risk, compute/resource impact, or whether proofs are being used in ways unrelated to the advertised payment workflow.
Undeclared zero-knowledge proof generation and cryptographic proof handling are not inherently malicious, but they are security-sensitive and materially different from a simple payment skill. When advanced cryptographic functionality is bundled without clear disclosure, operators cannot properly assess native-module risk, compute/resource impact, or whether proofs are being used in ways unrelated to the advertised payment workflow.
Undeclared zero-knowledge proof generation and cryptographic proof handling are not inherently malicious, but they are security-sensitive and materially different from a simple payment skill. When advanced cryptographic functionality is bundled without clear disclosure, operators cannot properly assess native-module risk, compute/resource impact, or whether proofs are being used in ways unrelated to the advertised payment workflow.
The skill declares environment-variable and networked MCP capabilities but does not declare any explicit tool scope or permissions boundary. For a payments skill handling API credentials and transaction-capable operations, missing scope declarations increases the risk of overbroad access and makes it harder for operators to audit or constrain what the skill may do.
The setup flow creates a wallet, sets a default spending policy, and persists the resulting credentials for future reuse, which establishes durable financial capabilities beyond a single session. In the context of a spending/payment skill, persistent wallet and API access is especially sensitive because compromise of the stored configuration could enable unauthorized payments or policy changes over time.
* 2. Validate API key format (oris_sk_live_ prefix, min length)
* 3. Validate API secret format (oris_ss_live_ prefix, min length)
* 4. Register agent via SDK
* 5. Create ERC-4337 wallet on Base
* 6. Set default spending policy
* 7. Write all credentials to OpenClaw config store
*/
The declarations explicitly state that API keys, API secrets, agent IDs, and wallet information are written into a shared OpenClaw config store at ~/.openclaw/config.json, and that the MCP server later reads them as environment variables. Storing payment and wallet credentials in a shared plaintext-style config location without any disclosure, scoping, encryption, or permission-hardening guidance materially increases the risk of credential theft by other local processes, users, or skills.
The setup flow persists the API key and API secret to ~/.openclaw/config.json, creating a local plaintext secret store. Although the file is created with restrictive permissions, storing long-lived payment credentials on disk increases the risk of credential theft from local compromise, backups, sync tools, or other processes reading the file. In a payments skill, those credentials may enable wallet operations and spending actions, so the context makes this more sensitive than ordinary application settings.
The setup flow persists the Oris API key and API secret to ~/.openclaw/config.json, creating a local plaintext credential store. Even though restrictive file modes are requested, local secrets at rest remain exposed to compromise from local malware, backups, accidental disclosure, or other processes/users in misconfigured environments, and this skill manages payment-capable credentials, which raises the risk.
This code accesses ORIS_API_KEY, ORIS_API_SECRET, ORIS_AGENT_ID, and falls back to reading credentials from ~/.openclaw/config.json. Although the module docstring documents configuration, there is no user-facing warning or disclosure at the point of access that the server will automatically consume locally stored secrets, which is a safety-relevant credential access behavior.
Tool-call arguments are forwarded to the executor for payment operations against an external Oris service without any explicit user-facing disclosure or consent check in the request path. In an agent setting, this can cause sensitive financial, identity, or transaction metadata supplied by users or upstream tools to be sent off-box unexpectedly, increasing privacy and data-governance risk.
The tool definition exposes a payment-sending capability but does not require any explicit user confirmation, warning text, or acknowledgement that invoking it can irreversibly transfer funds. In an agentic context, a model may select this tool based on prompt injection, misunderstanding, or ambiguous user intent, causing unauthorized or unintended financial loss even if downstream compliance checks exist.
This on-ramp tool can initiate external payment actions such as bank transfers or card charges, but the interface does not prominently warn that real-world payment rails may be triggered. In an autonomous agent setting, lack of explicit confirmation increases the risk of accidental funding events, chargeable transactions, or abuse through manipulated prompts.
The off-ramp tool enables withdrawal of stablecoins to a bank account, which is a sensitive fund-transfer operation, yet the tool contract lacks an explicit warning or confirmation field. Because withdrawals may be hard to reverse and destination_account is a free-form string, an agent could send funds to the wrong account or be induced to exfiltrate assets.
The manifest describes a spending/payments skill with built-in policy and compliance, but this file also implements local credential discovery by reading ~/.openclaw/config.json when environment variables are absent. Accessing arbitrary local config files is not clearly implied by the stated purpose and expands the skill's capability beyond simply exposing payment tools.
Although the description mentions escrow-backed purchase, the tool still commits funds and creates a financial obligation without an explicit acknowledgement or confirmation requirement in the schema. In a marketplace context, an agent could place unintended orders or lock funds in escrow due to ambiguous prompts or malicious instruction injection.
The runtime dependency oris-sdk is specified as *, which allows installation of any published version, including future releases with breaking changes or maliciously introduced supply-chain compromises. In a payment-related agent skill, this is more dangerous than usual because the dependency likely mediates payment, wallet, or compliance logic, so a compromised update could directly affect fund movement or sensitive financial operations.
"typecheck": "tsc --noEmit"
},
"dependencies": {
"oris-sdk": "*"
},
"devDependencies": {
"@types/node": "^22.0.0",
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"oris-sdk": "*"
},
"devDependencies": {
"@types/node": "^22.0.0",
"tsup": "^8.0.0",
"typescript": "^5.5.0",
"vitest": "^2.0.0"
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"@types/node": "^22.0.0",
"tsup": "^8.0.0",
"typescript": "^5.5.0",
"vitest": "^2.0.0"
},
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"devDependencies": {
"@types/node": "^22.0.0",
"tsup": "^8.0.0",
"typescript": "^5.5.0",
"vitest": "^2.0.0"
},
"keywords": [
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"@types/node": "^22.0.0",
"tsup": "^8.0.0",
"typescript": "^5.5.0",
"vitest": "^2.0.0"
},
"keywords": [
"oris",
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.
pydantic>=2.0,<3 permits a broad range of versions, and the package has had multiple advisories across its lifecycle. Because this is an MCP server for agent payment tooling, input validation is security-relevant; an affected resolved version could enable denial of service or malformed-input handling issues in externally reachable interfaces.
The optional grpcio dependency is only range-constrained (>=1.60,<2) and has a history of multiple security advisories. Although optional, if the gRPC transport is enabled in this payment-related agent service, a vulnerable resolved version could expose network-facing denial-of-service or protocol-handling weaknesses.
No suspicious patterns detected.