Wake Up

• Outcome: Review
• Latest audit: Sep 12, 2026 · 2:12 AM UTC
• Version: 1.3.0

Overview

The skill does what it says, but it asks an agent to use a Solana signing key for automatic paid API calls without strong local payment limits or endpoint constraints.

Review carefully before installing. Use only a dedicated low-balance Solana wallet, do not use a primary wallet, keep the default wake.meup.ai endpoint unless you fully trust another endpoint, and avoid putting sensitive personal details in hints. Treat every verification and scheduled call as a paid third-party action that shares your phone number and schedule details with the service.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/wake-cli.py:94
• Finding: Automatic x402 Payment Signing Without Local Transaction Constraints<![CDATA[ ## Vulnerability Details **File Location**: `scripts/wake-cli.py:94-103`, `scripts/wake-cli.py:152-167`, and `scripts/wake-cli.py:201-205` **Vulnerability Type**: Unrestricted automatic signing of server-proposed payment transactions **Risk Level**: High ### Vulnerable Code ```python async def cmd_verify(args: argparse.Namespace) -> int: """Run the verify flow: POST /verify, then poll until resolved.""" signer = load_signer(args.keypair) log(f"Signer address: {signer.address}") x402 = x402Client() register_exact_svm_client(x402, signer) async with x402HttpxClient(x402, base_url=args.base_url) as client: # Step 1: POST /api/v1/verify log(f"POST {args.base_url}/api/v1/verify") resp = await client.post( "/api/v1/verify", json={"phone": args.phone}, ) ``` ```python async def cmd_schedule(args: argparse.Namespace) -> int: """Run the schedule flow: POST /schedule.""" signer = load_signer(args.keypair) log(f"Signer address: {signer.address}") x402 = x402Client() register_exact_svm_client(x402, signer) body = { "phone": args.phone, "times": args.time, "voice": args.voice, } if args.hints: body["hints"] = args.hints async with x402HttpxClient(x402, base_url=args.base_url) as client: log(f"POST {args.base_url}/api/v1/schedule") resp = await client.post("/api/v1/schedule", json=body) ``` ```python parser.add_argument( "--base-url", default="https://wake.meup.ai", help="Base URL for the Wakeup API (default: https://wake.meup.ai)", ) ``` ### Technical Analysis The client registers a funded Solana keypair with the x402 client and then permits the HTTP client to handle payment negotiation automatically. No application-level control verifies the payment recipient, USDC mint, Solana network, transaction amount, or cumulative expenditure before a signature is produced. The documentatio ...[truncated 1879 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Enforce a strict allowlist of API origins. In production mode, require exactly `https://wake.meup.ai` and reject user-info components, non-HTTPS schemes, unexpected ports, redirects to different origins, and ambiguous hostnames. 2. Before signing, decode and validate every payment proposal: - Require the intended Solana network. - Require the expected USDC mint. - Require an allowlisted recipient account. - Enforce a maximum of $0.50 USDC for verification. - Enforce a maximum of $2.00 USDC per scheduled call. - Verify that the total charge matches the number of requested calls. 3. Add per-transaction, per-run, and cumulative spending limits. 4. Display the recipient, mint, network, amount, and operation to the user and require explicit confirmation before signing, particularly when a custom endpoint is used. 5. Reject transactions containing additional transfers, instructions, account authorities, or permissions not required for the documented payment. 6. Prefer a dedicated low-balance wallet with no unrelated assets and document this as a required security boundary rather than only a recommendation. 7. Add tests using malicious x402 responses to verify rejection of excessive amounts, substituted recipients, incorrect mints, incorrect networks, and unexpected instructions. ]]>

T08 · Insecure Dependencies

Warning

• Location: scripts/wake-cli.py:2
• Finding: Security-Sensitive Dependencies Are Resolved from Mutable Version Ranges<![CDATA[ ## Vulnerability Details **File Location**: `scripts/wake-cli.py:2-5` **Vulnerability Type**: Unlocked runtime dependency resolution for wallet-signing components **Risk Level**: Medium ### Vulnerable Code ```python # /// script # requires-python = ">=3.11" # dependencies = ["x402[svm]>=2.0.0,<3", "httpx>=0.27,<1"] # /// ``` ### Technical Analysis The script uses PEP 723 dependency metadata with broad version ranges. Running it through `uv run` may resolve and install any future package release satisfying those ranges. The project does not include a lockfile or hash-pinned dependency manifest in the audited directory. This is security-sensitive because the `x402` package and its transitive dependencies execute in the same Python process that loads the Solana keypair and creates payment signatures. A newly published, compromised, or otherwise unsafe version within the accepted range could therefore access key material, alter payment proposals, redirect requests, or exfiltrate signatures. This finding does not establish that the currently available packages are malicious. The vulnerability is the lack of reproducible and integrity-constrained dependency selection for components trusted with wallet-signing authority. ### Attack Path 1. An attacker compromises an allowed direct or transitive dependency release, or gains the ability to publish a malicious version within the accepted range. 2. A victim runs the script in an environment where that version is selected during dependency resolution. 3. The dependency is downloaded and imported into the client process. 4. Its initialization or runtime code executes with the permissions of the user running the script. 5. The malicious dependency can inspect process data, access files available to the process, intercept the loaded keypair or payment flow, and transmit sensitive material using the process's network access. ### Impact Assessment Exploitation occurs with the operating-system privileges of th ...[truncated 569 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every direct dependency to an exact reviewed version rather than a version range. 2. Commit a reproducible `uv.lock` file and execute the client in locked or frozen mode so dependency resolution cannot silently change. 3. Use package hashes or another integrity-verification mechanism for direct and transitive artifacts. 4. Review the complete transitive dependency graph, with particular attention to packages that process transactions or receive signing objects. 5. Introduce an explicit dependency-update process that includes source review, vulnerability scanning, provenance verification, and payment-flow regression tests. 6. Use a controlled package index or internal artifact mirror where practical. 7. Isolate the signer from the network-facing dependency stack. A separate signing component should decode, validate, and approve only narrowly defined transactions before producing a signature. 8. Continue using a dedicated low-value wallet so compromise of the runtime environment has a limited financial impact. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (6)

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 91% confidence
• Finding: The skill instructs use of environment variables, local keypair files, and outbound network access, but it does not declare an explicit tool scope or permissions boundary. That creates an avoidable least-privilege gap: an agent/runtime may grant broader capabilities than necessary, increasing the blast radius if the skill is misused or if later content becomes malicious.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill encourages sending personalized `hints` and states that the AI remembers past calls, but it does not prominently warn that this personal context is sent to and potentially retained by a third-party service. Because the examples include sensitive profile details and preferences, users may unknowingly disclose personal information that persists beyond the immediate transaction.

Vague Triggers

Medium

• Confidence: 92% confidence
• Finding: The trigger conditions are broad enough to activate for generic requests about alarms, morning routines, or being called, which can route users into a third-party telephony and payment workflow without sufficiently clear narrowing. In context, that increases the chance of unnecessary collection of phone numbers, transmission of personal details, and initiation of paid actions when a simpler local reminder would have sufficed.

Missing User Warnings

Medium

• Confidence: 80% confidence
• Finding: The script reads a Solana keypair from disk or environment-derived path and uses it to authorize x402 payment flows. While the code documents the file format, it does not clearly warn users that this credential is sensitive and will be used to sign payment-related transactions.

Missing User Warnings

Medium

• Confidence: 87% confidence
• Finding: This code sends a user's phone number to the wake.meup.ai API during verification, and similar transmission occurs for scheduling requests. Although the script logs the endpoint being called, it does not clearly warn users that personal data and optional contextual hints will be sent to a third-party service.

Context-Inappropriate Capability

Low

• Confidence: 77% confidence
• Finding: The manifest describes scheduling wake-up calls, phone verification, voice selection, and x402 USDC payment, but does not mention reading local environment variables for credentials. While payment support is in scope, sourcing a signing key from SOLANA_KEYPAIR_PATH is an extra capability that is not clearly justified by the stated end-user purpose and expands access to local secret material.

Static analysis

No suspicious patterns detected.