T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:38- Finding
Excessive Wiki-Wide Administrative Authorization
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 38–41 and 130–135
Vulnerability Type: Excessive privilege through inherited group membership
Risk Level: HighVulnerable Snippet
markdown 1. **权限穿透**：空间创建后机器人默认无权维护。**强烈建议使用“群组授权法”**： - 创建一个包含机器人的群组。 - 在知识库【设置】-【成员设置】中，添加该群组为“管理员”。 - 这样机器人即可通过群组身份获得该空间内所有页面的操作权。The same recommendation is repeated later:
markdown **空间授权的“群组法”穿透 (Critical)：** * **风险**：由于飞书租户安全策略，机器人通过 API 直接创建“顶级知识空间”往往会报权限错误 (403)。此外，即便有了空间，机器人默认对空间内的节点也可能无操作权。 * **对策**：教程必须强调 **“群组授权最佳实践”**： 1. 手动创建一个包含机器人的【群组】。 2. 在 Wiki 空间设置中，将该群组添加为【管理员】。 3. 这样机器人即可通过群组身份获得空间内所有页面的创建、移动和编辑权限。Technical Analysis
The Skill recommends adding the bot to a group and assigning that group the Wiki-space administrator role. This causes the bot to inherit broad administrative access to every page in the space rather than receiving only the permissions necessary for a specific task.
The document explicitly frames this technique as permission traversal and uses it to overcome the bot's default access restrictions. The resulting authorization is not limited to a designated subtree, operation, or temporary workflow. This violates least-privilege principles.
The risk is compounded by the Skill's documented governance capabilities, which include moving, renaming, and deleting existing Wiki content. A compromised bot identity, unsafe agent instruction, operator mistake, or unauthorized use of its tenant token could therefore affect unrelated organizational content.
Attack Path
- An administrator follows the Skill's recommendation and creates a group containing the bot.
- The administrator assigns that group the administrator role for a Wiki space.
- The bot inherits space-wide privileges, including access to pages unrelated to its immediate task.
- An attacker compromises the bot or its tenant access token, or induces the agent to perform an unintended privileged operation.
- The bot us ...[truncated 1085 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not place the bot in a group holding space-wide administrator privileges.
- Grant the bot access only to the specific Wiki space, subtree, or nodes required by its defined workflow.
- Use a dedicated service identity with narrowly scoped API permissions instead of a broadly privileged shared group.
- Separate read, create, edit, move, and delete capabilities. Do not grant destructive permissions unless they are strictly required.
- Require explicit human confirmation for node deletion, cross-space movement, bulk modification, and other high-impact operations.
- Implement an allowlist of authorized space IDs and parent node tokens in the integration layer.
- Validate that every requested operation remains within the approved space and subtree before making an API call.
- Maintain audit logs for privileged operations and alert on bulk edits, unexpected moves, deletion attempts, or access outside approved nodes.
- Establish a documented revocation process that removes the bot from privileged groups and invalidates its tenant token when access is no longer required.
- If broad access is operationally unavoidable, isolate the bot in a dedicated Wiki space containing no unrelated or sensitive material.