Magento CVE-2026-71362 is an incorrect authorization flaw in Adobe Commerce, Adobe Commerce B2B and Magento Open Source that lets an attacker with no account and no help from a victim switch a storefront session into another customer’s account, exposing that customer’s orders, addresses and saved details. Adobe rates it 9.1 and critical, the fix shipped in the August 2026 security patches for supported release lines, and attackers are now exploiting it, which put it on CISA’s Known Exploited Vulnerabilities list. Stores running the July 2026 release level or earlier without the isolated patch are exposed. For an online retailer or a B2B ordering portal, the steps are to apply the August update or isolated patch, confirm it on production, and review customer accounts and orders for signs of takeover since the flaw became public.
Why Customer Account Takeover Hurts a Small Store Most
Customer account takeover hurts a small store most because the costs land on the business directly: refunds for fraudulent orders, support hours spent with angry customers, card network scrutiny and, for stores in many states, breach notification duties. A large retailer absorbs that. A store doing a few million dollars a year feels every hour of it, which is why the store belongs inside your cybersecurity program.
Our team sees a recurring arrangement among clients selling online. The store was built on Magento by an agency, the agency maintains it on a retainer that covers a set number of hours, and security patches are bundled into quarterly upgrades to save time. That rhythm works for ordinary fixes. It fails for a flaw that attackers start using within weeks of the patch, a risk a zero trust security plan helps contain.
Here are the five principles behind the steps in this article:
- Patch level is measured, not assumed. Read it from the production installation, not from the agency’s last invoice.
- B2B portals count. Wholesale and dealer portals built on Adobe Commerce B2B hold pricing, credit terms and account contacts.
- Takeover leaves a trail. Changed emails, new addresses and odd orders show up in the admin if someone looks.
- Customers need a path back. A forced reset with a clear message protects customers without driving them away.
- Security patches cannot wait for upgrade projects. Isolated patches exist for exactly this situation.
This guide is written for owners, ecommerce managers and operations leads at retailers, distributors and manufacturers whose online store or ordering portal runs on Adobe Commerce or Magento Open Source.
How the Session Flaw Works
The session flaw works because the platform’s handling of customer identity and account sessions does not properly check that a session belongs to the customer it claims to represent. Researchers who reviewed the patch found that an attacker can switch a session to another customer’s account without holding any account of their own.
Some store owners take comfort in requiring login for checkout. That does not help here, because the attack moves the attacker into a logged-in customer’s session. Strong passwords and two-step sign-in for customers also do not stop it, since the attacker never goes through the login page.
What an Attacker Gets From a Customer Account
A hijacked account exposes the customer’s name, email, phone, saved addresses and order history, and on many stores it allows changing the shipping address and reordering with stored payment tokens. On B2B portals it can expose negotiated prices, purchase order history and the ability to place orders on the company’s credit terms.
The counterpoint is that most stores do not store full card numbers, since payment processors hold them. That narrows one kind of damage. It does nothing about fraudulent orders shipped to a new address, stolen personal data or the advantage a scammer gains by knowing a customer’s real order history when they phone or email them, a classic setup for the identity-based attacks that cost SMBs real money.
Applying the Adobe Commerce Security Patch
Applying the Adobe Commerce security patch for CVE-2026-71362 means installing the August 2026 security release for your supported line, or the isolated patch Adobe published for stores that cannot upgrade right away, and then confirming it on production. Stores on unsupported versions need to plan an upgrade, because they will not receive the fix.
Isolated Patch or Full Upgrade
Adobe publishes isolated patches so a store can take a single security fix without a full version upgrade. For a store that is days or weeks from a planned upgrade, the isolated patch is the faster route. For a store several releases behind, the upgrade is overdue anyway.
Agencies sometimes recommend waiting to fold the patch into the next upgrade because each deployment costs hours. For a flaw being exploited, that trade no longer holds. Ask for the isolated patch now and keep the upgrade on its own schedule.
Confirming the Patch on Production
Ask your developer to show the installed version and the list of applied patches on the production server, using the Composer package versions and the patch tool’s status output. Staging environments are often patched first and production later, so a staging screenshot is not proof. An independent cyber security audit can verify it for you.
A cautious team will also test checkout, account login, customer address changes and B2B quote flows after deployment. That is good practice and should take hours, not weeks.
Hosting and Cloud Editions
Stores on Adobe Commerce Cloud still need their own team or agency to deploy the patch to their project, even though Adobe manages the infrastructure. Stores on Magento Open Source are fully responsible for both. In either case, confirm who pressed the button and when.
Checking for Account Takeover Since Disclosure
Checking for account takeover since disclosure means reviewing customer accounts, orders and logs for changes that customers did not make, starting from the date exploitation became public and continuing until the patch went live. Most stores have the data they need in the admin and server logs.
Signals in Customer Data
Look for customer accounts whose email address, password or default shipping address changed recently, especially in clusters or at odd hours. Look for orders shipped to addresses that differ from the account’s history, reorders of high-value items to new addresses, and gift card or store credit use that customers did not request.
Some of these changes are legitimate, since people move and buy gifts. The goal is a short list for human review, not an automatic block. Patterns, such as many accounts changed from the same network range, are the strongest sign, and they are what network security monitoring is built to surface.
Signals in Logs and Fraud Tools
Ask your hosting provider or developer for web server logs covering the exposure window and look for unusual requests to customer account and session endpoints. Your payment processor’s fraud dashboard may also show a rise in declined or flagged orders that matches the timeline.
A fraud tool that blocked suspicious orders does not prove nothing happened. Data exposure from viewing an account leaves no order behind, so the account review still matters. A team providing managed security services can run it alongside your agency.
Talking to Customers Without Losing Them
Talking to customers about a possible account takeover means telling affected people clearly what happened, what you did and what they should do, while avoiding a vague mass alarm that pushes loyal buyers away. The right approach depends on what the review finds.
When to Force Password Resets
If the review finds confirmed or likely takeovers, reset passwords and sign out active sessions for those accounts, restore changed emails and addresses, and contact the customers directly. If you cannot narrow the scope, a store-wide session sign-out and an optional reset prompt is a reasonable middle ground.
Some owners worry that any notice will hurt sales. In practice, customers respond better to a short, plain message than to finding misuse on their own later. Check with counsel on whether state breach notification laws apply to what was exposed.
Writing the Message
Keep it short: what happened, when, what information may have been seen, what you changed, and what the customer should check. Avoid technical language, and do not ask customers to click a link to verify their account, because scammers copy that exact pattern. Your own staff should know the pattern too, through security awareness training.
Making Store Security Part of the Retainer
Making store security part of the retainer means your agreement with the agency or developer names a response time for security patches, separate from upgrade projects, and a monthly report of the installed version and patches. Most retainers are written around features and design, and security fits into whatever hours are left.
Questions to Ask Your Agency
- What Adobe Commerce or Magento version and patches are on production today?
- When was the CVE-2026-71362 fix applied, and how was it verified?
- What is your committed response time for a patch Adobe rates critical?
- Who reviews customer accounts and logs after a flaw like this?
Where the Store Fits in Your Security Program
Treat the store as one of the most exposed systems you run, with the same monitoring, access controls and incident plan as your email and network, including a tested business disaster recovery plan. Admin accounts on the store should use two-step sign-in (the same reasoning we apply to email security), the admin path should not be guessable, and access should be removed when staff or agency members leave.
Frequently Asked Questions
Which versions are affected by Magento CVE-2026-71362?
Adobe Commerce, Adobe Commerce B2B and Magento Open Source at the July 2026 release level and earlier are affected. The August 2026 security releases and isolated patches fix it for supported lines.
Does CVE-2026-71362 require the attacker to have an account?
No, the attacker needs no account, no admin access and no action from the victim. That is why exploitation spread quickly once details were known.
Do strong customer passwords stop this attack?
No, the attacker switches into an existing session instead of logging in, so passwords and two-step sign-in do not block it. The fix is the patch.
Should we notify customers after patching?
Notify customers whose accounts show signs of takeover, and check with counsel on state breach notification rules. A short, plain message protects trust better than silence.
Can we wait for our next planned upgrade to apply the fix?
For a flaw being exploited, waiting is risky. Apply Adobe’s isolated patch now and keep the upgrade on its own schedule.
Who Stands Behind This Guidance
Mindcore Technologies secures the systems small and midsize businesses depend on to sell and serve customers, including online stores and B2B ordering portals that hold customer data and payment relationships. Our team reviews CISA’s Known Exploited Vulnerabilities catalog daily and translates new entries into practical checks for the platforms our clients run. That approach reflects the priorities of Matt Rosenthal, Mindcore’s CEO, who has built the company around accountable, measurable security that business leaders can verify for themselves.
Protect Your Store and Your Customers This Week
Magento CVE-2026-71362 lets an attacker step into a customer’s account with no login of their own, and it is being exploited against stores that have not patched. Apply the August 2026 security release or isolated patch, confirm it on production, review customer accounts and orders since disclosure, and contact any customers whose accounts were touched. Then put a security response time in your agency agreement so the next critical patch does not wait for an upgrade project. If you want help reviewing your store’s patch level or your agency’s process, book a free strategy call and we will go through it with you.
