T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/agentwalletapi.sh:268
- Finding
- Immutable Global User Tag Can Be Set Without Enforced Confirmation## Vulnerability Details **File Location**: `scripts/agentwalletapi.sh`, lines 268–280 **Vulnerability Type**: Missing confirmation gate for an irreversible authenticated state change **Risk Level**: Medium ### Vulnerable Code ```bash user-tag-set) USER_TAG="$2" if [ -z "$USER_TAG" ]; then echo "Usage: agentwalletapi.sh user-tag-set <userTag> [--yes]" exit 1 fi json_escape_var USER_TAG_ESC "$USER_TAG" BODY="{\"userTag\":\"$USER_TAG_ESC\"}" curl -s -X PUT \ -H "X-Agent-Key: $AGENTWALLETAPI_KEY" \ -H "Content-Type: application/json" \ -d "$BODY" \ "$BASE_URL/api/agent/user-tag" | pretty_print_json ;; ``` ### Technical Analysis The `user-tag-set` command performs an authenticated `PUT` request that sets the account-wide checkout user tag. The project describes this value as one-time and immutable in `SKILL.md:226`, while both `SKILL.md:90` and the CLI usage text present `--yes` for this operation. However, the implementation does not invoke `confirm_risky_action` and does not otherwise check `FORCE_RISKY`. Consequently, supplying or omitting `--yes` has no effect: the persistent change is submitted immediately whenever the command receives a nonempty tag. This crosses the boundary between a local CLI request and persistent authenticated account state without enforcing the confirmation control represented by the interface. Although this is not evidence of malicious intent, it is a reachable discrepancy for an irreversible operation. ### Attack Path 1. The CLI has access to a configured `AGENTWALLETAPI_KEY`. 2. An Agent workflow or local caller invokes: ```bash bash scripts/agentwalletapi.sh user-tag-set studio ``` No `--yes` flag or interactive confirmation is required. 3. The script places the supplied value in a JSON body. 4. It immediately sends an authenticated `PUT` request to `/api/agent/user-ta ...[truncated 762 chars]
- Remediation
- ## Remediation Suggestions - Invoke `confirm_risky_action "Global user tag assignment"` at the beginning of the `user-tag-set` branch. - Require `--yes` for non-interactive execution and require an exact interactive `YES` response otherwise, consistently with other consequential write operations. - Validate the documented tag format locally before confirmation and submission, including length and permitted characters. - Display the proposed tag and target API host in the confirmation prompt so the user can verify the irreversible value. - Keep server-side authentication, format validation, and one-time assignment enforcement in place; client-side confirmation must supplement rather than replace server-side controls. - Add regression tests verifying that invocation without `--yes` fails in non-interactive mode and that an interactive rejection sends no request.