| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| alextselegidis/easyappointments | composer | <= 1.5.1 |
The vulnerability allows creating appointments with excessively long durations, causing a DoS. The provided commit (74633b60f28bdef3cc9f905c0599cef121fee32b) addresses this by ensuring the appointment's 'end_datetime' is always calculated based on the selected service's duration.
Appointments_api_v1::calculate_end_datetime was removed. This function previously calculated the end time using $end->add(new DateInterval('PT' . $duration . 'M'));. If $duration was not properly constrained (e.g., a service could be configured with an extremely large duration, or the value was otherwise manipulable), this function would produce an excessively long appointment, which is the core of the vulnerability. This function is therefore identified as vulnerable.Appointments_api_v1::store method called this removed calculate_end_datetime function. It's an API endpoint for creating appointments and thus an entry point for exploitation.Booking::register method in Booking.php had the correct end_datetime calculation logic added. This implies that before the patch, it was also susceptible, likely because it either accepted user-provided end times without sufficient validation against service duration or had a missing/flawed internal calculation for the end time.
These three functions are directly involved in the appointment creation process where the flawed duration logic (or lack of validation) existed, making them the key functions that would appear in a runtime profile during exploitation.Confidence for all identified functions is high due to direct evidence in the patch and alignment with the vulnerability description. The patch moves the calculate_end_datetime logic to the Appointments_model and ensures it's consistently used, which strongly indicates the previous locations/methods of calculation or input handling were flawed.
The Appointments_model::calculate_end_datetime is the new, fixed function, not the vulnerable one. The vulnerability lies in the absence of this correct calculation or the presence of a flawed one in the controller methods before the patch.