Online Appointment Booking System EUVD-2026-92897

Exploitation requires an authenticated low-privilege session (CVSS PR:L) plus the ability to reach the book.php endpoint of the Booking Handler component over the network, and the attacker must supply malicious input in the Doctor or appointment request parameter. Limiting factors: a valid account is needed (not unauthenticated), impact is partial (VC:L/VI:L/VA:L) rather than full database takeover, and there is no fixed version available because the project ships as an unversioned rolling release with an unresponsive maintainer. No special non-default configuration is indicated - the vulnerable parameter appears to be part of the standard booking workflow.

This is a genuine but low-to-moderate priority issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes network-reachable, low-complexity exploitation requiring low-level authentication (PR:L), with limited partial impact across confidentiality, integrity, and availability (VC:L/VI:L/VA:L) and no scope change - yielding a modest 5.3 (Medium). A CWE-89 SQL injection would often warrant higher impact, but the CVSS author rated all impacts Low, suggesting constrained data exposure rather than full database compromise or RCE. Exploit maturity is E:P (Proof-of-Concept), consistent with the publicly available POC on the GitHub issue tracker. No EPSS score was provided in the input, and the vulnerability is NOT in CISA KEV, so there is no evidence of active exploitation - exploitation status is 'publicly available exploit code exists', which must not be conflated with in-the-wild use. The combination of an obscure, unmaintained open-source project (vendor has not responded per the report), an authentication requirement, and only partial impacts makes this a low real-world priority despite being a verified, publicly-exploitable SQLi.

An authenticated user with low privileges submits a crafted value in the Doctor or appointment parameter to book.php, injecting SQL that the Booking Handler executes against the backend database. Because a public POC exists (linked from the project's GitHub issue tracker) and the attack is remote over the network, an attacker can reproduce it to read or tamper with limited database records. The PR:L requirement means the attacker must first hold a valid low-privilege account.