Hey Reader,

Adobe put out an emergency patch last night for the Magento 0-day exploit, and I wanted to make sure it didn’t get past you today.

What to do right now

If you run a store, or you take care of one for a client, go apply the VULN-39341 hotfix. Adobe’s security bulletin is linked at the bottom and it has the composer instructions in it. Once you’ve applied it, you can check that it actually landed with:

​
vendor/bin/magento-patches -n status | grep 39341
​

After that, rotate your encryption key and every credential that key protected. Adobe is pretty clear about that part, and it really isn’t optional if your store was exposed at any point since September 4th.

And if you’re not the person who runs these commands, please pass this along to whoever is.

If you turned off GraphQL last week

When this first went public and there wasn’t a patch yet, the advice everywhere was to disable GraphQL. Sansec, who are the eCommerce security folks that found this thing, said it, and everybody repeated it. It was good advice at the time, and I passed it along myself.

But I pulled the hotfix down and read through the diff, and none of the nine files have anything to do with GraphQL.

The fix is somewhere else entirely. PHP tags get neutralized inside the error reports that Magento generates, two factories start checking a class before they instantiate it instead of after, and the email template model stops accepting non-string input on template_styles.

GraphQL was one way in, but it wasn’t the only one. That same step is reachable through pub/errors/processor.php, which is just the error handler every store already runs.

So if you turned GraphQL off last week and left it there, you’ll still want to go apply the patch.

About that clean patch status

This is the part I keep thinking about. The first confirmed victim was on 2.4.6-p15, they had the July and August patches applied, and security:patch-status came back clean.

All that command tells you is that you applied what shipped. It was never telling you that you’re safe.

One thing to watch when you apply it

8 of the 9 files live under vendor/, but pub/errors/processor.php doesn’t, and that one gets customized a lot. If you’ve ever skinned your error pages, you can expect to hand-merge that part, and then go double-check that it took.

A bug pattern worth looking for in your own code

The best part of this exploit isn’t really even a Magento thing:

​
$block = $this->objectManager->create($blockName, $arguments);
if (!$block instanceof BlockInterface) { throw ... }
​

It builds the object, and then checks whether it should have. But by that point the constructor has already run, which is where this whole problem comes from. That shape shows up in a lot of code that has nothing to do with Magento, so it’s worth a look through your own.

→ Sansec’s writeup on StyleSmuggler (they list indicators of compromise you can check against)

→ Adobe’s security bulletin (APSB26-146)
​

If you get stuck on any of this, lmk as I read all replies!

Mark Shust Teacher / M.academy​ Say hi 👋 on LinkedIn & YouTube​