T06 · System Persistence
Warning
- Location
- SKILL.md:64
- Finding
- Persistent Authentication Poller Installed as a Cron Job## Vulnerability Details **File Location**: `SKILL.md`, lines 64–73 **Vulnerability Type**: Persistent scheduled task containing authentication state **Risk Level**: Medium ### Vulnerable Code ```markdown ## Purchase & Login Flow — CRITICAL When generating a `checkout_url` (via `POST /orders/purchase`) or `login_url` (via `POST /auth/login-link`), you **MUST send the link to the user as a message BEFORE calling any tools** (curl, exec, cron). If you call a tool first, the message with the link gets blocked and the user never sees it. Correct sequence: 1. **Reply to the user** with the `checkout_url` or `login_url` 2. **After the reply**, set up a cron (every 30s) to poll `GET /auth/claim?magic=...` 3. When claim returns `status: "ready"`, save the JWT token securely Do NOT use `while`/`sleep` loops — use a cron job or poll on the user's next message. ``` ### Technical Analysis The Skill explicitly directs the agent to create a cron job that runs every 30 seconds and polls an external authentication endpoint using a magic token. A cron entry is persistent system state: it can continue executing after the immediate Skill invocation or interactive session ends. No instruction requires the scheduled task to be removed after the claim becomes ready, fails, or expires. The magic token may also be placed in the cron definition or its associated command line, exposing authentication material to users or processes able to inspect scheduler configuration or process arguments. The document already identifies polling on the user's next message as a non-persistent alternative, making installation of a recurring system task unnecessary for the stated operation. ### Attack Path 1. A user initiates a purchase or login flow through the Skill. 2. The service returns a login URL containing a magic authentication token. 3. Following the Skill instructions, the agent creates a cron job that runs every 30 seconds. 4. The sche ...[truncated 1027 chars]
- Remediation
- ## Remediation Suggestions - Remove the instruction to create a cron job for authentication polling. - Poll only during an active, user-approved interaction, or defer polling until the user's next message. - If bounded automatic polling is required, enforce a short retry limit and a strict expiration time. - Never place magic tokens or JWTs directly in cron files, shell command lines, logs, or other broadly inspectable locations. - Store authentication material in a secret-management facility with restrictive access controls. - Clear temporary authentication state immediately after success, failure, cancellation, or expiration. - If scheduling is unavoidable, create a one-shot task with an explicit timeout and guaranteed cleanup logic that removes the task on every terminal outcome. - Require informed user confirmation before making any persistent system-level change.