T09 · Insecure Skill Coding Practices
- Location
SKILL.md:86- Finding
Unbounded Task-Result Polling Can Exhaust Resources and API Quota
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 86-102
Vulnerability Type: Unbounded polling and incomplete terminal-state handling
Risk Level: MediumVulnerable Code Snippet
markdown - `data.status` can be one of the following values: - `waiting`: queued - `processing`: running - `completed`: completed successfully - `failed`: failed - `timeout`: timed out - `data.reason`: provides additional context (e.g., `success` or error message) - When status is `completed`: - `data.result` is an array of output objects with generated URLs - Each result object contains `val` (internal path), `preview` (public HTTPS URL), and `status` (completion status) ## Standard Invocation Flow 1. Call `user/credits` to verify balance. 2. Call `effects-ghibli` with `data.images` and optional `data.ratio`, `data.batch`. 3. Extract `task_id`. 4. Poll `generation/result/{task_id}` every 3 to 5 seconds. 5. Stop when status is `completed` or `failed`. 6. Return output URLs from `data.result` when `completed`.Technical Analysis
The documented workflow requires polling every three to five seconds but provides neither a maximum attempt count nor an overall wall-clock deadline. Although the response contract explicitly identifies
timeoutas a possible task status, the invocation flow only treatscompletedandfailedas terminal states.Consequently, an implementing agent may continue sending authenticated requests when a task remains in
waitingorprocessing, returnstimeout, or produces an unexpected status. The guidance also does not specify termination behavior for repeated transport errors, malformed responses, or nonzero API response codes encountered during polling.Attack Path
- A generation task is created and a valid
task_idis returned. - The upstream service or affected task continually reports
waitingorprocessing, reports the documented but ...[truncated 970 chars]
- A generation task is created and a valid
- Remediation
View remediation
Remediation Suggestions
- Treat every documented terminal state, including
timeout, as a stopping condition. - Set both a maximum polling-attempt count and an overall wall-clock deadline.
- Replace fixed-interval polling with bounded exponential backoff and jitter, while respecting any server-provided
Retry-Afterguidance. - Stop safely on unknown statuses rather than polling indefinitely, and return a clear diagnostic containing the non-sensitive
trace_id. - Define strict limits for consecutive transport failures, malformed responses, and nonzero API response codes.
- Allow cancellation by the caller and ensure cancellation immediately stops further requests.
- Document explicit behavior such as: poll for no more than a configured duration, stop on
completed,failed, ortimeout, and fail closed on unsupported status values.
- Treat every documented terminal state, including
