Is ajarmoszuk/crypton-esim safe?
https://github.com/openclaw/skills/tree/main/skills/ajarmoszuk/crypton-esim
The crypton-esim skill is technically clean: no prompt injection instructions, no malicious code, no credential harvesting, and installation contacted only GitHub. However, the skill is purpose-built to facilitate anonymous eSIM purchases using Monero and Bitcoin with no identity verification, presents live cryptocurrency payment addresses in agent output without confirmation safeguards, and relies entirely on an unvalidated third-party API (crypton.sh) for all functionality including eSIM activation codes. The combination of broad generic triggers, anonymous financial transaction capability, and full dependency on an external unverified service warrants caution before deployment.
Category Scores
Findings (10)
HIGH Explicit anonymous Monero purchasing facilitates untraceable financial transactions -35 ▶
The skill's core feature set is explicitly designed around anonymity: no account, no identity verification, and support for Monero (XMR), a privacy coin specifically engineered to prevent transaction tracing. This makes the skill a direct enabler for anonymous communication infrastructure procurement. While purchasing an eSIM is not inherently illegal, the deliberate design for untraceability creates meaningful risk of misuse by threat actors seeking anonymous burner connectivity.
HIGH All user purchase data transmitted to unverified third-party API without response validation -25 ▶
Every interaction — browsing plans, creating checkouts, checking order status, retrieving eSIM activation codes — flows through the external crypton.sh API. eSIM activation codes (LPA format) and ICCID values returned from the API are presented directly to users without validation. A compromised or DNS-hijacked crypton.sh endpoint could inject attacker-controlled activation codes, substitute payment addresses to steal cryptocurrency payments, or return malicious content into the agent's response stream.
MEDIUM Skill can present live payment addresses to users without autonomous purchase safeguards -20 ▶
The buy command creates real checkout sessions with live Bitcoin and Monero payment addresses returned from the API and displayed to users. If this skill is installed alongside a cryptocurrency wallet skill, the combination could enable an agent to autonomously initiate purchases when the broad trigger terms appear in conversation. No confirmation or authorization step exists between trigger detection and payment address presentation.
MEDIUM Overly broad trigger vocabulary risks unintended skill activation in IT/enterprise contexts -15 ▶
The skill registers six trigger phrases that are common in enterprise network administration and IT operations: 'mobile data', 'travel data', 'data plan', 'roaming', plus the more specific 'esim'/'buy esim'/'get esim'. An agent supporting an IT administrator asking about corporate mobile data usage policies or configuring roaming rules on a network device could accidentally invoke this skill, triggering outbound API calls to crypton.sh.
MEDIUM API endpoint hardcoded with no certificate pinning or response integrity verification -15 ▶
The API base URL is baked into the code as a string constant. There is no TLS certificate fingerprint pinning, no HMAC response signing, and no JSON schema validation on any API response. The skill calls response.json() directly and accesses dict keys by name. This means DNS poisoning, BGP hijacking, or a compromise of crypton.sh's infrastructure would be completely transparent to the skill.
MEDIUM Country code extraction heuristic matches arbitrary 2-letter uppercase tokens -5 ▶
The _extract_country_code() method scans for any 2-letter uppercase sequence in the user message. This regex would match 'US' in 'update US server config', 'EU' in 'EU compliance audit', 'JP' in 'JP Morgan transaction', etc. In such cases the skill would call the eSIM plans API for that country and potentially present irrelevant eSIM offers in the middle of an unrelated task.
LOW Python dependency unpinned beyond minimum version floor -8 ▶
The only dependency, 'requests>=2.28.0', is specified with a minimum version constraint only. This means future installs could pull any later version of the requests library, including versions that have not been reviewed for this skill. Hash-pinning (pip's --require-hashes) is absent.
LOW Executable Python code present and makes live outbound network connections -10 ▶
crypton_esim.py is runnable Python that establishes a requests.Session() and makes HTTPS calls to crypton.sh. No subprocess, exec(), eval(), or shell invocation was found. The code is a straightforward API wrapper. Risk is low but the execution surface exists.
INFO Expected GitHub HTTPS connection during installation — no other external contacts -5 ▶
The only outbound connection during skill installation was a standard HTTPS connection to 140.82.121.4:443 (github.com) to clone the skills monorepo. No connections were made to crypton.sh, CDNs, or any other hosts. No new persistent listeners were created and the connection state after install is identical to before.
INFO Canary file reads attributable to monitoring infrastructure, not skill code -5 ▶
The honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, GCP credentials) appear in both inotifywait and auditd PATH records at two time points: audit timestamp 1771654212 (approximately 6 seconds before the git clone began) and 1771654234 (after installation complete). These correspond to the oathe audit system's own pre- and post-installation canary baseline sweeps. The skill's Python code contains no file I/O operations.