T09 · Insecure Skill Coding Practices
- Location
SKILL.md:31- Finding
Unauthenticated Email Account Enumeration
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:31-40
Vulnerability Type: Account enumeration through distinguishable authentication responses
Risk Level: MediumVulnerable Code
http POST https://ringez-api.vercel.app/api/v1/auth/check-email Content-Type: application/json {"email": "you@example.com"}Response:
new_user→ Continue to OTP verificationexisting_user→ Login with password
Technical Analysis
The documented unauthenticated endpoint accepts an arbitrary email address and explicitly reveals whether the address belongs to a new or existing user. This creates an account-enumeration oracle.
Authentication systems should normally return a uniform response regardless of whether an account exists. The registration status is not required to be disclosed to an unauthenticated client; the server can internally select the appropriate authentication flow while presenting the same external response.
The canonical API definition in
openapi.json:17-52confirms that the endpoint returns auser_statusvalue whose possible values arenew_userandexisting_user.Attack Path
- An attacker obtains or generates a list of potential victim email addresses.
- The attacker submits each address to
/api/v1/auth/check-email. - The attacker classifies addresses according to the
new_userorexisting_userresponse. - Confirmed Ringez users are selected for credential stuffing, password spraying, targeted phishing, or OTP abuse.
- If rate limiting and abuse controls are absent or insufficient, this process can be automated at scale.
Impact Assessment
The endpoint does not directly grant account privileges, but it discloses private account-registration state to unauthenticated callers. This improves the accuracy and efficiency of subsequent attacks against registered users.
The affected scope includes any email address that can be queried against the servi ...[truncated 128 chars]
- Remediation
View remediation
Remediation Suggestions
- Replace the distinguishable responses with a uniform message such as: “If this address is eligible, further instructions will be sent.”
- Internally determine whether login, registration, or OTP processing is appropriate without returning account-existence state.
- Apply per-IP, per-email, and device-level rate limits.
- Add progressive delays, anomaly detection, and temporary suppression for repeated enumeration patterns.
- Avoid response-time differences that could recreate the enumeration oracle as a timing side channel.
- Log suspected enumeration attempts without recording unnecessary plaintext personal data.
- Document generic error responses in both
SKILL.mdandopenapi.json.
