EasyAppointments - v1.5.0 - Password Brute Force

By 0xhamy 04:48 PM - October 22nd 2025
Type software
Product Environment web
Product Name EasyAppointments
Product Vendor Alex Tselegidis
Product Version 1.5.0
Product Link https://github.com/alextselegidis/easyappointments
Vulnerability Name Password Brute Force
Severity Critical
CVSS String CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CVSS Score 9.1
CVE ID CVE-2024-57602
Vendor Acknowledgement No
Affected digital Assets 1293
Affected Users 129300
Date of Reporting Dec 22, 2024
PoC Exploit https://gist.github.com/0xHamy/fd3e1d95e114eddcfd91961032eec7fd
Credit 0xhamy

Description

EasyAppointments 1.5.0 allows brute-force attacks against the admin login endpoint /index.php/login/validate due to insufficient rate-limiting.
Although the server applies rate limiting, it can be trivially bypassed by inserting short pauses between bursts of password attempts (e.g., sleeping after every 8 tries). This enables sustained, large-scale credential guessing against administrator accounts.

Vulnerability Details

The login endpoint issues HTTP 429 after several rapid failures, but the counter/window is lax enough that waiting ~10 seconds after 8 attempts resets enforcement.
With this cadence, an attacker can make ~69,120 guesses per 24 hours against a single account:

  • 86,400 seconds/day ÷ 10-second sleeps = 8,640 cycles/day
  • 8 guesses/cycle × 8,640 cycles ≈ 69,120 guesses/day

This materially aids credential stuffing/dictionary attacks and increases the likelihood of admin account compromise, especially where passwords are guessable or reused.


Steps to Reproduce

  1. Obtain the proof-of-concept script.
    Use the provided gist to automate attempts with sleeps:
    https://gist.github.com/0xHamy/fd3e1d95e114eddcfd91961032eec7fd

  2. Run the script against the admin login endpoint.
    Point it at:

    /index.php/login/validate
    

    Observe that after an initial 429, inserting a 10-second sleep after every 8 attempts allows guessing to continue indefinitely within the rate limit.

  3. Measure throughput.
    Confirm sustained attempts (~69k/day) and absence of escalating lockouts or IP/account blocks.


Recommendation

  • Enforce adaptive rate-limiting per account/IP/device (token bucket + exponential backoff; longer lockouts on repeated failures).
  • Introduce secondary controls: CAPTCHA after few failures, mandatory 2FA for admins, and IP reputation/velocity checks.
  • Harden feedback: uniform error messages and server-side tracking across IPs/agents to prevent trivial resets.
  • Add alerting on excessive failures/guessing patterns and temporarily disable targeted accounts pending verification.