@coinbase/cdp-sdk npm package: is it safe?

All exceptions in the try/catch are silently ignored with a bare catch returning undefined. This can hide network or authentication failures and complicate security monitoring, though it is not itself malicious.

The code sends analytics events (action names and account type) to an internal analytics module. This is expected telemetry for a wallet SDK, not data exfiltration to an external attacker-controlled server.

No top-level side effects, eval/new Function, child_process/exec, filesystem manipulation, environment/credential harvesting, network calls outside the SDK's stated purpose, or dynamic require with computed input were found. Requires are static and refer to internal modules (.js relative paths).

Several methods (quoteSwap, swap) hardcode signerAddress: this.owners[0].address and taker: this.address. If an attacker can influence options.owner at account creation time (e.g., via a supply-chain or config injection), the first owner becomes the implicit signing authority for all future swap/sign operations. This is a design risk worth scrutinizing in the surrounding toNetworkScopedEvmSmartAccount / sendSwapOperation modules.

The code calls Analytics.trackAction at various points (send_transaction, transfer, wait_for_transaction_receipt, list_token_balances, request_faucet, quote_swap, swap, use_spend_permission). This is telemetry that sends usage data to an external analytics service. While not inherently malicious, it is data exfiltration of operational metadata and may be a privacy concern depending on the package's policies.

The function calls client.prepareUserOperation and client.sendUserOperation, which may ultimately route to Coinbase CDP API endpoints. The default paymasterUrl for 'base' network is resolved via getBaseNodeRpcUrl. This is expected SDK behavior for a blockchain user operation sender, but the paymasterUrl is supplied by the caller and could point to an attacker-controlled endpoint, though it is not exfiltration by itself.

Owner private key material (owner.sign) is used to sign a userOpHash. This is normal for a wallet SDK but implies access to signing keys. No key exfiltration is observed; only a hash signature is produced.

The fetch call uses mode: 'no-cors', which prevents the caller from reading responses and can be used to bypass CORS restrictions. While commonly used for fire-and-forget analytics, it can also be used for covert data transmission without visibility into the response. Combined with the external endpoint, this is a notable pattern.

wrapClassWithErrorTracking and wrapObjectMethodsWithErrorTracking dynamically replace all prototype/object methods with wrapped functions via Object.getOwnPropertyNames. This is executed when consumers call these functions, and the wrapped functions automatically capture errors (including stack traces and messages) and forward them to the external analytics service. This interception behavior could be abused to exfiltrate error context, though here it appears to be for legitimate error reporting.

Debug mode also logs response error details including headers and data, which may contain authentication tokens or sensitive response payloads in error scenarios.

The constructor reads sensitive credentials from environment variables (CDP_API_KEY_ID, CDP_API_KEY_SECRET, CDP_WALLET_SECRET, CDP_API_KEY_NAME) and passes them to the API client configuration. While this is expected for an SDK, it involves handling sensitive keys.

Every public client method calls Analytics.trackAction(...) before performing the operation, and accounts returned are wrapped with Analytics.wrapObjectMethodsWithErrorTracking(account). This transmits usage telemetry to remote analytics infrastructure, which may include method names, account types, and network identifiers.

All key operations (createAccount, exportAccount, importAccount, signMessage, signTransaction, sendTransaction) delegate to CdpOpenApiClient, which communicates with an external Coinbase endpoint. Since this file handles private keys, users should be aware that key material and/or signing requests flow to a remote service.

Address and name parameters are interpolated directly into URL paths (e.g., /v2/evm/accounts/${address}) without encodeURIComponent. While this is a common pattern in generated API clients, it could allow path traversal or request forgery against unintended endpoints if untrusted input is passed. This is a minor input-handling concern, not malicious.

Generates 4096-bit RSA keys and returns base64-encoded PKCS1 DER private keys. Although not inherently malicious, exporting private keys as strings from a utility module can facilitate credential leakage if logs, telemetry, or error paths capture them.

options.account is converted via toAccount() and embedded into createWalletClient. This is standard for signing flows, but if the account object contains a raw private key, this module would be a convenient sink for credential theft in a compromised dependency. No local exfiltration is present, but the acceptance surface is broad.

Every signing and transaction method calls Analytics.trackAction, sending operational metadata (action type, account type, network, and account address implicitly via the account object) to an analytics endpoint. While not inherently malicious and consistent with legitimate SDK telemetry, it constitutes data collection that may be undesirable depending on the threat model.

All cryptographic signing operations (signMessage, sign, signTransaction, signTypedData) delegate to a remote apiClient rather than local key storage. This is a server-managed account design, not a drainer, but it means sensitive operations depend on a trusted external service and the code does not itself expose private keys.

