T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:63
- Finding
- Calendar setup requests unrelated task and employee-directory privileges## Vulnerability Details **File Location**: `SKILL.md:63-77` and duplicated verbatim in `README.md:63-77` **Vulnerability Type**: Excessive permission request and least-privilege violation **Risk Level**: Medium **Vulnerable configuration:** ```json { "scopes": { "tenant": [ "calendar:calendar", "calendar:calendar:readonly", "task:task:write", "task:task:read", "contact:user.employee_id:readonly" ], "user": [ "calendar:calendar", "calendar:calendar:readonly", "task:task:write", "task:task:read" ] } } ``` ### Technical Analysis The section is presented as a procedure for enabling calendar permissions, but its recommended configuration also requests tenant-level and user-level task read/write privileges. It additionally requests tenant-level access to employee identifiers. These capabilities are not justified by the documented calendar troubleshooting objective. In particular, `task:task:write` permits modification rather than merely observation, while `task:task:read` and `contact:user.employee_id:readonly` expand access into task and employee-directory data. The simultaneous inclusion of full calendar access and read-only calendar access also indicates that the permission set has not been minimized according to the actual operation required. The artifact contains documentation rather than executable application code, so it does not itself exercise these permissions. The risk arises when a user follows the instructions, imports the supplied scope configuration, approves it, and connects an application capable of using the granted Feishu authorization. ### Attack Path 1. An administrator follows the calendar permission instructions in `SKILL.md` or `README.md`. 2. The administrator imports the supplied JSON into the Feishu application permission manager. 3. The application is approved and published with task read/write and ...[truncated 1203 chars]
- Remediation
- ## Remediation Suggestions 1. Remove `task:task:write`, `task:task:read`, and `contact:user.employee_id:readonly` from the calendar permission example unless a documented feature explicitly requires each scope. 2. Use only `calendar:calendar:readonly` when the integration merely reads calendar information. 3. Request `calendar:calendar` only when the application must create, update, or delete calendar resources. 4. Separate calendar, task, and contact capabilities into independent, opt-in permission examples so administrators do not grant unrelated privileges as one bundle. 5. Document the exact operation enabled by every requested scope, whether it is tenant-level or user-level, and why a narrower scope is insufficient. 6. Add a warning that administrators should review requested scopes before approval and should not grant optional write privileges by default. 7. Apply the same corrections to `README.md`, which duplicates the affected configuration. 8. Review already deployed applications and revoke unnecessary task, contact, or write-capable calendar scopes. Rotate application credentials if there is evidence that an overprivileged integration was compromised.