Is eucalyptus-viminalis/leak-buy safe?

The skill's primary payment mechanism reads a user-specified file as a buyer private key and uses it to sign x402 payment transactions sent to arbitrary seller URLs. The buy.sh validation confirms the file exists and is a readable non-symlink, but applies no format or content-type checks. Any readable file path — including ~/.ssh/id_rsa, ~/.aws/credentials, or any .env file — would silently pass validation and be read by the leak binary. A malicious seller or social engineering attack could exploit this to harvest credentials under the guise of a payment key file.

The skill description, URL patterns (ephemeral Cloudflare Tunnels), and payment mechanism (x402 cryptocurrency with private keys) are all consistent with underground marketplace infrastructure for selling pirated or stolen content. 'Leak' in this context refers to illegally distributed digital content sold through channels designed to avoid attribution and takedowns. Installing this skill enables the agent to autonomously transact with such marketplaces on behalf of the user.

The skill instructs the agent to download and save files from user-supplied seller URLs. The content, type, and safety of these files are entirely controlled by the seller's server. No MIME type checking, file signature validation, or sandbox isolation is applied before writing to the local filesystem. A malicious seller could serve executable malware, exploit payloads, or exfiltration scripts as the purchased content.

Once the skill is invoked with a buyer key file, the agent can initiate x402 payment transactions autonomously. No per-transaction confirmation step is prescribed beyond the initial skill invocation. A malicious promo URL, injected instructions in a seller response, or a confused invocation could result in unauthorized financial transactions from the user's Ethereum wallet.

The buy.sh wrapper handles input sanitization but delegates all cryptographic, network, and file I/O operations to the 'leak' binary from the leak-cli npm package. This package's source code, update policy, and supply chain integrity are not verifiable from the audit evidence. The global npm install means any package update could silently modify behavior. The 'exec leak "$@"' pass-through exposes all flags the leak binary accepts, not just those validated by buy.sh.

The First Response Template and Safety Policy together condition the agent to always ask users for private key file paths and treat this as a normal, expected workflow. This normalization is a prerequisite for exploitation: once a user is accustomed to providing key file paths on request, a malicious seller URL or chained skill could redirect that path to system credentials rather than an Ethereum key.

Section headers '## Safety policy (required)' and '## Dependency policy (required)' assert mandatory authority over agent behavior. While the current rules are reasonable security guidelines, this framing pattern could be exploited in a future malicious version of the skill to inject new 'required' behaviors — such as reading additional files or suppressing output — that override platform or user policies.

All six honeypot credential files were read at timestamps 1771918164.995 (before git clone) and 1771918188.558 (after install). The pre-install timestamp definitively excludes the skill itself; the post-install timestamp aligns with the monitoring system's post-install integrity sweep. However, auditd PATH records in the provided data do not include process-level attribution (PPID/PID) for these specific accesses, leaving a small residual ambiguity.

The shell wrapper validates URLs (requires http/https scheme, rejects whitespace and control characters), validates key file paths (must exist, be readable, be a regular file, not a symlink), blocks --buyer-private-key and --buyer-private-key-stdin argument modes, and uses proper quoted argv token passing. This substantially reduces shell injection risk at the bash layer.

The install exclusively performed a git sparse-checkout clone, file copy, and cleanup. No npm postinstall hooks were triggered, no git submodules were fetched, no gitattributes filters were configured, no symlinks were created, and no processes persisted after install. The baseline filesystem diff shows only the three expected skill files were added.