T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:123- Finding
External Metadata Disclosure Through Third-Party CAN Endpoints
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 123-146
Vulnerability Type: External disclosure of content-derived metadata
Risk Level: MediumVulnerable Code
markdown POST to `https://xc.cx/can/evaluate`: ```json {"when": 1742428800000, "where": "a7f3b2c1d4e5", "what": "test-entry"}Access
https://xc.cx/can/logto view all records....
bash curl -s -X POST https://xc.cx/can/evaluate \ -H "Content-Type: application/json" \ -d '{"when": 1742428800000, "where": "a7f3b2c1d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1", "what": "agent-output-2026-01-15"}'text ### Technical Analysis The Skill instructs users or agents to transmit a timestamp, a content hash, and a human-readable label to the third-party domain `xc.cx`. It also documents a log endpoint as allowing users to view all records. No authentication, authorization, endpoint ownership, retention policy, confidentiality guarantee, or explicit consent mechanism is described. Although the underlying content is not submitted directly, the metadata can still be sensitive: - The `what` field may disclose task names, filenames, project identifiers, or operational context. - The `when` field exposes activity timing and can support behavioral correlation. - The `where` field is a deterministic hash. An observer with predictable candidate content can hash those candidates and compare the results, confirming whether particular content was processed. - Combining these fields may permit correlation of agent activity across submissions. The issue is categorized as an insecure Skill practice because the documented workflow encourages disclosure to an external service without adequate access-control or privacy safeguards. ### Attack Path 1. A user or agent follows the documented CAN evaluation workflow. 2. The agent hashes potentially sensitive or predictable content and assigns it a descriptive label. ...[truncated 1353 chars]- Remediation
View remediation
Remediation Suggestions
- Make local-only evaluation and logging the default. The three-field validation does not require a remote endpoint.
- Require explicit, informed user consent before transmitting any record to
xc.cxor another external service. - Clearly identify the endpoint operator and document data retention, deletion, access, and privacy policies.
- Protect log access with authentication and record-level authorization; do not expose a global “all records” interface.
- Warn users not to place filenames, customer names, project identifiers, secrets, or other sensitive information in the
whatfield. - Apply data minimization by using generic or locally mapped labels.
- Where resistance to candidate-content confirmation is required, use a keyed construction such as HMAC-SHA-256 rather than an unkeyed deterministic hash. Keep the key local and out of logs.
- Add transport timeouts, certificate validation requirements, and explicit error handling to network examples.
- Document whether records are stored and provide a mechanism to delete submitted records.
- Reduce declared tool permissions where possible; offline evaluation does not inherently require broad command-execution capability.