No password. No account. No click. Just someone else's customer session.
CVE-2026-71362 is a CVSS 9.1 incorrect authorization flaw in Adobe Commerce and Magento Open Source. It lets an attacker with no account, no privileges and no help from the victim step into another customer's session. Adobe patched it in August, Sansec blocked exploitation attempts shortly afterwards, and CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of Sunday 27 September — yesterday.
If your store runs on Magento and nobody has confirmed the August patch level in writing, this article is about you.
WHAT ACTUALLY HAPPENED
Adobe published bulletin APSB26-92 in August 2026. It fixed seven vulnerabilities across Adobe Commerce, Commerce B2B and Magento Open Source: two stored cross-site scripting flaws, several authorization weaknesses, and the one that matters most here, CVE-2026-71362.
The mechanism, as Sansec describes it, is almost insultingly simple: the attacker switches a customer session to another customer's account. That grants access to the victim's account and private customer data. There is no password to guess, no credential to phish, no admin panel to reach. Every release line through the July 2026 patches is affected.
Exploitation did not wait. Sansec detected and blocked attempts against the flaw shortly after the bulletin went public, which is now the normal pattern for e-commerce: an advisory is published, the patch is diffed, and automated scanning of every reachable storefront begins within days.
AND THEN THE ZERO-DAY
CVE-2026-71362 was not September's only Magento emergency.
On 23 August Sansec saw the first unsuccessful probes of something new. On 4 September at 22:20 UTC they confirmed the first successful exploitation of a previously unknown remote code execution chain, which they named StyleSmuggler. It affected Adobe Commerce and Magento Open Source from 2.4.4 through 2.4.9 — every supported version — and there was nothing to install.
The chain is a lesson in how modern web exploitation works. In the first stage, the attacker plants PHP code in a file Magento writes by itself, such as an error report generated from a crafted payment callback request. In the second, a request to the GraphQL endpoint assembles a chain of legitimate framework classes that ends up loading and executing that poisoned file, triggered through the rendering of a "Payment Transaction Failed Reminder" email. No email ever needs to be delivered. No administrator needs to click anything. One server was reportedly compromised within 50 minutes of the attacks starting.
Adobe shipped a hotfix on 7 September as APSB26-146, tracked as CVE-2026-75650 with a CVSS score of 10.0. For three days, stores had no patch and no official workaround. Versions 2.2, 2.3 and 2.4.0 to 2.4.3 are out of support and received nothing, although community maintainers have since backported the fix to many older releases.
WHAT THE ATTACKERS LEFT BEHIND
The payloads tell you what the intrusions were for.
The main implant is a Rust backdoor that hides in plain sight. It disguises itself as a kernel worker thread, [kworker/u:8:0], or as ordinary system services such as fc-cache and chronyd. It is relaunched by cron every few minutes, so killing the process does nothing, and some variants beacon out in traffic shaped like NTP time synchronisation, one of the least suspicious protocols on any server.
A second group dropped PHP web shells into the product image cache directory, a folder full of generated files nobody reviews, protected by a custom HTTP header so casual scanners see nothing. On at least one compromised store, researchers later found additional remote access tooling.
This is not smash-and-grab. It is persistence, built by people who expect to come back.
WHY THE STOREFRONT IS THE PERIMETER
For most small and mid-sized businesses, the online store is the only system that faces the entire internet, holds customer identities, and touches payment flows. It is also very often the system nobody inside the company runs. An agency built it, a hosting provider operates it, and patches get applied "when the next sprint allows".
That arrangement works until an advisory like APSB26-92 lands. Then three questions matter, and many organisations cannot answer any of them: which exact version runs the checkout, who is contractually responsible for applying the fix, and how long they have to do it.
Account takeover without authentication is particularly corrosive because it defeats the controls you actually invested in. MFA, CAPTCHA, rate limiting and failed-login alerting all protect the login page. This attack never touches the login page. The attacker simply looks like a logged-in customer, because as far as your logs are concerned, they are one. Addresses, order history, saved details, loyalty balances and gift card credit all sit behind a session that was never theirs.
Remote code execution goes further. Once an attacker runs code on the server, the checkout page belongs to them. Card skimming is one injected line of JavaScript away, and it is invisible to your customers until their bank calls them. At that point your customers are the victims, and your company is the breach notification.
THE PATCH MATH FOR E-COMMERCE
The timelines here are worth putting side by side.
For CVE-2026-71362, attacks began within days of the patch, and federal agencies were given a fixed deadline. For StyleSmuggler, attacks began three days before any patch existed. In both cases, the window between "public" and "exploited" was measured in days, while the typical change process for an agency-managed storefront is measured in weeks: ticket, estimate, staging, regression tests on the checkout, release slot.
That gap is the real vulnerability. A store that can only be patched on the next scheduled release is a store that will be exploited before it is patched, again and again, because commerce platforms are among the most aggressively scanned applications on the internet. Attackers do not need to target you. They run the exploit against everything that answers like Magento and see what comes back.
WHAT TO DO NOW
APPLY APSB26-92 AND APSB26-146 TODAY — confirm the patch status with vendor/bin/magento-patches, not with an email from your agency saying it is done; if nobody can show you the output, assume you are exposed.
HUNT FOR THE IMPLANT, NOT JUST THE BUG — patching closes the door but does not remove anyone already inside: look for fake kworker, fc-cache or chronyd processes, cron entries nobody created, and unexpected PHP files under pub/media.
ROTATE SECRETS IF IN DOUBT — if the store was exposed during the StyleSmuggler window, rotate the Magento encryption key and everything that depends on it: admin passwords, API tokens, payment integration keys, database credentials and SSH keys.
SHRINK THE ATTACK SURFACE — disable GraphQL if your storefront does not use it, block proc_open in PHP, mount /tmp, /var/tmp and /dev/shm with noexec, and put a web application firewall with Magento-specific rules in front of the store.
WATCH YOUR OWN EMAILS — "Payment Transaction Failed Reminder" messages with broken or unresolved template variables are a known exploitation signal; route a copy of store notifications to someone who will notice.
WRITE THE PATCH SLA INTO THE CONTRACT — your agency or host should commit to a maximum delay for critical security patches, in days, with an emergency path that bypasses the normal release cycle.
THE UNCOMFORTABLE PART
Most companies still think of their online store as a marketing asset: a design, a catalogue, a conversion rate. Attackers see it differently. To them it is an internet-facing application server that stores customer identities, processes payments, and is maintained by a third party on a quarterly budget.
They are right, and the September advisories prove it. One flaw handed out customer accounts without a password. The other handed out the server itself before a patch existed.
So ask the simple question, and insist on a real answer. Who in your organisation can tell you, right now, which Magento version runs your checkout — and who would notice if someone else started running it too?