Back to skill

Security audit

Go4Me

Security checks for vulnerabilities and agentic risk

Overview

This skill is openly about sending Chia, but its payment flow is under-scoped for irreversible wallet transactions.

Install only if you are comfortable letting an agent use Sage Wallet to submit Chia transactions after confirmation. Treat send and tip commands as high-risk: verify the resolved address, exact mojo amount, and fee yourself, and avoid using natural-language payment requests until the skill adds strict handle validation, address validation, amount limits, safer JSON construction, and clearer irreversible-transfer warnings.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/go4me-lookup.sh:6
Finding
Arbitrary HTTPS Request Destination Through Username Injection<![CDATA[ ## Vulnerability Details **File Location**: `scripts/go4me-lookup.sh:6-18` **Vulnerability Type**: Improper input validation and URL authority injection **Risk Level**: Medium ### Vulnerable Code ```bash go4me_lookup() { local username="${1#@}" # Strip @ if present if [[ -z "$username" ]]; then echo '{"error":"Username required"}' >&2 return 1 fi local url="https://${username}.go4.me/" local response local http_code # Fetch page and capture HTTP code response=$(curl -s -w "\n%{http_code}" "$url" 2>/dev/null) ``` ### Technical Analysis The function removes one leading `@` but does not validate that the remaining input conforms to the permitted Twitter-handle syntax. It embeds the untrusted value directly into the authority portion of an HTTPS URL. Characters that have special meaning in a URL authority—particularly `@`—can change how `curl` interprets the hostname. For example, the input: ```text ignored@attacker.example/path ``` produces: ```text https://ignored@attacker.example/path.go4.me/ ``` In URL syntax, `ignored` is interpreted as user information and `attacker.example` becomes the destination host. The suffix `/path.go4.me/` is interpreted as the request path rather than as part of the hostname. Quoting `"$url"` prevents shell word splitting but does not prevent semantic URL injection. TLS certificate verification remains enabled and provides some protection, but an attacker controlling a domain with a valid certificate can still receive the request. ### Attack Path 1. An attacker supplies a crafted lookup value containing an authority delimiter, such as `ignored@attacker.example/path`. 2. `go4me_lookup` removes only an optional leading `@` and accepts the remainder unchanged. 3. The value is concatenated into `https://${username}.go4.me/`. 4. `curl` parses the injected `@` and treats the attacker-controlled domain as the destination hostname. 5. The skill sends an HTT ...[truncated 859 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Apply strict allowlist validation before constructing the URL. If the intended identifier is a Twitter/X handle, accept only the documented handle character set and length: ```bash go4me_lookup() { local username="${1#@}" if [[ ! "$username" =~ ^[A-Za-z0-9_]{1,15}$ ]]; then printf '%s\n' '{"error":"Invalid username"}' >&2 return 1 fi local url="https://${username}.go4.me/" # Continue with the request. } ``` Additional hardening should include: 1. Reject URL separators, dots, whitespace, additional `@` characters, percent-encoding, and control characters. 2. Configure `curl` with explicit failure and timeout behavior, such as `--fail-with-body`, `--connect-timeout`, and `--max-time`. 3. Restrict redirects or validate every redirect destination before following it. The current command does not follow redirects, and that property should not be changed without validation. 4. If more flexible identifiers are later required, construct and parse the URL using a URL-aware library and verify that the final hostname is exactly a valid single-label subdomain of `go4.me`. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:40
Finding
Unvalidated Transaction Fields and Unsafe JSON Construction<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:40-52` and `SKILL.md:66-75` **Vulnerability Type**: Missing transaction validation and unsafe interpolation into a wallet request **Risk Level**: Medium ### Vulnerable Code ```bash ### Send 1. Lookup user (as above) 2. If not found, report error 3. Display confirmation: ``` Send <amount> to @<username> (<fullName>)? Address: <xchAddress> [Yes] [No] ``` 4. On confirm, call sage-wallet `send_xch`: ```bash curl -s --cert $CERT --key $KEY -X POST https://127.0.0.1:9257/send_xch \ -H "Content-Type: application/json" \ -d '{"address":"<xchAddress>","amount":"<mojos>","fee":"0","memos":[],"auto_submit":true}' ``` 5. Report transaction result ``` The associated amount-processing instructions are: ```bash ## Amount Conversion | Input | Mojos | |-------|-------| | `1` (no unit) | 1 mojo | | `1 mojo` | 1 | | `0.001 XCH` | 1000000000 | | `1 XCH` | 1000000000000 | Parse amount: if contains "XCH", multiply by 10^12. Default unit is mojos for small numbers, XCH for decimals. ``` ### Technical Analysis The workflow submits a transaction with `"auto_submit":true`, but it does not define concrete validation requirements for the network-derived `xchAddress` or the user-derived amount. Although the error-handling table mentions an invalid address, the transaction workflow does not specify: - Canonical Chia address decoding and checksum validation. - Enforcement of the expected `xch` network prefix. - A strict integer representation for the final mojo amount. - Rejection of negative, zero, fractional-mojo, non-finite, excessively large, or overflow-producing values. - A maximum transaction amount. - Safe programmatic JSON construction. The example inserts placeholders into a single-quoted JSON argument. If an implementation performs literal textual substitution, unexpected quote or control characters in a field can produce malformed JSON. If substitution is implemented thro ...[truncated 2226 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Establish a mandatory validation and serialization boundary before confirmation and submission: 1. Decode the Chia address using a maintained Chia address library. 2. Verify its Bech32m encoding, checksum, payload length, and expected network prefix. 3. Parse amounts using decimal or integer arithmetic rather than floating-point arithmetic. 4. Convert XCH to mojos exactly and reject values that produce fractional mojos. 5. Require the final mojo amount to be a positive integer within an explicitly configured maximum. 6. Reject scientific notation, signs, unsupported units, non-finite values, and ambiguous input. 7. Construct JSON with a serializer rather than textual interpolation. For example: ```bash payload="$( jq -n \ --arg address "$validated_address" \ --arg amount "$validated_mojos" \ '{ address: $address, amount: $amount, fee: "0", memos: [], auto_submit: false }' )" curl --fail-with-body \ --silent --show-error \ --cert "$CERT" \ --key "$KEY" \ --request POST \ 'https://127.0.0.1:9257/send_xch' \ --header 'Content-Type: application/json' \ --data-binary "$payload" ``` 8. Display the canonical validated address and exact integer mojo amount during confirmation. 9. Bind the confirmation to a digest or immutable transaction object so values cannot change between review and submission. 10. Prefer transaction creation with `auto_submit:false`, inspect the resulting transaction, and submit it only after the validated details match the user's confirmation. 11. Quote `"$CERT"` and `"$KEY"` and verify that both files have appropriately restrictive permissions. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (5)

Tp4

High
Category
MCP Tool Poisoning
Confidence
94% confidence
Finding
The skill claims it can send and tip XCH based on Twitter/Go4Me identity resolution, but the documented implementation is inconsistent and incomplete, creating a dangerous trust gap around financial actions. When a payment skill's declared behavior does not precisely match what is actually implemented, users and downstream agents may approve transfers under false assumptions about identity verification, transaction handling, or safeguards.

Vague Triggers

Medium
Confidence
94% confidence
Finding
The README advertises broad natural-language triggers like 'Send 1 XCH to @hoffmang' and 'Tip @sage_wallet' for a skill that can move cryptocurrency. In a transactional context, overly permissive invocation phrasing increases the chance of unintended activation, prompt ambiguity, or social-engineering-driven transfers, especially when the agent may interpret casual text as an authorization to initiate a payment flow.

Lp3

Medium
Category
MCP Least Privilege
Confidence
94% confidence
Finding
The skill documents shell-based behavior and a wallet transaction workflow but declares no explicit tool scope or permissions. In an agent environment, missing scope increases the chance the skill can invoke shell capabilities or sensitive operations without clear sandboxing or user-visible constraints, which is especially risky because the workflow involves wallet access and transaction submission.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill describes sending XCH using local wallet certificates/keys and auto-submitting an on-chain transaction, but it does not prominently warn users that invoking send functionality will use local wallet credentials and move funds. In a financial context, omission of this warning is dangerous because it can lead to uninformed consent and accidental irreversible transfers.

External Transmission

Medium
Category
Data Exfiltration
Content
```
4. On confirm, call sage-wallet `send_xch`:
   ```bash
   curl -s --cert $CERT --key $KEY -X POST https://127.0.0.1:9257/send_xch \
     -H "Content-Type: application/json" \
     -d '{"address":"<xchAddress>","amount":"<mojos>","fee":"0","memos":[],"auto_submit":true}'
   ```
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.