Submit #955125: AdithyaYelloju Restaurant-Management-System 7f0e7e84255e8fcfd488e83f8f91451bbbff6b9c Authorization Bypass Through User-Controlled SQL Primary Key

The affected components are `User/cancel.php`, `User/cancel_t.php`, `admin/delete1.php`, `admin/delete1_m.php`, `admin/delete_user1.php`, `admin/approve.php`, `admin/notapprove.php`, `admin/approvet.php`, and `admin/notapprovet.php`. Every endpoint takes a `$_GET['id']` and uses it as the SQL primary key without any ownership check:

```php
// User/cancel.php
$id = $_GET["id"];
mysqli_query($conn,"delete from order_list where id='$id'");

// User/cancel_t.php
$id = $_GET["id"];
mysqli_query($conn,"delete from t_order where id='$id'");

// admin/approve.php
$id = $_GET["id"];
mysqli_query($conn,"update order_list set status='yes' where id='$id'");
```

No `$_SESSION['id']` is involved. The server has the victim's `uid` available (it lives in `$_SESSION['id']` after login, see `User/login.php`), and the `order_list`/`t_order` rows include a `uid`/`uname` column, but neither check runs. The result is a textbook "Authorization Bypass Through User-Controlled SQL Primary Key" (CWE-639): any caller can address any row in the table. Even logged-in users can address rows they don't own; **unauthenticated callers reach the same rows** because there is no session check (CVE-13). Verified: Alice's order id=4 and Bob's order id=5 were both deletable by an anonymous caller; the same caller mass-updates `status='yes'` on every order. Most of these endpoints also have the SQL injection from CVE-04/CVE-06, so the parameter is doubly dangerous.

• Source: ⚠️ https://github.com/AdithyaYelloju/Restaurant-Management-System/issues/13
• User: 100001001X (UID 100909)
• Submission: 09/01/2026 13:47 (2 months ago)
• Moderation: 10/12/2026 11:39 (1 month later)
• Status: Accepted
• VulDB entry: 416873 [AdithyaYelloju Restaurant-Management-System up to 7f0e7e84255e8fcfd488e83f8f91451bbbff6b9c Order Management mysqli_query id authorization]
• Points: 20