viem npm package: is it safe?

The ccipRequest function performs HTTP requests to arbitrary URLs provided by on-chain contract data via the OffchainLookup mechanism. While this is the intended EIP-3668 CCIP-read behavior, the URLs are fully attacker-controllable if a malicious contract is interacted with, allowing potential SSRF or data exfiltration to attacker-controlled endpoints. The fetched URLs are constructed by replacing '{sender}' and '{data}' placeholders in the URL string, and the response is parsed and returned as call data.

The code dynamically builds URLs by replacing placeholders with sender address and calldata, then fetches them. There is no allowlist or validation of the destination host, so a malicious contract could direct requests to internal network resources or arbitrary external services.

The fromRlp function creates a cursor with recursiveReadLimit set to Number.POSITIVE_INFINITY, disabling the library's built-in protection against deeply nested RLP structures. Combined with recursive list parsing in readList/fromRlpCursor, a maliciously crafted deeply-nested RLP payload could cause stack exhaustion (RangeError: Maximum call stack size exceeded) or excessive memory consumption, resulting in a denial-of-service condition for callers that process untrusted RLP data.

The functions isImageUri, getMetadataAvatarUri, and parseAvatarUri perform fetch() requests to URLs derived from the input 'uri' parameter without validating or restricting the target host. An attacker controlling the URI could cause the library to request arbitrary internal or external services, potentially leading to SSRF or information disclosure.

In resolveAvatarUri, when parsedUri starts with '<svg', it is base64-encoded and prefixed with 'data:image/svg+xml;base64,'. This URI is later returned and potentially rendered by consumers. SVG can contain scripts; if the consumer renders this data URI as an image in an insecure context, it may lead to XSS. The code does not sanitize SVG content.

extractMessages tracks only brace nesting and ignores string literals and escapes. JSON strings containing unmatched braces (e.g. '{"a":"}"}') will corrupt the nesting level, causing incorrect message splitting, dropped messages, or merged payloads. Depending on the caller, this can be used to smuggle or truncate messages across the IPC boundary.

getIpcRpcClient(path) forwards the caller-supplied path directly to node:net connect() as an IPC endpoint with no normalization, allowlisting, or scope restriction. If path is influenced by untrusted input, it could connect to arbitrary local sockets (e.g. privileged daemons) rather than an intended package-scoped endpoint.

The onData handler parses every complete JSON message received over the IPC socket with JSON.parse(). There is no validation, size limit, or schema check before parsing. A malicious or compromised peer can send arbitrarily large or deeply nested JSON, causing high CPU/memory usage (JSON bombs / DoS). The parsed object is then passed directly to onResponse().

The function receives private keys as parameters and uses them to sign hashes. While this is expected behavior for a multisig smart account utility, handling private keys in memory and passing them to a signing function introduces risk if the keys are logged, stored, or transmitted improperly. The code does not appear to exfiltrate keys, but the pattern warrants caution since private keys are highly sensitive credentials.

The factoryAddress is configurable by the caller (parameters.factoryAddress) and defaults to a hardcoded address. If a malicious factory is provided, it could deploy a backdoored smart account or perform arbitrary calls during account creation. This is a design risk inherent in account abstraction but should be clearly documented.

A default factory address '0x5d82735936c6Cd5DE57cC3c1A799f6B2E6F933Df' is hardcoded instead of being derived from the provided entryPoint. This could lead to unexpected account creation address if the factory is not intended for the given chain/entryPoint, potentially causing loss of funds or incorrect account deployment.

The owner account is parsed via parseAccount(parameters.owner) without verifying that it is a valid EOA or that the address matches the expected owner. If an attacker can influence the owner parameter, they could set themselves as owner and drain funds.

The createCursor call sets recursiveReadLimit to Number.POSITIVE_INFINITY, disabling the library's built-in recursion limit. A deeply nested or maliciously crafted RLP input can cause unbounded recursion in readList/fromRlpCursor, leading to a stack overflow and process crash (DoS).

The functions isImageUri, getMetadataAvatarUri, and parseAvatarUri perform fetch() requests to URIs derived from user/on-chain input (ENS avatar records). While intended for avatar resolution, these requests can reach arbitrary external endpoints, enabling SSRF-style behavior or privacy leakage (IP/user-agent disclosure) when untrusted ENS records are resolved.

The ccipRequest function performs fetch() requests to URLs supplied by on-chain contract data (the 'urls' array from the OffchainLookup error). While this is the intended EIP-3668 (CCIP Read) behavior, it allows arbitrary external HTTP requests with attacker-controllable URLs, which could be leveraged for SSRF-like scenarios depending on the caller's environment.

URLs are used directly in fetch() without checking scheme (http/https) or host allowlisting, and template substitution replaces '{sender}' and '{data}' without encoding. A malicious contract could redirect requests to internal endpoints or exfiltrate calldata to unintended hosts.

isImageUri and getMetadataAvatarUri call fetch() with URIs derived from ENS avatar metadata (which can be attacker-controlled via ENS records). This enables SSRF-style requests to internal or arbitrary hosts, and the HEAD/GET responses are used to infer content. In browser contexts this is somewhat constrained by CORS, but in Node/backend contexts (e.g., server-side usage) it can reach internal services.

resolveAvatarUri base64-encodes raw input when it starts with '<svg', producing a data:image/svg+xml URI. This is a known XSS vector if the resulting URI is later rendered as HTML rather than as an image (SVG can contain scripts). The library returns the URI to the caller, so impact depends on consumer handling.

fetchFn can be provided via options or params, silently replacing the global fetch function. A malicious dependency could supply a fetchFn that exfiltrates all RPC request bodies (including signed transactions or auth tokens) to a third party.

User-supplied headers from fetchOptions are merged after default Content-Type, and there is no validation restricting headers. Combined with the URL override, this could allow authentication headers intended for one host to be sent to an attacker-controlled host.

The onRequest callback receives the Request and init object and can return an arbitrary url that overrides the original URL (args.url ?? url). If this callback is attacker-influenced, it enables Server-Side Request Forgery by redirecting requests to arbitrary internal or external endpoints.

The uid() function uses Math.random() to generate identifiers. Math.random() is not cryptographically secure and is predictable, which is unsuitable for security-sensitive uses such as tokens, session IDs, CSRF nonces, or password reset links. If this utility is used for such purposes, it could allow attackers to predict or brute-force generated values. This is a code-quality/security weakness rather than an active malicious pattern.