CVE-2025-6767: sfturing hosp_order SQL Injection Vulnerability

CVE-2025-6767 Overview

CVE-2025-6767 is a SQL injection vulnerability in the sfturing/hosp_order hospital order management application. The flaw resides in the findDoctorByCondition function within DoctorServiceImpl.java. Attackers manipulate the hospitalName parameter to inject arbitrary SQL into backend database queries. The vulnerability is remotely exploitable and requires only low-privileged authenticated access. The project follows a rolling release model, so no versioned fix identifier is available. The affected commit range extends up to 627f426331da8086ce8fff2017d65b1ddef384f8. A public disclosure exists via the project's GitHub issue tracker.

Critical Impact
Authenticated remote attackers can inject arbitrary SQL through the hospitalName parameter, potentially exposing or modifying hospital, doctor, and patient order records stored in the backend database.

Affected Products

sfturing hosp_order (hospital order management application)
Component: DoctorServiceImpl.java, function findDoctorByCondition
All commits up to 627f426331da8086ce8fff2017d65b1ddef384f8 (rolling release)

Discovery Timeline

2025-06-27 - CVE-2025-6767 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-6767

Vulnerability Analysis

The flaw is a SQL injection issue classified under CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component. The findDoctorByCondition method in DoctorServiceImpl.java accepts a hospitalName argument and passes it into a SQL statement without proper parameterization or sanitization. An authenticated remote attacker can embed SQL metacharacters inside hospitalName to alter query logic. Successful exploitation can yield unauthorized data retrieval, record modification, or enumeration of underlying schema objects. The project's rolling release model means no fixed version string identifies a patched build, complicating downstream patch tracking.

Root Cause

The root cause is direct concatenation or unsafe interpolation of user-supplied input into a SQL query inside findDoctorByCondition. The service layer does not use prepared statements or bind parameters for the hospitalName field. Any string containing SQL control characters is interpreted as query syntax by the database driver.

Attack Vector

The attack is executed over the network against the application endpoint that invokes findDoctorByCondition. An attacker with low-level credentials submits a crafted hospitalName value containing SQL payloads such as boolean conditions, UNION SELECT clauses, or stacked statements. No user interaction is required beyond the attacker's own request. Public disclosure of the issue appears in the GitHub Issue Report and the VulDB entry #314081.

// No verified exploit code is published. The vulnerability stems
// from unsanitized use of the hospitalName parameter inside the
// SQL query constructed by findDoctorByCondition in
// DoctorServiceImpl.java. See the referenced advisories for details.

Detection Methods for CVE-2025-6767

Indicators of Compromise

HTTP requests to endpoints invoking findDoctorByCondition containing SQL metacharacters such as ', --, ;, /*, or UNION inside the hospitalName parameter.
Application or database logs showing malformed queries, syntax errors, or unusually long responses tied to doctor-search operations.
Unexpected SELECT activity against doctor, hospital, or user tables originating from the application's database account.

Detection Strategies

Deploy a web application firewall rule to flag SQL injection patterns on request parameters sent to the hospital/doctor search endpoints.
Enable database query logging and alert on queries referencing hospitalName that include SQL keywords or tautologies such as OR 1=1.
Perform static analysis on DoctorServiceImpl.java to locate string concatenation involving JDBC query strings and the hospitalName argument.

Monitoring Recommendations

Monitor authentication logs for low-privileged accounts generating high volumes of search requests to the vulnerable endpoint.
Correlate application error logs with database error responses to surface failed injection attempts that precede successful ones.
Track outbound data volumes from the application tier to identify potential bulk record exfiltration.

How to Mitigate CVE-2025-6767

Immediate Actions Required

Audit DoctorServiceImpl.java and replace dynamic SQL construction involving hospitalName with parameterized queries using JDBC PreparedStatement or MyBatis #{} bindings.
Restrict access to the hospital/doctor search functionality to the minimum set of authenticated roles that require it.
Rotate database credentials used by the application if injection activity is suspected in logs.

Patch Information

The sfturing/hosp_order project ships via rolling releases, so no formal patched version is published. Track remediation progress in the GitHub Issue Report and apply any merged commits that convert the vulnerable query to a parameterized form. Rebuild and redeploy the application from the latest main branch after confirming the fix.

Workarounds

Place a reverse proxy or WAF in front of the application with signatures that block SQL metacharacters in the hospitalName request parameter.
Enforce server-side input validation that limits hospitalName to an allow-list of expected characters, such as letters, digits, spaces, and hyphens.
Apply the principle of least privilege to the database account used by the application, revoking rights to tables and operations not required by the service.

bash

# Example input validation using a strict allow-list regex (Java pseudocode)
# if (!hospitalName.matches("^[\\p{L}0-9 .-]{1,64}$")) {
#     throw new IllegalArgumentException("Invalid hospitalName");
# }
# Prefer PreparedStatement over string concatenation:
# PreparedStatement ps = conn.prepareStatement(
#     "SELECT * FROM doctor WHERE hospital_name = ?");
# ps.setString(1, hospitalName);