T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:46
- Finding
- Reversible Metadata Exposes Source Calendar Details in Target Events## Vulnerability Details **File Location**: `SKILL.md:46-48, 71-82` **Additional Locations**: `SKILL.base.md:41-43, 66-77`; `config/sample.config.json:24-28` **Vulnerability Type**: Sensitive information stored using reversible encoding **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown - `metadata.format` (`SYNCV1`) - `metadata.encoding` (`base64url(json)`) - `metadata.fields`: `srcAccount,srcCalendar,eventId,start,end,title` ## Metadata Encoding Store source linkage in hold `description` as: - `SYNCV1:<base64url(JSON)>` JSON fields: - `srcAccount` - `srcCalendar` - `eventId` - `start` - `end` - `title` ``` The corresponding sample configuration is: ```json "metadata": { "format": "SYNCV1", "encoding": "base64url(json)", "fields": ["srcAccount", "srcCalendar", "eventId", "start", "end", "title"] } ``` ### Technical Analysis The skill instructs implementations to copy source calendar metadata into each target hold's description. The stored data includes the source account, source calendar identifier, source event identifier, event times, and event title. Base64url is an encoding mechanism, not encryption. Any party or integration with permission to read the target event description can decode the value without possessing a secret key. Consequently, marking the target event as private and giving it the generic summary `Busy` does not prevent disclosure through its description. This creates a confidentiality boundary violation when source and target calendars have different readers, integrations, administrators, retention policies, or account ownership. The target calendar receives substantially more source information than is necessary to represent an unavailable time interval. ### Attack Path 1. An attacker, delegated calendar user, administrator, or third-party integration obtains legitimate or compromised read access to the target calendar. 2. The party rea ...[truncated 1434 chars]
- Remediation
- ## Remediation Suggestions 1. Remove `title`, `srcAccount`, and `srcCalendar` from metadata stored in target event descriptions. 2. Replace raw source identifiers with a deterministic opaque identifier, such as an HMAC computed from the source account, calendar ID, and event ID using a locally managed secret. 3. Store only the minimum metadata required for idempotent reconciliation. Prefer an opaque linkage token and avoid duplicating event times if the target event already contains them. 4. If reversible metadata is operationally required, use authenticated encryption rather than base64url encoding. Keep the encryption key outside calendar data and configuration files, using an operating-system credential store or dedicated secret manager. 5. Ensure encrypted payloads use unique nonces and integrity protection, such as AES-GCM or ChaCha20-Poly1305. 6. Document explicitly that target event descriptions may be visible to calendar delegates, administrators, API clients, and connected integrations. 7. Add tests confirming that generated target holds do not contain plaintext or trivially decodable source titles, account addresses, calendar IDs, or event IDs. 8. Provide a migration routine that updates existing holds and removes legacy `SYNCV1` descriptions containing sensitive metadata.
