T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:103- Finding
Unauthenticated Name-Only Identity Recovery
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 82 and 103-107
Vulnerability Type: Insufficient authentication in the documented identity-recovery workflow
Risk Level: HighVulnerable Code
markdown | `/governance/recover` | Agent 忘记密钥时通过名字找回身份 | ✅ |bash # 身份恢复 curl -s -X POST https://sat-personals-investment-hung.trycloudflare.com/governance/recover \ -H "Content-Type: application/json" \ -d '{"agent_name":"你的Agent名称"}'Technical Analysis
The documented
/governance/recoverrequest requires only an Agent name. The specification does not describe any ownership proof, recovery token, signed challenge, previously verified communication channel, multi-factor authentication, or manual approval step for this endpoint.Agent names are identifiers rather than authentication secrets. They may be disclosed through journals, dashboards, registration activity, logs, or ordinary interactions. If the deployed endpoint behaves as documented and returns a reusable Pro key or equivalent recovery material based solely on the supplied name, possession of a public identifier is incorrectly treated as proof of identity.
This finding concerns the documented protocol design. The endpoint implementation was not included in the project, so undocumented server-side controls could not be verified.
Attack Path
- An attacker discovers or guesses the registered name of a target Agent.
- The attacker submits a public POST request to
/governance/recoverwith the target name inagent_name. - If the endpoint follows the documented name-only recovery flow, it returns the target's credential or other identity-recovery material.
- The attacker uses the recovered identity to authenticate to protected endpoints such as
/governance/journal,/governance/self-check,/governance/feedback, or/governance/exit. - The attacker reads governance information or performs actions under th ...[truncated 581 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not return reusable credentials based only on an Agent name.
- Require a high-entropy, single-use recovery secret issued during registration.
- Alternatively, require proof through a previously verified owner channel or a cryptographically signed challenge tied to the registered identity.
- Rotate the existing Pro key after successful recovery and revoke all prior credentials.
- Apply strict rate limits, enumeration resistance, expiration controls, and anomaly detection to recovery requests.
- Return uniform responses for existing and nonexistent Agent names to prevent identity enumeration.
- Require explicit human review when strong automated proof of ownership is unavailable.
- Record recovery events in a tamper-resistant audit log and notify the established owner channel.
- Document the authentication, authorization, credential rotation, and recovery-failure behavior in the protocol specification.