porto npm package: is it safe?

The module executes await Messenger.cliRelay() at the top level (line 3), which means code runs immediately upon import. This is a potential side effect that occurs before any user interaction and could initiate network connections or other operations.

The messenger.send('rpc-requests', requests) calls (lines 22 and 55) transmit request data to a relay server whose URL is provided by messenger.relayUrl. The destination is not validated or restricted, and the data being sent could contain sensitive information. Additionally, open() constructs a URL containing the relay URL and opens it in a browser (lines 31-35), which could leak relay information.

The HTTP server sets 'Access-Control-Allow-Origin: *' combined with 'Access-Control-Allow-Private-Network: true'. This allows any website in a browser to make requests to this local server, potentially enabling DNS rebinding or cross-origin attacks against local services.

The server accepts POST requests at '/' with an unauthenticated JSON payload and dispatches it to internal listeners based on topic. No origin, token, or secret check is performed, so any process or webpage that can reach the port can publish arbitrary payloads to internal message handlers.

When the user declines to reveal the private key, the code writes the account's private key to a file named ${accounts[0].address}.key in import.meta.dirname — the package's own source/distribution directory — rather than a proper user-specific config directory. This persists sensitive key material into package scope and could leak the key to other users, future renders of the package, or packaging artifacts.

The 'Reveal private key?' confirmation prints the raw private key to the terminal via prompts.log.info. While user-initiated, printing raw private keys to terminal/stdout can leak them to shell history, log files, CI output, or screen-sharing sessions.

In cleanup(), when an uncaught exception or SIGTERM/SIGINT occurs and a temp key file exists, the code prints the file path and calls process.exit(1) without deleting the temp key file (cleanup of tempKeyFile via fs.rmSync only happens on the normal success path). On abnormal exits the private key may remain on disk indefinitely.

The code creates directories and files in os.tmpdir()/porto and writes .key files into import.meta.dirname. Writing into the package's own distribution directory (import.meta.dirname) is unexpected behavior that modifies installed package contents at runtime and is a persistence mechanism that could tamper with the module the user trust-installed.

Messenger.bridge is configured with targetOrigin for outbound messages, but inbound message handling (messenger.on('rpc-response' | 'ready' | '__internal')) appears to trust messages from the embedded iframe/opener. If the target host (hostUrl.origin) is compromised or if window.location can be influenced, responses including RPC results could be forged.

In the React Native authSession flow, the code parses 'payload' returned via redirect URL query parameters and directly JSON.parses it, treating it as RPC results (which may include signing keys, accounts, permissions). If the redirect URI is hijacked or the payload is manipulated, it could be consumed as a valid RPC response.

The fromWindow send() method defaults targetOrigin to '*' when no targetOrigin option or target parameter is provided. Using '*' in window.postMessage leaks message contents to any origin that can receive the message, which can expose sensitive data (e.g. auth tokens, payloads) to malicious frames or windows.

The cliRelay() function accepts an arbitrary relayUrl and uses it for both EventSource connections and fetch POST requests, sending payloads and receiving commands. If relayUrl is influenced by untrusted input (e.g. environment or remote config), this becomes a data exfiltration and remote-command channel. No allowlist, scheme validation, or authentication is enforced.

The code defines a production relay URL 'https://rpc.porto.sh' and staging URL 'https://stg-rpc.porto.sh'. All methods starting with 'wallet_' or 'account_', plus 'health', are routed to this external relay. While this appears to be an intentional design for a relay proxy, it means sensitive wallet/account RPC calls are sent to a third-party server controlled by the package authors, not the configured public transport. This is a potential data exfiltration vector if the package is compromised or if the relay is malicious.

The isRelay() function intercepts all 'wallet_*' and 'account_*' RPC methods and forwards them to the relay transport instead of the user-configured public transport. Wallet methods include highly sensitive operations such as wallet_sendTransaction, wallet_signTransaction, wallet_requestPermissions, and wallet_getCapabilities. Routing these to an external relay could allow the relay operator to observe or manipulate signing requests, though the actual signing typically happens client-side.