The module calls Analytics.trackAction() on every account method invocation, reporting action names and network properties. This appears to be first-party product telemetry (Coinbase CDP SDK), not exfiltration of secrets; no credentials, keys, or user data beyond account type and network are collected.

The function resolves viem clients from a user-supplied network or RPC URL and delegates signing/sending to the underlying account. This is expected behavior for a network-scoped account wrapper and does not itself exfiltrate data or execute untrusted code.

The code calls Analytics.trackAction with action names, account type, and network properties before performing operations. This is telemetry, not credential/secret exfiltration, and does not transmit private keys, seed phrases, or sensitive file contents.

The code calls Analytics.trackAction for each operation, sending action names and account type properties to an analytics endpoint. This is a common, non-malicious pattern for usage telemetry but does constitute data exfiltration if the endpoint is external and not disclosed. However, no sensitive data like credentials or keys is included.

The code uses an Analytics.trackAction function to track user actions (request_faucet, sign_message, sign_transaction, send_transaction, transfer) along with account type and network information. While this may be a legitimate analytics feature, it constitutes telemetry data collection that could be considered a privacy concern depending on how the collected data is used.

The module export objects (Analytics, AnalyticsDeprecated) and the wrapping functions modify prototypes and object methods at call sites. No top-level execution occurs beyond symbol/constant definitions, but the wrapping utilities intercept and redirect every class/object method through error-reporting wrappers that call sendEvent, effectively instrumenting arbitrary user classes for telemetry.

The interceptor builds a fully qualified URL from axiosClient.getUri() concatenated with axiosConfig.url and sends authentication headers to the resulting host/path. If the axios client base URL or request URL is attacker-influenced, credentials could be sent to an unintended host. No allow-listing or host validation is present.

The module imports Analytics and openapi-client modules which may perform network/telemetry side effects. The constructor also performs environment and version checks and modifies shared static configuration (CdpOpenApiClient.configure) as a side effect of instantiation.

The code imports and calls an internal Analytics.trackAction() function on every public method invocation (createEndUser, listEndUsers, validateAccessToken). While the analytics module is part of the same package and no data exfiltration to an external server is directly visible here, sending usage telemetry from a client-side SDK is a privacy concern that should be scrutinized (what data is collected and where it is sent).

randomUUID() from Node's crypto module is used to generate user IDs. This is cryptographically appropriate and not a security concern.

validateAccessToken forwards the provided accessToken directly to the backend API client. The token is not logged or persisted in this file, which is good practice, but it does get passed through to CdpOpenApiClient without any local redaction or validation, so any weakness in that layer could expose credentials.

The code sends action names and limited context (e.g., scope) to an internal Analytics module. This appears to be first-party telemetry for the CDP SDK, not exfiltration to an attacker-controlled server. No credentials, environment variables, or sensitive user data are collected.

CreatePolicyBodySchema.parse and UpdatePolicyBodySchema.parse are called to validate input; this is legitimate input validation and not dynamic code execution.

Address and name values are interpolated directly into URL paths (e.g. /v2/evm/accounts/${address}) without URL encoding. A malicious or malformed address/name containing path traversal or special characters could alter the request target, potentially leading to unexpected API endpoints being hit.

The code performs standard RSA key generation and decryption, and Solana key formatting. There is no evidence of data exfiltration, environment variable harvesting, obfuscation, dynamic code execution, mining, backdoors, suspicious network requests, file system manipulation, or process spawning. The cryptographic operations appear to be for legitimate export/decryption purposes.

The function constructs an API key-based JWT (using apiKeyId and apiKeySecret from the config) and sends it via an Authorization header to a dynamically-derived URL from config.basePath. While this appears to be legitimate authentication to the CDP API, it represents credential usage in outbound network requests that could become exfiltration if config is attacker-controlled or basePath is tampered with.

The catch block silently returns undefined, hiding failures including network errors or auth errors. This is not malicious per se but can mask misbehavior and complicate security auditing of the credential flow.

The code tracks user actions (send_transaction, transfer, wait_for_transaction_receipt, etc.) via an Analytics module. This is common in SDKs but could be a privacy concern if it sends data externally without consent. However, it only tracks action names and network/account type, not sensitive data.

The code includes Analytics.trackAction calls that report action types and some account metadata (e.g., accountType, network) to an internal analytics system. This is not classic exfiltration of credentials or secrets but is telemetry that could be a privacy concern depending on policy. No external endpoints are hardcoded in this file.

