Summary
Lychee does not sufficiently limit password attempts when users unlock password-protected albums. A remote unauthenticated attacker who knows or obtains an album identifier may automate guesses and gain access to private photos if the album password is recovered.
Lychee does not sufficiently limit password attempts when users unlock password-protected albums. A remote unauthenticated attacker who knows or obtains an album identifier may automate guesses and gain access to private photos if the album password is recovered.
Affected context
The issue occurs in Lychee deployments where the album-unlock endpoint is reachable and password-protected albums can be identified. The unlock authorization path accepts repeated attempts without applying throttling, backoff, CAPTCHA, attempt counting, or account- or album-level lockout.
The issue occurs in Lychee deployments where the album-unlock endpoint is reachable and password-protected albums can be identified. The unlock authorization path accepts repeated attempts without applying throttling, backoff, CAPTCHA, attempt counting, or account- or album-level lockout.
Exploit preconditions
- Attack surface: The remote album-unlock API endpoint - Required access: No authentication is generally required, but the attacker
must know or obtain a valid album identifier
- Trigger point: Repeated password submissions to the album unlock operation - Why exploitation is possible: Each password guess is checked without
meaningful limits on frequency or cumulative failures
- Attack surface: The remote album-unlock API endpoint - Required access: No authentication is generally required, but the attacker
must know or obtain a valid album identifier
- Trigger point: Repeated password submissions to the album unlock operation - Why exploitation is possible: Each password guess is checked without
meaningful limits on frequency or cumulative failures
Why this happens
The underlying flaw is inadequate enforcement of limits around authentication attempts. The authorization flow permits any caller to submit guesses, while password verification is performed repeatedly without throttling, progressive delay, CAPTCHA, or lockout controls. This behavior maps to CWE-307, Improper Restriction of Excessive Authentication Attempts, because the application does not sufficiently constrain automated password guessing.
The underlying flaw is inadequate enforcement of limits around authentication attempts. The authorization flow permits any caller to submit guesses, while password verification is performed repeatedly without throttling, progressive delay, CAPTCHA, or lockout controls. This behavior maps to CWE-307, Improper Restriction of Excessive Authentication Attempts, because the application does not sufficiently constrain automated password guessing.
Potential impact
- An attacker may recover a weak or reused album password
- Unauthorized users could access private photo collections
- Private images may be copied, disclosed, or redistributed
- Repeated automated requests could consume application resources
- An attacker may recover a weak or reused album password
- Unauthorized users could access private photo collections
- Private images may be copied, disclosed, or redistributed
- Repeated automated requests could consume application resources
General mitigation guidance
Mitigation generally centers on making password verification resistant to automation. Common defensive patterns include applying per-album, per-account, and per-client rate limits; introducing progressive backoff after failures; enforcing bounded attempt counters and temporary lockouts; and using CAPTCHA or equivalent challenge mechanisms when suspicious activity is detected. Album identifiers and unlock endpoints should be treated as sensitive attack surfaces, while authorization should remain separate from request admission. Monitoring, alerting, and least-privilege access to stored photos can reduce impact if a password is compromised.
Mitigation generally centers on making password verification resistant to automation. Common defensive patterns include applying per-album, per-account, and per-client rate limits; introducing progressive backoff after failures; enforcing bounded attempt counters and temporary lockouts; and using CAPTCHA or equivalent challenge mechanisms when suspicious activity is detected. Album identifiers and unlock endpoints should be treated as sensitive attack surfaces, while authorization should remain separate from request admission. Monitoring, alerting, and least-privilege access to stored photos can reduce impact if a password is compromised.
How teams detect issues like this
Detection can include static and dynamic checks for password-verification endpoints that lack rate limiting, failure counters, delay, or lockout behavior. Code review should examine authorization handlers, request validators, and password-checking actions for unrestricted retry paths. Security testing can generate repeated failed attempts and verify that policy controls activate. Web-application monitoring can also flag bursts of unlock requests, repeated failures against one album, and distributed guessing across client addresses. Automated application-security review tools may help identify missing abuse-prevention controls.
Detection can include static and dynamic checks for password-verification endpoints that lack rate limiting, failure counters, delay, or lockout behavior. Code review should examine authorization handlers, request validators, and password-checking actions for unrestricted retry paths. Security testing can generate repeated failed attempts and verify that policy controls activate. Web-application monitoring can also flag bursts of unlock requests, repeated failures against one album, and distributed guessing across client addresses. Automated application-security review tools may help identify missing abuse-prevention controls.
