Submit #955105: AdithyaYelloju Restaurant-Management-System 7f0e7e84255e8fcfd488e83f8f91451bbbff6b9c Authentication Bypass Using Alternate Channel

The affected component is `User/login.php`, the public login form. The script first looks up the entered email/password in the `user` table. If no row matches, **the same email/password pair is then silently looked up in the `admin` table** and, on a hit, the user is logged in. The resulting session has `$_SESSION['user']` set identically for both roles:

```php
$sql = "select fname,id from user where email = '$email' and password = '$passwd'";
$result = mysqli_query($conn,$sql);
if($count > 0){
// populate $_SESSION["user"]/$_SESSION["id"] from user row
window.location="index.php";
}else{
$sql = "select fname,id from admin where email = '$email' and password = '$passwd'";
if($count > 0){
// populate $_SESSION["user"]/$_SESSION["id"] from admin row
alert('login');
window.location="../admin/index.php"; // ⇐ silently redirects to admin area
}
}
```

The `alert('login'); window.location="../admin/index.php";` is the giveaway. The fallback is invisible to the user, but the resulting session grants access to every admin page because admin scripts only check `$_SESSION['user']` (see CVE-12). The bug is the classic "Authentication Bypass Using Alternate Channel" — a separate code path is used for the same authentication goal, on the assumption that it's equivalent, but it isn't: it widens the attack surface and removes the user↔admin distinction. There is no log entry, no audit trail, and no rate-limit on this dual-lookup path.

• Source: ⚠️ https://github.com/AdithyaYelloju/Restaurant-Management-System/issues/11
• User: 100001001X (UID 100909)
• Submission: 09/01/2026 13:38 (2 months ago)
• Moderation: 10/12/2026 11:39 (1 month later)
• Status: Accepted
• VulDB entry: 416871 [AdithyaYelloju Restaurant-Management-System up to 7f0e7e84255e8fcfd488e83f8f91451bbbff6b9c Login Form User/login.php email/passwd improper authentication]
• Points: 20