The exported 'code' field contains a large hex-encoded EVM bytecode blob with no plaintext source or comments. While the ABI and bytecode appear to implement a standard EIP-7702 proxy pattern (implementation/admin storage slots, fallback delegation), the bytecode is unverified and cannot be audited for hidden malicious behavior such as arbitrary delegatecalls, storage manipulation, or hardcoded addresses.

The bytecode embeds specific storage slot constants (0x360894a1... and 0xb5312768...) that match common proxy implementation/admin slots. If these differ from the documented EIP-7702 proxy spec, they could allow the contract author to redirect logic or seize admin control. No source mapping or verification hash is provided.

The file exports raw Ethereum contract bytecode ('code') for an ERC-721 contract. The bytecode contains low-level EVM assembly that is not human-readable and could hide arbitrary on-chain logic. While this is a standard ABI/bytecode export for a smart contract SDK, the actual contract behavior cannot be fully audited from the bytecode alone. The contract includes a 'mint' function that is payable and a 'mint()' no-argument function that could be called by anyone to mint tokens for free or for payment depending on implementation. There is also a constructor accepting a token address and price, suggesting this is an experiment/ERC-721 contract that may interact with an external ERC-20 token.

The ABI exposes a public 'mint()' function with no arguments and nonpayable state mutability, as well as 'mint(address recipient)'. If the contract allows arbitrary callers to mint tokens, this could lead to inflation or abuse depending on the intended use case. However, without decompiling the bytecode, the actual access control cannot be confirmed.

The constructor accepts an ERC-20 token address and a price, and the bytecode appears to call 'transferFrom' on that token during the 'mint()' no-argument function (see the bytecode snippet calling 0x23b872dd). This means the contract will attempt to transfer tokens from the caller to itself and then mint an NFT. If the token address is malicious or the price is manipulated, users could lose funds. This is a common pattern for paid NFT mints but requires trust in the contract owner and the token.

The file contains a large 'code' string literal with compiled Ethereum Virtual Machine (EVM) bytecode for an 'Orchestrator' smart contract. While not inherently malicious in a blockchain development context, this bytecode is unverified compiled code that could contain backdoors or vulnerabilities. Its presence in a JavaScript package is unusual and could be used to deploy or interact with a smart contract on-chain.

The bytecode is opaque and not human-readable, which hinders security auditing. It includes low-level operations (e.g., delegatecall, CREATE2 patterns via assembly-like opcodes) that could enable arbitrary execution or contract creation if invoked. Without source verification, malicious behavior cannot be ruled out.

The dialog renderer uses iframes (Dialog.iframe()) to communicate with external hosts (Dialog.hostUrls.prod by default). This establishes cross-origin communication channels that could be exploited if the host is compromised or if messages are not properly validated.

The code creates a provider that sends RPC requests to external services via the dialog/iframe mechanism. While this is expected functionality, it means sensitive wallet operations (signing, account creation, permissions) are delegated to external services.

The disconnect action performs a fetch to an external authUrl.logout endpoint with credentials: 'include', which sends cookies to an external server. The authUrl is derived from config.authUrl or stored in local storage, potentially allowing arbitrary external server communication with the user's credentials.

The authenticate function sends the user's wallet address, signature, chainId, message, and optionally publicKey to an external URL (authUrl.verify) via fetch. Since authUrl is provided by the caller and not validated, a malicious dApp or compromised configuration could direct this sensitive authentication data to an attacker-controlled server.

The fetch in authenticate uses credentials: 'include', which sends cookies and HTTP authentication credentials to whatever origin authUrl.verify points to. Combined with the lack of origin validation, this could facilitate credential leakage or CSRF-like attacks if an attacker controls the authUrl.

In buildMessage, when no nonce is provided, the code makes a POST request to an external authUrl.nonce endpoint, sending the user's wallet address and chainId. This could leak the user's wallet address to arbitrary third-party servers if the authUrl is malicious or compromised.

The actual logic is delegated to ./core/react-native/index.js and ./react-native/register.js, which are not included in the provided snippet. The safety of this entrypoint cannot be fully determined without reviewing those files, since configure() could contain arbitrary behavior (network calls, credential access, etc.).