No obfuscation, eval/exec, environment variable harvesting, filesystem manipulation outside package scope, process spawning, dynamic imports, or wallet draining logic is present. The code simply constructs an account object with wrapper methods that delegate to imported actions.

The function takes transfer arguments (recipient address, amount, token) from the caller and immediately submits transactions without any validation or confirmation. While this may be intentional for a library, it enables misuse where an attacker-controlled caller can initiate token approvals and transfers. The code does not verify that the token address is legitimate, that the recipient matches the intended one, or that the amount is within safe limits.

A hardcoded 'publicClientId' (54f2ee2fb3d2b901a829940d70fbfc13) is embedded and used to authenticate to the external analytics endpoint. This is expected for analytics but represents a fixed, non-user-configurable reporting channel.

MD5 is used to generate an integrity 'checksum' for telemetry payloads. MD5 is cryptographically broken, though here it is not used for security purposes (just payload integrity), so risk is low.

API key secrets and optional wallet secrets are accepted as plain strings and passed through to getAuthHeaders. No validation or zeroization of secrets in memory. This is typical for auth libraries but warrants attention given the wallet secret handling.

The constructor reads sensitive credentials (CDP_API_KEY_ID, CDP_API_KEY_NAME, CDP_API_KEY_SECRET, CDP_WALLET_SECRET) from environment variables. While this is a documented design pattern and expected behavior for SDK configuration, it involves accessing sensitive secrets from the process environment, which could be exploited if the package were compromised. This is standard behavior for the official Coinbase CDP SDK, not inherently malicious.

The client imports an Analytics module and calls Analytics.trackAction for each public method (createEndUser, listEndUsers, validateAccessToken). This collects telemetry about user operations. While this appears to be intentional SDK analytics rather than covert exfiltration, it does transmit usage data alongside operations without an explicit opt-out, and the Analytics implementation is not shown and could contain unexpected behavior.

Uses crypto.randomUUID() to generate user IDs when not supplied. This is standard and safe, but worth noting as it involves identity material generated client-side.

The module uses Node's crypto primitives (publicEncrypt with RSA-OAEP/SHA-256 and a decryptWithPrivateKey helper) to protect private keys during import/export. This is a legitimate cryptographic design, not a backdoor; no key material is exfiltrated to unintended destinations.

All network calls go through the CDP OpenApiClient (Coinbase Developer Platform SDK). Endpoints are hardcoded/derived from the SDK configuration; no user-controllable URLs, eval, or dynamic imports are used to redirect traffic.

Multiple methods call Analytics.trackAction, which may transmit usage data to external servers. While not inherently malicious, this constitutes data collection that could include sensitive metadata (e.g., action types, account types, network names). Users should be aware of this telemetry.

The exportAccount method generates an encryption key pair, sends the public key to the API, receives an encrypted private key, and decrypts it locally. This pattern is standard for secure key export, but it involves handling sensitive private key material in memory. No direct exfiltration is present, but the risk of improper memory handling or accidental logging exists.

This file re-exports symbols from a 'spend-permissions' module and includes Ethereum-related utilities (viem parseEther/parseUnits, spend permission manager ABI/address). While no direct exfiltration, process spawning, or obfuscation is present in this index file, imported modules may execute top-level code on import. The presence of blockchain/wallet-related exports (SpendPermission, spendPermissionManagerAddress/Abi, parseEther) in a package warrants review of the underlying modules for wallet-draining or address-rewriting behavior, as these are common targets for supply-chain attacks. No malicious pattern is present in the shown code itself.

User-supplied address/name values are interpolated directly into request URLs (e.g. /v2/evm/accounts/${address}, /v2/evm/accounts/by-name/${name}, /v2/evm/accounts/export/by-name/${name}) without visible encoding or validation in this module. If cdpApiClient does not URL-encode these segments, an attacker-controlled address/name could alter the request path, potentially causing requests to unintended endpoints on the API host (path traversal / SSRF-style issues within the API surface).

Functions signEvmHash, signEvmMessage, signEvmTypedData, and signEvmTransaction allow arbitrary 32-byte hashes, EIP-191 messages, EIP-712 typed data, and RLP-serialized transactions to be signed. The docs note the API does not validate unsigned transactions. This is expected for a signing SDK, but callers with access to this module can obtain valid signatures over attacker-chosen payloads, which is a significant capability worth surfacing explicitly.

The RSA private key is generated in PKCS1 DER format with 4096-bit modulus, which is acceptable. However, RSA-OAEP-SHA256 decryption is used on a PKCS1-formatted key, which is valid. No cryptographic weakness is directly introduced by this code, but storing/exporting unencrypted private keys in base64 is a sensitive operation that should be handled carefully by callers.