Patching Magento Alone Won't Save Your Store — Attackers Were In Three Days Earlier

A 10-out-of-10 Flaw in Magento and Adobe Commerce: What Actually Happened

The direct answer first: on September 4, 2026, attackers began exploiting an unpatched flaw in Magento Open Source and Adobe Commerce, tracked as CVE-2026-75650 with a severity score of 10.0 — the highest possible. The flaw allows commands to be executed on the store's server with no login and no privileges at all, and Adobe released its fix on the evening of September 7. That leaves three full days during which stores were exposed with no protection whatsoever. Which is precisely why installing the patch is not enough: if your store runs on this platform, the safe assumption is that you may have been compromised before the fix existed, and the right response is to hunt for signs of intrusion and rotate your encryption keys and every credential — not install the update and move on with your day.

Who is affected, exactly

The list is unusually broad, because it includes the newest release available at the time of discovery:

• Magento Open Source and Adobe Commerce: versions 2.4.4 through 2.4.9, including all patch updates up to August 2026.
• Adobe Commerce B2B: versions 1.3.3 through 1.5.3, up to the August 2026 update.
• Anything older than 2.4.4: already out of support, and the most dangerous category because the official hotfix does not cover it.

Put plainly: if you were running a fully updated Magento as of September 1, you were exposed. This is not the familiar negligence scenario we usually warn about — it is a genuine zero-day that nobody had a way to get ahead of.

How the attack works without a password

The attack runs in two stages and abuses Magento's ability to build email templates. In the first stage, the attacker sends a crafted request to a payment response path, and the full contents of that request get written into an error-report file on the server. In the second stage, a request to the GraphQL endpoint points back at that poisoned file, and its contents execute while a payment-failure reminder email is being prepared.

The part worth a business owner's attention is not the technical detail but what it reveals: public paths that look entirely innocent — a payment gateway response, a query endpoint for the storefront, an automated email — combined into a complete route into the server. Serious vulnerabilities are rarely one wide-open door; far more often they are a chain of small doors, each of which looks perfectly reasonable on its own.

What attackers planted once inside

This is where the difference between a vandal and an organized operation shows. The payloads observed were not loud ransomware notes but quiet persistence tooling:

• A backdoor written in Rust that disguises itself as one of the operating system's kernel processes, so it does not stand out to anyone skimming a process list.
• Camouflaged command-and-control traffic over the time-synchronization port, so the activity looks like routine clock-setting in network logs.
• PHP web shells written inside product-image cache folders — places nobody normally inspects because they are full of temporary files.
• Additional remote-access tooling from a second attacker with unrelated tools, meaning the flaw was being exploited by more than one group at the same time.

The goal of payloads like this on a known online store is to stay for a long time and read order and payment data as it passes through — not to take the site down. An infected store keeps operating completely normally, and that is the unsettling part.

Why installing the update is not enough

Because if an attacker got in before September 7, they now hold a copy of your encryption keys and stored credentials. The patch closes the door they came through; it does not evict them from inside. Adobe's own guidance was explicit on this point: apply the fix and then rotate encryption keys, admin panel passwords, API tokens, payment gateway credentials, database passwords, and server access keys.

The patch stops the bleeding. Rotating keys is what gets the uninvited guest out of the house.

A practical action plan for a store owner

• First — confirm the fix is genuinely installed, not that someone said it was. Ask your team for proof from the patch log on the server itself, not a reassuring message.
• Second — check for intrusion artifacts: suspicious running processes with names mimicking system processes, PHP files inside media and image folders, and unusual error-report files.
• Third — review the outbound email log. A sudden spike in payment-failure reminder emails is a direct indicator of exploitation attempts, and it is one any operations lead can read without deep security expertise.
• Fourth — rotate every key without exception, payment gateway credentials above all. This needs a planned maintenance window, not an improvised decision at peak hours.
• Fifth — if your version predates 2.4.4, stop waiting for an official patch that is not coming. Set an upgrade plan with a real date, and put the store behind a web application firewall in the meantime.
• Sixth — document what you did. If customer data turns out to have leaked, you will need a timeline of what you did and when.

The regulatory angle in Saudi Arabia: customer data is not only a technical matter

An online store holding customer names, addresses, mobile numbers, and order history is processing personal data governed by the Personal Data Protection Law. A breach does not stay an internal matter between the store and its hosting provider; it creates obligations toward the competent authority and toward the data subjects themselves. So the question a store owner should be asking today is not only "has the server been patched" but "can I demonstrate that my customers' data was not touched".

If your store runs on a managed cloud platform such as Salla or Zid, you are outside the scope of this particular flaw, because patching the platform is not your responsibility. But the same lesson applies to any extension or third-party integration you have wired into your store: patching responsibility follows whoever owns the server.

How we handle incidents like this at Origami

The principle we build client systems on is that a security incident is not a remote possibility but a deferred event. In practice that means three things: credentials kept out of the codebase in a separate vault so rotating them is a minutes-long task rather than a week-long project; operational logs stored off the server itself so an attacker cannot erase their own traces; and backups that have actually been tested by restoring them, not merely scheduled.

And if you run a Magento store without a dedicated technical team, today's correct move is simple: ask your hosting provider or technical partner for a written report answering just three questions — exactly when the fix was installed, what the compromise scan found, and whether the keys were rotated. Those three questions reveal more about a technical partner's readiness than any presentation.

Sources

• Adobe Commerce official announcement on security update APSB26-146 and the urgent hotfix: experienceleague.adobe.com
• Sansec technical analysis of CVE-2026-75650 and indicators of compromise: sansec.io/research/stylesmuggler-0day
• CISA Known Exploited Vulnerabilities catalog: cisa.gov
• Personal Data Protection Law — Saudi Data and AI Authority: sdaia.gov.sa