The trustedOrigins check uses event.origin.endsWith(origin) to validate origins. This is vulnerable to origin spoofing because a malicious origin like 'evil-id.porto.sh.attacker.com' would pass the endsWith check for 'id.porto.sh'. This could allow unauthorized dialogs from attacker-controlled origins.

The code processes RPC requests based on the event.origin from messenger events without additional cryptographic validation. If the messenger implementation does not properly validate message sources, this could enable cross-origin request forgery against the wallet.

The code reads a 'relayUrl' query parameter from window.location.href and uses it to construct a Messenger.cliRelay instance. This allows an attacker to potentially redirect communications to an arbitrary external relay URL by crafting a malicious link, which could lead to data exfiltration or man-in-the-middle attacks.

The messenger is initialized to bridge communication between the current window and window.opener or window.parent. This cross-origin messaging could be exploited if the parent/opener is untrusted, potentially leading to data leakage or command execution if the messaging protocol is not properly validated.

This file defines an allowlist of external hostnames, including non-production, staging, development, ngrok, workers.dev, vercel.app, and localhost domains. If this allowlist is used for security-sensitive trust decisions (e.g., wallet connectivity, authentication origins, message signing, or deep-link handling), it could allow attackers or malicious dApps to impersonate trusted services or bypass origin checks.

The list contains many DeFi, wallet, exchange, and cross-chain bridge hostnames (e.g., uniswap.org, app.uniswap.org, jumper.exchange, relay.link, sushi.com, app.cashmere.exchange). If used to authorize wallet interactions or transaction signing, a compromised or typo-squatted domain in this list may lead to phishing or unauthorized signing approvals.

The list includes ephemeral or development infrastructure such as 'localhost', 'stg.localhost', 'anvil.localhost', 'daimo.ngrok.app', 'porto-react-native.ngrok.io', multiple '*.workers.dev', '*.vercel.app', and '*.ts.net' hostnames. These domains are not controlled by the package publisher and can be registered or repurposed by third parties, creating trust or spoofing risks if consumed as an allowlist.

The prepareCalls function creates a new client using a user-supplied merchantUrl via http(merchantUrl), causing network requests to an arbitrary external endpoint. While this appears to be an intended feature for merchant RPC, dynamic URLs can be abused for data exfiltration if attacker-controlled.

The code builds an HTTP transport from chain.rpcUrls.default.http and a relay object. This results in outbound network requests to RPC endpoints and a relay service whose URLs come from runtime configuration. While this is expected for a blockchain client, the destinations are not validated or allow-listed here, so a compromised config could direct traffic to attacker-controlled endpoints.

The module executes await Messenger.cliRelay() at the top level during import. This means network relay setup (potentially opening WebSocket/HTTP connections) runs simply by importing the module, before any explicit invocation. Import-time side effects can be exploited and make behavior harder to audit.

The dialog embeds a relayUrl into a URL opened in the browser and communicates over a messenger channel ('rpc-response', 'rpc-requests'). This creates a bidirectional bridge between the CLI process and a remote relay, which could be abused for data exfiltration or command relay if the relay URL is attacker-controlled or the transport is unauthenticated.

The server sets 'Access-Control-Allow-Origin: *' on all responses, including the SSE stream that carries relay payloads. Any web page can connect to this local server and read relayed messages or POST data into the messenger, enabling cross-origin data theft or message injection.

POST bodies are accumulated into a single string with no size limit. A malicious or buggy client can send arbitrarily large payloads, exhausting memory and potentially crashing the process.

Incoming POST data is parsed and dispatched to listeners based solely on the client-supplied 'topic' field. Combined with wildcard CORS, this allows cross-origin attackers to trigger application-level message handlers with arbitrary payloads.

The admin private key is written to a predictable temporary file path under os.tmpdir()/porto with a timestamp+Math.random() filename. While permissions are 0o600, the use of Math.random() and predictable temp directory could allow another local process to race or guess the filename and read the key. The catch block also silently swallows errors.

On confirmation, the private key is printed directly to the terminal via prompts.log.info, and it may also be logged via the cleanup path (shouldPrintKeyOnExit) on SIGINT/SIGTERM/uncaught errors. Logging secrets increases risk of leaking credentials to terminal scrollback, CI logs, or shell history.

