CVE-2026-109525 is a high severity missing authorization flaw (CVSS 7.3) in girishsaraf Online-Appointment-Booking-System, in the changebookingstatus.php handler. The record says an exploit is public and the project has not responded. It is a rolling release project with no fixed version, so treat the software as unfixed.
What's affected
The record is the only source we relied on for this CVE. It says the product, girishsaraf Online-Appointment-Booking-System, is affected up to commit f427b4757128ca253d33d0cc4e87bbb9c999a4d5. Because the project uses a rolling release system, the record says version information for affected or updated releases is not disclosed. We did not fetch the project page or the issue, so we cannot say whether a fix has landed since the record was written. Check the repository and the issue the record lists.
The weaknesses are CWE-862, missing authorization, and CWE-863, incorrect authorization. The vector is network reachable, low complexity, no privileges and no interaction, with low impact on each of confidentiality, integrity and availability.
The record says the flaw is in the submit2 handler of the file changebookingstatus.php, and that manipulating the username, timestamp and status array arguments leads to missing authorization. It says the exploit is publicly available and might be used, and that the project was told early through an issue report and has not responded.
Note that this is not the same as the CISA Known Exploited list. The record's KEV flag is false.
How to check if you're exposed
Start by identifying whether you run this application. Search your web roots for the file name:
find /var/www -name changebookingstatus.php 2>/dev/null
If it exists, find the commit your deployment was taken from, with git log -1 if the folder is a clone, and compare it with the commit in the record.
Then review who can reach the page. A booking status page that changes records should only accept calls from signed in staff. Check your web server logs for requests to that file from addresses you do not recognise, and check booking records for statuses that changed without a matching staff action.
Because the project is small, also look for local modifications. Many deployments are copied and edited, so your copy may differ from upstream.
What to do now
- Check the project repository and issue tracker for a fix, and apply it if one exists.
- If the application is public, put it behind authentication at the web server or proxy level, or take it offline until fixed.
- Add your own server side check to the handler so only authenticated staff can change a booking status.
- Review recent booking status changes for entries that do not match staff activity.
- If the project stays unmaintained, plan a move to a maintained scheduling product.
Why it matters
Missing authorization is a failure to ask a simple question: is this caller allowed to do this? A handler that accepts a request and changes a record without checking who sent it gives the power to every visitor who finds the address.
Small open source projects are the typical home of this bug. They are written to work, not to defend, and nobody reviews them for access control. When a researcher files an issue and the maintainer is silent, as the record says happened here, users are left holding unfixed code with a public exploit.
The impact here is limited, which is why the score is 7.3 and not higher: low confidentiality, integrity and availability effects. For a clinic or salon, though, altered appointment status can mean missed customers. The lesson for anyone adopting an open source project is to check that it has active maintenance before running it on a public address.
Quick check
Is there a patched version?
The record says version information is not disclosed because the project uses rolling releases, and that the project has not responded. Check the repository.
Is it on the CISA Known Exploited list?
No. The record's KEV flag is false. The record does say a public exploit exists.
Sources
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan to see which of your packages carry known CVEs.
Last reviewed: 18 October 2026.
