Note: stevesim84@gmail.com is an account thats been locked by KDP due to not using for many years so even after login it shows the screen for temporary lockout which is equivalent to logging into KDP for normal KDP accounts. Also the same password is used for Amazon login, so that means an attacker gets access to user's Amazon.com account

Introduction

While performing responsible research on Amazon's Kindle Direct Publishing (KDP) platform, I uncovered a critical authentication flaw that allowed unlimited password attempts without any account lockout. Despite having CAPTCHA and client-side encryption in place, the login endpoint at kdp.amazon.com failed to enforce the fundamental rule of limiting repeated password attempts.

This write-up details how the vulnerability was discovered, tested, and responsibly disclosed through the Amazon Vulnerability Research Program on HackerOne (Report #3388715) — and how the triage process exposed gaps in security validation and communication.​

The Discovery

While testing KDP's login flow for typical resilience controls, I noticed something interesting — after multiple invalid logins, there was no timeout or lockout behavior. Normally, enterprise-grade systems enforce user lockouts or exponential backoff after several failed attempts, in line with OWASP Authentication Guidelines and Amazon's internal security standards.

Curious, I wrote a Playwright-based automation script to simulate repeated login attempts. When executed, the script continued firing authentication requests indefinitely — CAPTCHA popped up, but did not stop the attempts from being processed server-side.

Technical Breakdown

Platform affected: Amazon Kindle Direct Publishing, (https://kdp.amazon.com) and Amazon (https://www.amazon.com/) Vulnerability: Missing Account Lockout (Improper Restriction of Authentication Attempts) Severity: Initially marked Critical (9.8) by the researcher; downgraded to None by triage Weakness: Inadequate rate-limiting and CAPTCHA validation Test method: Browser automation via Playwright and Chromium

The Playwright script automated repeated password attempts for a controlled dummy account. The result was surprising: the endpoint accepted endless credential submissions with only superficial CAPTCHA challenges. Even with client-side encrypted password processing, the platform never blocked or throttled login attempts.

Proof of Concept

1. Launch automated login sequence via Playwright targeting https://kdp.amazon.com
2. Submit multiple invalid passwords for the same account using the script attached as an image known as KDDPl.py

3. Observe system behavior — CAPTCHA rendered, but backend continued accepting password submissions

4. After sufficient iterations, successful login achieved without account lockout

5. Server continued accepting new attempts regardless of prior failures

The lack of lockout or progressive rate-limiting proved the endpoint's vulnerability to brute-force attacks. In a real-world scenario, an attacker could continuously test credentials and eventually compromise an account without triggering any defense.

Note: stevesim84@gmail.com is an account thats been locked by KDP due to not using for many years so even after login it shows the screen for temporary lockout which is equivalent to logging into KDP for normal KDP accounts. Also the same password is used for Amazon login, so that means an attacker gets access to user's Amazon.com account

Impact

This flaw allowed continuous, automated credential brute-forcing against KDP accounts. Potential outcomes included:

• Unauthorized access to author dashboards
• Data exposure of royalty or publishing metadata
• Unauthorized eBook publishing or content tampering
• Account takeover due to missing back-end validation

While CAPTCHA appeared to slow down basic scripts, its validation was purely cosmetic — it reloaded with each attempt, yet authentication requests kept being processed by the server.

Disclosure Timeline

• October 17, 2025: Reported vulnerability through HackerOne under Amazon's Vulnerability Research Program.
• October 18, 2025: Amazon acknowledged receipt and requested clarification about the number of requests sent.
• October 19, 2025: Triage downgraded severity from Critical to None citing "insufficient request volume (8–9 requests)".

Despite a clear reproduction of the authentication bypass, the issue remains unresolved at the time of publication.

Technical Analysis and Discussion

CAPTCHA and client-side encryption are useful deterrents but do not replace a server-enforced authentication throttle. The absence of lockout means the backend allows pattern-based credential enumeration, creating a scalable attack surface. Playwright's ability to handle CAPTCHA-challenged sessions demonstrated that automated brute forcing could proceed without interruption.

The flaw violates multiple security best practices, including:

• OWASP ASVS 2.1.7: "Account lockout after a defined number of failed logins."
• NIST SP 800–63B §5.2.2: "Limit consecutive failed authentication attempts."

By failing to implement any of these, KDP exposes a systemic control failure in a production environment.

Triage Outcome and Reflection

Amazon's triage decision concluded that the report "did not demonstrate practical exploitation," reasoning that only a small number of requests were tested. However, as demonstrated in the videos and follow-up response, the absence of lockout control is absolute, regardless of attempt volume. This discrepancy underscores a broader concern within coordinated vulnerability disclosure — evaluating findings by metrics rather than security fundamentals.

Responsible disclosure was followed in full, and all evidence (videos, scripts, and screenshots) were submitted as part of the report.​

Suggested Remediation

1. Implement progressive account lockout or temporary suspension after repeated failed login attempts.
2. Strengthen CAPTCHA validation to ensure server-side enforcement.
3. Add rate-limiting middleware and monitoring for repetitive failed logins.
4. Apply server-side password validation independent of client-side encryption.
5. Employ behavior-based threat detection for suspicious login patterns.

These recommendations directly align with OWASP Authentication and NIST digital identity guidelines.

Conclusion

This case illustrates how missing basic authentication controls — even with CAPTCHA and encryption — can leave high-value systems open to attack. While Amazon's security frameworks are generally robust, this flaw highlights that even global platforms can overlook foundational protections.

As researchers, our goal remains the same: to responsibly identify, document, and report vulnerabilities that could otherwise lead to real harm if left unaddressed.