When the user chooses not to reveal, the private key is written to a file named after the account address inside import.meta.dirname (the package's own source directory). Writing secrets into the application/package directory is a poor practice and may cause them to be committed or packaged.

The getRelayClient function uses user-supplied options.chain to dynamically index into the Chains namespace (Chains[chain]) without validation. While this is TypeScript, there is no runtime check that the chain exists or is a legitimate chain object. A malicious or unexpected value could lead to unpredictable behavior or access to unintended properties on the Chains object.

getRelayClient accepts an options.rpc parameter and passes it directly to viem's http() transport. This allows arbitrary RPC endpoints to be contacted, which could be used to send requests to attacker-controlled servers or to perform SSRF-like behavior depending on how the CLI invokes this function. No allowlist or validation is applied.

In fromWindow.on, origin validation only occurs when targetOrigin is explicitly configured. If targetOrigin is undefined, incoming message events from any origin are accepted and dispatched to listeners. This can allow cross-origin pages to inject spoofed messages (e.g. fake rpc-response, ready, or __internal payloads), potentially influencing wallet/RPC flows.

The messenger schema includes rpc-requests and rpc-response topics that carry RPC requests/responses. These are posted via w.postMessage using the potentially wildcard target origin, which could expose RPC payloads to unintended recipients if the window is embedded or opened by a malicious origin.

The send method in fromWindow defaults to a target origin of '*' when no targetOrigin is provided. Posting messages with a wildcard origin can leak sensitive payloads (e.g. RPC requests/responses, ready options, themes) to any window that has a reference to the sender, and can enable message spoofing/hijacking. A specific target origin should be required.

cliRelay connects an EventSource to a caller-provided relayUrl and POSTs message payloads to the same URL. Incoming SSE messages are JSON.parsed and dispatched to listeners based solely on data.topic and data.payload presence, with no schema validation, origin check, or authentication. A malicious or compromised relay can send arbitrary payloads (including __internal init/theme/resize or rpc-response messages) to the client, and the client will forward potentially sensitive RPC data to that relay.

The cookie() storage implementation sets cookies with samesite=None; secure and a 1-year max-age, and parses cookie values with JSON.parse. While this is primarily a configuration concern rather than malicious behavior, setting SameSite=None without proper CSRF protections can expose stored data to cross-site attacks. The cookie name and value are interpolated directly into the cookie string without encoding, which could allow cookie injection if name/value contain special characters like ';' or '='.

The cookie storage serializes arbitrary values (via Json.stringify) into document.cookie with a long-lived max-age. Cookies are accessible to any JavaScript on the same origin and are automatically sent with cross-site requests, making them a generally poor storage location for sensitive data (e.g., tokens, keys). If the consuming application stores secrets via this Storage abstraction, they could be exfiltrated via XSS or leaked cross-origin.

The file exports a large hex-encoded Ethereum smart contract bytecode string ('code'). This EVM bytecode is heavily optimized/obfuscated (e.g., uses non-standard jump tables, packed storage, and hashed function selectors). While it appears to be legitimate account abstraction/wallet code (IthacaAccount), the obfuscation makes it impossible to verify its full behavior statically. It could contain hidden privileged functions or backdoors.

The ABI includes a function 'execute' with arbitrary calls (to, value, data) and a fallback/receive that can execute arbitrary calldata. Combined with signature validation and key management, this is typical of smart contract wallets but could be abused if the contract has flaws or hidden logic. The presence of 'pay' and 'spendLimit' functions suggests payment and token spending capabilities.

The contract includes an 'upgradeProxyAccount' function and an 'upgradeHook', indicating a proxied upgradeable contract. The implementation address can be changed, potentially allowing a malicious upgrade if the orchestrator or keys are compromised. The EIP-1967 implementation slot pattern is used.

The file is a generated TypeScript contract interface containing raw bytecode and ABI. No source Solidity is provided, so the actual logic cannot be audited. This is a third-party package, and the bytecode is the ultimate authority for on-chain behavior.

The code modifies the global 'crypto' object at import time using Object.defineProperty with enumerable: true on non-web platforms. This monkey-patches a standard global API, which could alter the behavior of other libraries expecting the native implementation. While it delegates to ExpoCrypto, it replaces the platform's crypto implementation globally.

The trustedOrigins check uses event.origin.endsWith(origin), which can be bypassed by malicious domains like 'evil-id.porto.sh' or 'attacker-localhost:5173'. This weakens the sameOrigin security check and could allow unauthorized dialog handling from spoofed origins.

The module reads a 'relayUrl' from window.location.search and, if present, creates a Messenger.cliRelay with that attacker-controllable URL. This allows arbitrary external URLs to be used as a message relay endpoint, which could enable data exfiltration from the consuming application's context (e.g., dApp requests, user data) to an attacker-controlled server. The relay URL is not validated against the trustedHosts list.

The messenger is constructed from window and window.opener/window.parent without explicit origin checks at initialization time. Communication established via postMessage with an opener/parent window could be exploited if the embedding page is not fully trusted, potentially leaking RPC requests and responses across frames.

The router applies hono.use('*', cors(options.cors)) with a caller-supplied configuration and no default restrictions. If options.cors is omitted or set permissively, the API (including merchant RPC endpoints that sign feePayerDigest payloads with an admin key) would be reachable from any origin, enabling cross-site requests to the signing service.

merchant() accepts an admin private key (Hex or {type, privateKey}) and signs feePayerDigest payloads returned by the relay, while all other RPC traffic goes to the configurable relay endpoint. A malicious or compromised relay could return attacker-chosen digests to obtain signatures, or observe metadata about every request. The relay is fully caller-configurable and no allowlist/validation is applied.

This file is a hardcoded list of trusted hostnames. It does not execute code, perform network requests, read environment variables or files, spawn processes, or use dynamic code execution. However, it contains several development, staging, tunneling, and temporary hosting domains (e.g., 'anvil.localhost', 'localhost', 'stg.localhost', '.ngrok.app', '.ngrok.io', '.workers.dev', '.vercel.app', '.ts.net') that could weaken host verification if this allowlist is used in production to authorize requests. No direct malicious pattern is present, but the list is suspiciously broad for a 'trusted hosts' allowlist.

The sign() function includes the full key object (including any privateKey field, though it is a function or CryptoKey rather than a raw string in most branches) in error messages via Json.stringify when no private key exists or when the key type is unsupported. If consumers pass keys with extractable private key material (e.g. raw hex strings in custom wrappers), this could leak secrets into logs or error reports. Additionally, fromP256 and fromHeadlessWebAuthnP256 close over raw private key hex strings in the privateKey() function.

The prepareCalls function accepts a merchantUrl parameter and creates a new HTTP client via createClient({ transport: http(merchantUrl) }) to send prepared call data (including the user's account address, calls, and authorization keys) to an externally-supplied URL. The response is verified via verifyPrepareCallsResponse, but this pattern still constitutes an outbound network request to an arbitrary user/parameter-controlled endpoint, which could be exploited for data exfiltration if merchantUrl is attacker-controlled. The error is only logged via console.error on failure, silently falling back to the default client.

Uses custom(provider) from viem to route JSON-RPC calls through a caller-supplied provider. The provider originates from the Porto instance; if that instance is attacker-controlled, all wallet RPC traffic (including signing requests) flows through it. This is expected behavior for a wallet client wrapper, but it represents a trust boundary worth highlighting.

verifyPrepareCallsResponse verifies a quote signature by recovering an address and comparing against quoteSigner fetched from health(client). If the relay endpoint is compromised or MITM'd, the quote signer could be replaced and malicious prepared calls accepted. The trust model relies entirely on the relay's transport security. Note: the signature is over a JSON-stringified sorted payload hashed with keccak256 - not a standard EIP-712 domain-separated scheme, which could create cross-protocol replay risks.

The file executes '../react-native/register.js' at module import time via a top-level import statement. This side-effect import runs before any exported functionality and can perform arbitrary initialization, monkey-patching, or environment modification. While not inherently malicious, side-effect imports at the top level are a common vector for hidden behavior in third-party packages and warrant inspection of the imported module.