CVE-2026-37600
Received Received - Intake
SQL Injection in Patient Appointment Scheduler Admin Panel

Publication date: 2026-04-14

Last updated on: 2026-04-14

Assigner: MITRE

Description
SourceCodester Patient Appointment Scheduler System v1.0 is vulnerable to SQL Injection in the file /scheduler/admin/appointments/view_details.php.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-14
Last Modified
2026-04-14
Generated
2026-05-07
AI Q&A
2026-04-14
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
sourcecodester patient_appointment_scheduler_system 1.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-89 The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

The Patient Appointment Scheduler System v1.0 by Sourcecodester has an SQL injection vulnerability in the file /scheduler/admin/appointments/view_details.php.

This vulnerability exists in the 'id' parameter of the URL query string, which interacts directly with the scheduler_db database.

An attacker can inject malicious SQL code through this parameter, for example by using payloads that exploit the updatexml function to trigger error-based SQL injection and extract database information.

This allows the attacker to execute arbitrary SQL commands, potentially leading to unauthorized access to or disclosure of sensitive data stored in the database.


How can this vulnerability impact me? :

This SQL injection vulnerability can allow an attacker to execute arbitrary SQL commands on the backend database.

  • Unauthorized disclosure of sensitive patient or appointment data.
  • Potential modification or deletion of database records.
  • Compromise of the integrity and confidentiality of the database.
  • Further exploitation leading to full system compromise depending on the database and server configuration.

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This SQL injection vulnerability can be detected by sending crafted HTTP requests to the vulnerable URL parameter and observing the responses for SQL error messages or unexpected data leakage.

Specifically, the vulnerability exists in the `id` parameter of the URL `/scheduler/admin/appointments/view_details.php`.

An example command using curl to test for the vulnerability is:

  • curl -i "http://<target>/scheduler/admin/appointments/view_details.php?id=1' and updatexml(1, concat(0x7e, (SELECT database()), 0x7e), 1)-- "

This payload uses the SQL function `updatexml` to trigger an error-based SQL injection that leaks the current database name in the HTTP response.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The SQL injection vulnerability in the Patient Appointment Scheduler System v1.0 allows an attacker to execute arbitrary SQL commands via the vulnerable `id` parameter. This can lead to unauthorized disclosure of sensitive data stored in the database.

Such unauthorized data disclosure can impact compliance with data protection regulations like GDPR and HIPAA, which require safeguarding personal and health information against unauthorized access.

Therefore, exploitation of this vulnerability could result in violations of these standards due to potential exposure of sensitive patient appointment data.


What immediate steps should I take to mitigate this vulnerability?

To mitigate the SQL injection vulnerability in the Patient Appointment Scheduler System v1.0, immediate steps include:

  • Sanitize and validate all user inputs, especially the 'id' parameter in the URL query string.
  • Use prepared statements or parameterized queries to interact with the database instead of directly embedding user input.
  • Restrict database user permissions to limit the impact of any potential injection.
  • Apply any available patches or updates from the vendor or source code provider.
  • Monitor logs for suspicious activity related to the vulnerable endpoint.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart