CVE-2022-39180 is a critical vulnerability discovered in the College Management System v1.. This bug relates to a classic but still dangerous web application weakness: SQL Injection (SQLi). In this long read, we’ll break down what went wrong, show you real code examples, give you working exploit code, and provide you with the references to learn more.

What’s College Management System v1.?

This is an open-source PHP and MySQL application used by small schools or colleges to organize student, faculty, and class data. Rather than inventing fancy frameworks, it’s built the traditional way, using simple PHP and direct MySQL queries.

Where’s the Problem? (login.php SQLi)

The main issue is in login.php, the module where students and admins log in. The developer failed to sanitize user input (the username and password fields). This means you can inject SQL commands directly into those fields and control the database query.

Here’s a simplified version of the vulnerable code in login.php

<?php
if(isset($_POST['submit'])){
    $username = $_POST['username'];
    $password = $_POST['password'];
    $query = "SELECT * FROM users WHERE username='$username' AND password='$password'";
    $result = mysqli_query($conn, $query);
    if(mysqli_num_rows($result) == 1){
        // Login successful
    } else {
        // Login failed
    }
}
?>

See the problem? User input goes straight into the SQL query, wrapped in quotes, but without any escaping or prepared statements.

- In the Username field, enter

  ' OR 1=1 #

The query becomes

SELECT * FROM users WHERE username='' OR 1=1 # ' AND password='anything'

The # symbol is a MySQL comment: everything after it is ignored. So, OR 1=1 always returns true. This means anyone can bypass authentication and log in.

#### How-to in Burp Suite/Browser

The ability to steal, edit, or delete all information in the system

- The chance to run more dangerous SQL code (like UNION attacks, extracting passwords, or even wiping the whole database)

How To Fix It

The safest solution is prepared statements (also called parameterized queries). Here’s a secure version of that PHP code:

<?php
if(isset($_POST['submit'])){
    $username = $_POST['username'];
    $password = $_POST['password'];
    $stmt = $conn->prepare("SELECT * FROM users WHERE username=? AND password=?");
    $stmt->bind_param("ss", $username, $password);
    $stmt->execute();
    $result = $stmt->get_result();
    if($result->num_rows == 1){
        // Login success
    } else {
        // Login failed
    }
}
?>

Even better, passwords should be hashed—but that’s another story.

References

- CVE-2022-39180 on NIST
- Original Exploit DB entry
- OWASP SQL Injection Cheat Sheet
- Official College Management System v1. Download

Conclusion

Even new apps, if not carefully coded, can have ancient vulnerabilities. CVE-2022-39180 is a textbook case: never put user input straight into SQL queries. For students learning web development: always, always use prepared statements. For admins running this system: patch now, and check your logs for unusual activity.

Timeline

Published on: 11/17/2022 23:15:00 UTC
Last modified on: 11/18/2022 18:28:00 UTC