Shopping for Shells: Bagisto Reporting SSTI to RCE

Bagisto is built on Laravel, a PHP framework known for its robust security defaults. Laravel's Blade templating engine typically handles output encoding automatically, making Cross-Site Scripting (XSS) and injection attacks difficult. It's like a padded room: it's hard to hurt yourself unless you really, really try.

However, even the best frameworks can't save you from a developer determined to pass raw user input directly into a dynamic rendering context. In CVE-2026-21450, we find exactly that—a classic case of trusting the user a little too much. Specifically, in the administrative Reporting module.

This isn't your average 'low impact' admin vulnerability. In the world of eCommerce, 'Admin' often means 'Business Owner', not 'System Administrator'. If a store owner's account is compromised (phishing, reused credentials), this vulnerability turns that limited access into full server takeover. It transforms a bad day into a catastrophic data breach.

The vulnerability resides in the Webkul\Admin\Http\Controllers\Reporting namespace. The application uses a query parameter named type to determine which statistical graph to render (e.g., 'total-sales', 'average-order-value'). Ideally, this input would be matched against a strict allowlist of valid graph types.

Instead, the application took a shortcut. It grabbed the type parameter from the URL and used it to dynamically resolve functions or view components. This is the programmatic equivalent of letting a stranger walk into a bank vault just because they're wearing a suit. Because the input wasn't validated, the application passed the string further down the chain into the Blade engine.

When Blade encounters syntax like {{ 7*7 }}, it evaluates it. If you can control the string being evaluated, you aren't just changing a graph label; you are executing PHP code. This is Server-Side Template Injection (SSTI), and in a PHP environment, it's Game Over.

Let's look at the fix to understand the crime. The patch was applied in packages/Webkul/Admin/src/Http/Controllers/Reporting/Controller.php.

The Vulnerable Logic (Conceptual): Previously, the code effectively blindly trusted the input. It likely looked something like this:

$type = request()->query('type');
// The app blindly tries to use $type to fetch data or render a view
return $this->reportingHelper->getStats($type);

The Fix (Commit 3f294b4): The developers introduced a new method resolveTypeFunction() that acts as a bouncer. It checks the ID against a hardcoded list of valid functions ($this->typeFunctions).

// Fixed implementation in Controller.php
protected function resolveTypeFunction()
{
    // STRICT CHECK: Does the key exist in our allowed list?
    if (! array_key_exists(request()->query('type'), $this->typeFunctions)) {
        // If not, kill the request immediately.
        abort(404);
    }
    return $this->typeFunctions[request()->query('type')];
}

By adding array_key_exists, the application ensures that {{system('id')}} is treated as an invalid key (returning 404) rather than a valid instruction to execute.

Exploiting this is trivially easy once you have access to the admin panel. The barrier to entry is high (you need admin creds), but the complexity of the exploit is essentially zero.

Step 1: Authenticate Log in to the Bagisto dashboard. You need permissions to view reports.

Step 2: Locate the Target Navigate to any reporting page, for example, the Products report view.

Step 3: Inject the Payload Append the malicious type parameter to the URL. We use standard Blade syntax {{ }} to break out of the string context.

[!NOTE] Real-world attackers will base64 encode payloads or use passthru to handle output better, but system() works for a simple proof of concept.

URL: http://target-store.com/admin/reporting/products/view?type={{system('cat /etc/passwd')}}

Step 4: Execution The server receives the request. The controller sees the type, passes it to the view renderer, Blade parses the curly braces, executes cat /etc/passwd, and dumps the contents of the password file right into your nice HTML sales chart.

Since Bagisto is an eCommerce platform, it holds the Crown Jewels: customer PII, order history, and potentially payment tokens (depending on the gateway implementation).

Confidentiality Loss: An attacker with RCE can dump the entire database configuration from the .env file, connect to the database, and steal every single customer record.

Integrity Loss: They can modify product prices, inject malicious JavaScript (Magecart skimmers) into the frontend to steal credit cards from future customers, or create hidden admin accounts.

Availability Loss: rm -rf /. Need I say more? The store is gone.

The remediation is straightforward. If you are running Bagisto, you have two options:

1. Upgrade (Recommended): Update your Bagisto instance to version 2.3.10 or greater immediately. This version includes the patch.
2. Manual Patch: If you cannot upgrade, you must manually edit the Reporting Controller to validate the type parameter against a whitelist before using it.

Defense in Depth: This vulnerability highlights the need for a Web Application Firewall (WAF). A WAF rule blocking query parameters containing {{ or }} would have likely mitigated this attack even before the patch was applied. Additionally, file integrity monitoring should alert you if core controller files are tampered with.