T09 · Insecure Skill Coding Practices
- Location
SKILL.md:571- Finding
Public Hosting Recommendation May Expose Sensitive Media
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:571-575
Vulnerability Type: Insecure handling of sensitive media
Risk Level: Mediummarkdown ### 10.4 Key limits and engineering tips - Supports common formats: WAV/MP3/AIFF/AAC/OGG/FLAC. - If the audio file is large, upload it to a publicly accessible URL first and pass the URL instead of Base64. - For very long audio, consider splitting into segments.Technical Analysis
The skill recommends placing large audio files at a publicly accessible URL before submitting that URL to the SkillBoss API Hub. Audio processed by this skill may include meeting recordings, speech, personal information, confidential business discussions, or other sensitive content.
Public accessibility is not required to implement remote media processing. A private object protected by a short-lived signed URL or an authenticated upload mechanism would provide the service with temporary access without exposing the object to the general public.
The recommendation contains no requirement for authentication, expiration, unguessable object names, access logging, encryption controls, or deletion after processing. It also does not warn that public objects may be discovered through leaked URLs, server logs, browser history, analytics, referrer headers, storage-bucket listings, or accidental indexing.
Attack Path
- A user follows the skill's recommendation when processing a large, sensitive recording.
- The user uploads the recording to storage configured for unrestricted public access.
- The public URL is passed to the SkillBoss API Hub and may also appear in local logs, request telemetry, shell history, or service-side records.
- An unauthorized party obtains or discovers the URL through a leak, exposed bucket listing, predictable object name, indexing, or shared logs.
- The unauthorized party downloads, retains, or redistributes the recording without possessing application ...[truncated 846 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the recommendation to make media publicly accessible.
- Prefer direct authenticated uploads to the media-processing service where supported.
- When URL-based retrieval is necessary, require private object storage and a short-lived, capability-limited signed URL.
- Configure signed URLs with the minimum practical lifetime, read-only access, and access restricted to one object.
- Use cryptographically random object names and disable bucket listing and public anonymous access.
- Delete uploaded media and revoke its signed URL immediately after processing.
- Warn users that prompts and media leave the local environment and are processed by a third party.
- Require explicit confirmation before transmitting recordings likely to contain confidential, personal, or regulated information.
- Document applicable retention, deletion, logging, and subprocessor policies.
- Add safeguards against URL disclosure in application logs, analytics, exception messages, and shell history.
A safer replacement would be:
markdown - For large audio files, keep the object private and provide a short-lived, read-only signed URL if the service supports URL retrieval. Do not expose confidential media through an unrestricted public URL. Delete the object or revoke access immediately after processing.