I'll Have What He's Having: IDOR in Bagisto eCommerce

eCommerce platforms are complex beasts. They have to juggle inventory, payments, shipping, and the ever-demanding user experience. One feature designed to reduce friction is the "Reorder" button. It’s simple: you bought 50 pounds of coffee beans last month, and you want to do it again without searching for the product page.

Bagisto, a popular open-source Laravel eCommerce package, implements this handy feature. It takes an old order, grabs the items, and tosses them into your current cart. It’s convenient, efficient, and—until version 2.3.10—completely blind to who actually placed the original order. This feature turned into a massive privacy leak, allowing nosy neighbors or corporate spies to see exactly what other people were buying.

The vulnerability here is a textbook Insecure Direct Object Reference (IDOR). In the world of web security, IDOR is the "forgot to lock the bathroom door" of vulnerabilities. The application receives a request to access a specific object (in this case, an Order ID) and retrieves it from the database.

However, the application forgot the second, most critical step: checking if the person asking for the order actually owns it. Bagisto's code essentially said, "Oh, you want Order #1337? Sure, here it is!" without verifying if the requester was the customer who placed Order #1337. Because database IDs are often sequential integers, an attacker doesn't even need to be clever. They can just count up: 100, 101, 102, grabbing cart data for every single purchase on the platform.

Let's look at the PHP code in OrderController.php. This is a classic Laravel oversight. The developer used a repository method that finds a record by ID but doesn't scope it to the current user.

The Vulnerable Code:

public function reorder(int $id)
{
    // DIRECT LOOKUP: No ownership check!
    $order = $this->orderRepository->findOrFail($id);
 
    foreach ($order->items as $item) {
        // ... logic to add items to cart ...
    }
    // ...
}

See that findOrFail($id)? That is the root of all evil here. It queries the database for any order with that ID. If it exists, it returns it. It doesn't care if the logged-in user is Customer A and the order belongs to Customer B.

The Fixed Code:

public function reorder(int $id)
{
    // SCOPED LOOKUP: Must match ID AND current Customer ID
    $order = $this->orderRepository->findOneWhere([
        'customer_id' => auth()->guard('customer')->id(),
        'id'          => $id,
    ]);
 
    // If it's not yours, it doesn't exist to you.
    abort_if(! $order, 404);
 
    foreach ($order->items as $item) {
       // ...
    }
}

The fix is elegant and simple. Instead of just looking for $id, the query now mandates that the customer_id on the record must match auth()->guard('customer')->id(). If I try to access your order now, the database returns null, and the app throws a 404.

Exploiting this requires zero elite hacking tools. You just need a browser and a logged-in account. Here is how a competitor might use this to spy on sales trends or how a stalker might track a victim's purchases.

1. Authenticate: The attacker creates a legitimate account on the Bagisto store and logs in.
2. Target Selection: The attacker guesses an Order ID. If the site is busy, IDs might be in the thousands. Let's say the attacker's last order was #500. They want to see what Order #499 was.
3. The Request: The attacker sends a POST request (or visits the URL, depending on implementation specifics) to: POST /customer/account/reorder/499
4. The Execution: The server processes the ID 499, retrieves the order details (product names, quantities, variants), and adds them to the attacker's active shopping cart.
5. The Reveal: The attacker clicks on "My Cart." Suddenly, their cart is full of items they didn't select. "Oh, User 499 bought a 'Limited Edition GPU' and 'Gaming Chair'? Interesting."

This can be automated with a simple script to iterate from ID 1 to 10,000, scraping product popularity data or revealing sensitive purchases.

While this doesn't dump the database credentials or allow Remote Code Execution (RCE), the privacy impact is rated High (Confidentiality).

Business Intelligence Leak: A competitor could enumerate all orders to calculate precise sales volume, identify best-selling items, and map out order frequency.

Privacy Violation: In specific niches (medical supplies, adult industries, political merchandise), knowing what someone bought can be devastatingly sensitive. Since the attacker effectively "sees" the items by having them added to their cart, the confidentiality of the purchase history is completely breached.

Fraud Potential: While less direct, an attacker could potentially manipulate inventory availability by "reordering" massive quantities of items from other orders, locking up stock in their cart (depending on how the cart reservation system works).

If you are running Bagisto, you need to upgrade to version 2.3.10 immediately. The patch was released in late December 2025.

If you cannot upgrade the entire platform, you must patch packages/Webkul/Shop/src/Http/Controllers/Customer/Account/OrderController.php manually. Replace the findOrFail call with the composite findOneWhere check shown in the code section above.

Developer Lesson: Never trust an ID provided by the client. Whenever you look up a resource that belongs to a specific user, your database query must include the user's ID as a WHERE clause. Do not rely on checking ownership after fetching the object; scope the fetch itself.