Adobe Has Patched StyleSmuggler. Patching Is Not the Whole Job.

Updated 8 September 2026. Adobe has released the fix: Security Bulletin APSB26-146, covering CVE-2026-75650. Apply it now rather than at your next maintenance window. Affected builds are 2.4.4 through 2.4.9 at the 2026-aug releases and earlier, and Adobe has also pushed WAF rules for Cloud Infrastructure customers as an extra layer.

That is the urgent part, and if you do nothing else today, do that.

But there is a second half that the patch does not touch, and it is the reason this post still exists.

Sansec disclosed the vulnerability on 5 September. Exploitation was already running from the 4th. The patch landed on the 8th. That is a four-day window in which every unpatched Magento store on the internet was reachable by an unauthenticated attacker, and scanning was indiscriminate — this was not targeted at names anyone has heard of.

Applying the hotfix closes the door. It does not remove anyone who walked through it first. A patch does not delete a web shell, a cron entry, or a credential that has already been copied.

So the question for this week is not “are we patched”. It is “can we prove nothing happened during those four days?”

If you were running an affected version before 8 September, read this.

Patch first — APSB26-146 — but take a copy of your logs before you do. Patching and redeploying is the single most common way stores destroy the evidence of whether they were hit during the exposure window.

If you are not certain you are clean, contact us. We will help you check whether it already happened and work through what comes next. Same day. You do not need to be a client and there is no charge for pointing you in the right direction.

What it does, at the level worth publishing

Two stages, and the elegance of it is unpleasant.

First the attacker smuggles PHP into a file Magento itself writes — abusing a styles property in an unauthenticated GraphQL request so that hostile content lands in a log or report file. That file is not executable on its own. Nothing has happened yet.

Then they trigger Magento’s Payment Transaction Failed Reminder email. Rendering that email walks a template chain that ends up including the poisoned file, and the smuggled code executes with the permissions of the web application.

Neither half is exotic. The first is “user input reaches a file”. The second is “the application reads its own files back”. What makes it a zero-day is that the two are connected through machinery nobody was auditing as one path — a GraphQL parameter, a report writer and a transactional email template, owned by three different parts of the codebase and probably three different teams.

I am not publishing the request shape. It is already public, it is already being used, and repeating it helps the wrong people faster than it helps you.

Why this keeps happening faster than it used to

A colleague put it plainly in our own Slack the night this broke: vulnerabilities are coming out faster and more aggressively than they used to.

That is worth being precise about rather than hand-waving at “AI”. The change is not that attackers got smarter. It is that the economics of finding a bug like this collapsed. Chaining a GraphQL parameter to a report writer to an email template is exactly the kind of multi-hop reasoning across an unfamiliar million-line codebase that used to take a skilled researcher weeks of unpaid curiosity. It is also exactly what current tooling is good at.

The consequence for anyone running a large PHP application is structural, not tactical:

• The gap between “a bug exists” and “a bug is being exploited” is shrinking. Disclosure on the 5th, exploitation on the 4th. The attackers were first.
• Patch currency stops being a strategy. It remains necessary. It is no longer sufficient, and a security posture consisting entirely of “we are up to date” has no answer to the day there is nothing to update.
• Detection matters more than it did. If you cannot tell whether something already happened, patching later tells you nothing about whether you are already hosting somebody else’s code.

None of that is a reason to panic about Magento specifically. Every large application has this shape. Magento is simply large, valuable, and holds payment flows, which puts it near the front of the queue.

What to actually do, in order

1. Snapshot your logs, then patch. Both, today, in that order — and the first part takes minutes. Copy your application and access logs somewhere the deployment cannot touch. Patching and redeploying routinely rotates or wipes exactly the evidence you would need to answer whether you were hit during the exposure window, and once it is gone you cannot get it back. Then apply APSB26-146 immediately. This is not an argument for delaying the patch by even an hour; it is an argument for spending ten minutes preserving evidence first.

2. Then work out whether it already happened. Search the logs you just preserved for PHP function names turning up where user input belongs — base64_decode is the obvious marker — and for unusual bursts of payment-failure emails, which is the trigger half of the chain. Then check the host: unexpected cron entries, processes wearing system-worker names, recently modified files under /tmp and cache directories. Sansec’s write-up lists concrete indicators and remains the authoritative source; use theirs rather than mine.

3. Edge blocking is now a backstop, not the plan. Before the patch existed this was the main defence, and the advice circulating everywhere — “disable GraphQL” — traded a real outage for a hypothetical one. That argument is largely over: apply the hotfix and the hole is closed. Adobe has also deployed WAF rules for Adobe Commerce on Cloud Infrastructure, which is useful, but a WAF is a mitigation and the hotfix is the fix. Do not treat the WAF as permission to defer patching.

Where an edge rule still earns its place is if you genuinely cannot patch today — an ancient fork, a frozen release train, a change freeze someone will not lift. If that is you, get in touch and we will help you get a rule in front of your store while you sort the patch out.

4. Rotate anything that would have been reachable. If there are indicators, assume credentials, API keys and integration secrets were readable and cycle them. This is unglamorous and it is the step most often skipped because it is inconvenient and the evidence is ambiguous.

5. Do not assume the version number is the answer. Check the release notes rather than inferring coverage from a build bump, and confirm the hotfix actually applied cleanly. A partially applied patch on a store nobody re-checked is a worse position than an unpatched one, because everybody believes it is done.

If it did happen, there is a clock

This is the part most technical write-ups skip, and it is the one with legal consequences attached.

In Australia, the Notifiable Data Breaches scheme under the Privacy Act is triggered by suspicion, not proof. If you have reasonable grounds to suspect an eligible data breach, you have 30 days to carry out an assessment, and if it is confirmed you must notify the OAIC and affected individuals as soon as practicable. New Zealand’s Privacy Act 2020 works on a similar principle, with notification required as soon as practicable where a breach is likely to cause serious harm.

A remote code execution flaw on a store that processes payments and holds customer records is squarely the scenario those regimes were written for. Which means the moment you find an indicator, two things start at once: the technical response, and the assessment clock.

The mistake we see is treating those as sequential — spending three weeks confirming exactly what happened before anyone mentions the word “notifiable”. The clock did not wait for the forensics to finish.

We have worked clients through this. To be clear about where the line sits: we are not lawyers and the notification decision is not ours to make. What we can do is the part that decision depends on — establish what was reachable, what was actually accessed, and when — and give your privacy officer or legal counsel something factual to assess rather than a shrug. In our experience that evidence is what turns a frightening open-ended question into a decision someone can defensibly make.

The uncomfortable part

Steps 1 and 2 both assume something a lot of stores do not have: searchable logs, and someone who looks at them.

The reason a compromise gets found on day one rather than month four is almost never a clever tool. It is that logs were centralised and searchable, so a person could ask “has this string appeared anywhere” and get an answer in a minute. Where that is missing, the honest position is not “we are fine” — it is “we do not know”, and those are very different things to tell a board.

If you run Magento and cannot currently answer “would we know?”, that is the gap worth closing this quarter. It is cheaper than the alternative, and unlike patching, it still works on the day there is no patch.

---

Sources: Adobe Security Bulletin APSB26-146 and the hotfix installation notes, Sansec’s original disclosure, and The Hacker News coverage. Written 7 September 2026 and updated 8 September when Adobe shipped the fix.

We run Adobe Commerce platforms in production and handle this kind of week as part of support and maintenance. If you are not sure whether anyone is watching your logs, that is a conversation worth having.