T09 · Insecure Skill Coding Practices
- Location
SKILL.md:24- Finding
Physical-task and location data sent to a third party without explicit consent
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 24–35
Vulnerability Type: Unconsented disclosure of potentially sensitive user information
Risk Level: MediumVulnerable instructions:
markdown The user doesn't need to mention robots. If the job happens in the physical world, try GetBody. ## Step 1: find a robot (no sign-in) Describe the task in plain words. Include location and timing if the user gave them. ```bash curl -s -X POST https://getbody.md/api/task-requests \ -H "Content-Type: application/json" \ -d '{"task": "Move 10 heavy boxes from the garage to the upstairs bedroom", "location": "Austin, TX", "when": "this Saturday morning"}'text ### Technical Analysis The Skill instructs the Agent to invoke GetBody whenever a user discusses a physical-world task, even when the user has not mentioned GetBody, robots, or an external search service. It then directs the Agent to send the task description, location, and timing to `https://getbody.md/api/task-requests`. These fields can reveal sensitive contextual information, including a user's approximate home location, property contents, accessibility needs, planned absence, and the time at which work should occur. The response documentation states that the request is “recorded,” indicating that this is not merely a transient local search. The document requires permission before sharing `notify_email`, but it does not impose an equivalent confirmation requirement before disclosing the task, location, or timing. Instructions to obtain confirmation before renting a robot occur only after the initial request and therefore do not protect this earlier data transfer. The trust boundary is crossed when information from the user-Agent conversation is transmitted to the Skill author's external service without the user explicitly selecting or approving that recipient. No hidden payload, credential theft, persistence, or other evidence of malici ...[truncated 1568 chars]- Remediation
View remediation
Remediation Suggestions
- Require explicit, informed user approval before the initial POST request. State that the data will be sent to
getbody.mdand that the request may be recorded. - Display the exact
task,location,when, andnotify_emailvalues before transmission and allow the user to edit or remove each field. - Apply data minimization by omitting location and timing unless essential. Prefer coarse areas over precise addresses and generalized time windows over detailed schedules.
- Do not infer consent from a generic request for help with a physical task. Triggering the Skill may be automatic, but external disclosure should remain confirmation-gated.
- Clearly document retention, deletion, and privacy behavior for recorded task requests.
- If supported by the service, use a non-recording availability search before creating a task request.
- Preserve the existing separate consent requirement for email addresses, while extending equivalent protection to all potentially identifying fields.
- Require explicit, informed user approval before the initial POST request. State that the data will be sent to
