CVE-2023-38050 is a critical severity (CVSS 9.1) broken object level authorization flaw in the Easy!Appointments webhooks API. A low privileged user can read, change or delete the webhooks of any user, including the admin. The record names no fixed version, so upgrade Easy!Appointments and confirm the fix in the project's release notes.
What's affected
The record names the Easy!Appointments scheduler (alextselegidis/easyappointments) and gives no version limits, so we cannot say which releases are affected. It scores the flaw 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:L. That is a network attack by a user with a low privilege account, no user interaction, and a changed scope, with high confidentiality impact and low integrity and availability impact.
The record says the GET, PUT and DELETE operations on the webhooks API resource accept an identifier and act on it without checking that the caller may touch that object. The weakness is CWE-639 (authorization bypass through a user-controlled key), an authorization bypass through a user controlled key. The related Easy!Appointments records, CVE-2023-38047 to CVE-2023-38055, describe the same pattern on other resources.
The only reference in the record is the project repository, and its front page does not carry a security advisory or a fixed version that we could confirm. The record does not flag CISA KEV and nothing we read says the flaw is exploited in the wild. Treat the fixed version as unconfirmed and check the project releases and its security policy.
How to check if you're exposed
Start with the version your installation runs. The Easy!Appointments admin area and your deployment notes show it, and a git checkout shows the tag. Compare it with the newest release on the project page, because the record does not name a fixed one.
Then check how the API is exposed. The API is separate from the booking pages, so look at your web server and proxy configuration for who can reach it, and whether the API is switched on at all:
grep "api/v1" /var/log/nginx/access.log | head
Adjust the log path to your web server, and note the API path may differ in your setup. Also search access logs for API requests from accounts that should not use it, for example customer or secretary logins calling the webhooks endpoint with identifiers that belong to other people.
What to do now
- Find every Easy!Appointments installation you run, and note version and owner.
- Upgrade to the latest release and read the changelog for authorization fixes. Confirm the fixed version with the maintainers if the notes are unclear.
- Until you can upgrade, limit who can reach the API at the proxy, or block the API path at the proxy if you do not use it.
- Review the webhooks data for changes you did not expect, and review accounts, since this class of flaw can change the admin and provider records too.
- Add API authorization tests to your own test plan, so object ownership checks are verified for every resource.
Why it matters
BOLA, short for broken object level authorization, tops the OWASP list of API risks for a reason. The API checks that you are logged in, then trusts the identifier you send. If it never asks whether that object belongs to you, any signed in user can walk through other people's records by changing the number.
For a scheduling system that matters more than it sounds. Appointments hold names, contacts and times, and providers, admins and settings control who can log in and what the system does. The record rates this one critical because a low privilege user can reach data and functions that belong to others. The fix is an ownership or role check on every read, update and delete.
Quick check
What does BOLA mean?
It means the API acts on an object identifier from the caller without checking that the caller is allowed to access that object. Changing the identifier is enough to reach someone else's data.
Is there a fixed version?
The record does not name one and the project page we could read does not either. Upgrade to the newest release and check the project's release notes.
Sources
Last reviewed: 19 October 2026.
