)
On 22 October 2025, attackers began mass-exploiting SessionReaper, a critical flaw in Magento and Adobe Commerce. Adobe had released the fix six weeks earlier. Ten days after the release, fewer than one in three stores had applied it.
Most Magento breaches happen in that gap between a published fix and a patched store. This article explains why Magento stores attract attacks, what the main threats look like, and how a layered setup limits the damage when one defence fails. It ends with a checklist you can use to assess your own store.
Why Magento stores are targeted
Magento stores combine three things attackers look for: card payments, customer data and code that anyone can read.
Magento Open Source is public. When Adobe publishes a security fix, researchers and attackers can compare the old and new code to work out exactly what the hole was. Exploit details often appear within days, and automated tools then scan every Magento store on the internet to find the ones still running the old code.
This means the risk to an unpatched store rises sharply after a fix is released, because the fix itself points to the weakness. The time a merchant has to patch is set by how fast attackers move, which in recent cases has been between two and six weeks.
The five threats that matter most
1. Card skimming (Magecart)
Hidden JavaScript on the checkout copies card details as customers type them. The store keeps working normally, so the merchant usually finds out from the payment provider or from customers.
2. Unpatched flaws in Magento itself
The most serious ones let an attacker run code on the server or take over accounts without a password.
3. Vulnerable extensions
Many stores run dozens of third-party modules. Each one adds code that may be patched slowly or abandoned by its developer.
4. Admin break-ins
Bots try large numbers of passwords on the admin login, or reuse staff passwords leaked from other services.
5. Bots and abuse
Scrapers, fake account creation, card testing on the checkout, and traffic floods that slow the site down or take it offline.
These threats often chain together. A flaw in Magento gives an attacker access, a backdoor keeps it, and a skimmer turns it into stolen card data.
Two recent attacks, step by step
SessionReaper (CVE-2025-54236)
SessionReaper is a flaw rated 9.1 out of 10 that affects Magento and Adobe Commerce. Under certain conditions it lets an attacker take over customer accounts and run code on the server without logging in. Sansec, the Dutch ecommerce security firm that named it, ranks it among the most severe Magento flaws to date. The timeline shows how quickly the risk grew once the details were public:
9 Sep 2025: Adobe released the security fix.
19 Sep 2025: Ten days after the fix, fewer than one in three stores had applied it.
22 Oct 2025: A technical analysis was published and the first real-world attacks were detected.
23 Oct 2025: Only 38% of stores had applied the fix.
26 Oct 2025: Attacks had reached 49% of stores. Sansec estimated that 16–18% of all Magento stores carried at least one backdoor.
1 Nov 2025: 81% of Magento stores had been probed by SessionReaper attacks.
Attackers uploaded backdoors through the file upload used by the customer address form. Stores that store sessions as files on the server, which is the Magento default, were the easiest to exploit.
CosmicSting (CVE-2024-34102)
CosmicSting, rated 9.8 out of 10, let attackers read any file on the server. Attackers used it to read the store's secret encryption key, which allowed them to create admin access tokens and insert card skimmers into content blocks shown on every page, including checkout.
Adobe released the fix in June 2024. One week later, about 75% of stores were still unpatched. From 12 July, Sansec observed 5 to 30 stores being infected every hour, including international brands. A second wave in November 2024 infected nearly 3,000 stores.
CosmicSting also showed that patching alone may leave a store exposed. If the encryption key was stolen before the patch went in, the attacker can keep using it. Sansec advised stores to rotate the key after patching.
Defence in layers
Any single defence can fail. A patch can arrive late, a password can leak, an extension can carry a flaw nobody has found yet. A layered setup accepts this and makes an attacker get past several independent controls before reaching card data.
1. Edge (CDN)
All traffic passes a CDN such as Fastly first. Admin and API traffic go to a separate backend. Rate limiting, IP and country blocking, and forced HTTPS are applied per store.
Limits: bot floods, password guessing, attack traffic from unwanted regions.
2. Web server
Setup tools and sensitive folders are blocked, and GraphQL is disabled where the store doesn't use it. The admin can be restricted to approved IP addresses. A web application firewall (WAF) with a rule set such as OWASP filters known attack requests.
Limits: direct attacks on known weak spots, admin break-ins.
3. Magento application
Security patches are applied as tracked code changes. Every admin user logs in with two-factor authentication. A strict Content Security Policy at checkout controls which scripts can run.
Limits: known Magento and extension flaws, stolen staff passwords, skimmers.
4. Server and operating system
Servers have no public IP and are reached only through a secured gateway. The store's system user can't run system commands or schedule its own jobs, and can only reach approved outside addresses. Upload folders can't run code.
Limits: an attacker who gets in can't install tools, contact their own servers or stay.
5. Monitoring and response
Automated scans check regularly for malware and skimmers. Servers and logs are monitored. Prepared steps make it possible to lock down a store quickly when a new flaw is published.
Limits: late detection and improvised reaction to a live attack.
Layers 1 to 3 reduce the chance of a break-in. Layers 4 and 5 reduce the damage if one happens. The SessionReaper attacks show why the later layers count. The backdoors Sansec observed were PHP files uploaded to the server. On a store where upload folders can't run code, those files would not execute.
How patching works in practice
A reliable patch process has four steps:
1. Track releases
Follow Adobe's security bulletins and an independent source such as Sansec, which often publishes analysis before attacks start.
2. Add the fix as a tracked code change
Applying it through version control means every environment gets the same change, and it survives later deploys.
3. Test on staging, then deploy
Checkout, payment and key extensions are the parts most likely to break.
4. Check for earlier compromise
If attackers were active before the patch, a backdoor or stolen key may still be in place. After CosmicSting, this meant rotating the encryption key.
A full Magento upgrade can take longer than the window attackers give. In that case, a targeted mitigation buys time. For SessionReaper, that meant blocking code execution in the upload folder the attack used, while keeping a copy of the folder's contents as evidence. The full upgrade then follows on a normal schedule.
Questions to ask about your own store
These questions work whether you manage the store yourself or with an agency or host. Each "no" or "don't know" points to a gap worth closing.
☐ Do we know which Magento version we run, and which security patches are missing?
☐ How many days did it take us to apply the last critical patch?
☐ Do we have a list of installed extensions, and do we know which ones are still maintained?
☐ Does every admin user log in with two-factor authentication?
☐ Is the admin panel reachable only from approved IP addresses?
☐ Does traffic pass through a CDN or firewall that can block bots and rate-limit logins?
☐ Are upload folders blocked from running code on the server?
☐ Is the store scanned for malware and skimmers automatically, and do we know who receives the alerts?
☐ Do we have written steps for what happens on the day a critical flaw is published?
☐ If we patched late in the past, have we checked for backdoors and rotated the encryption key?
How we work with Magento stores
At Nordic Web Team, every layer described above is scripted with Ansible and Terraform. Each store we host gets the same setup, and changes are reviewed before they go live. We are also a Sansec partner.
When we take on a Magento store, the security work follows the same order:
1. Health check
A read-only review of the Magento version, missing patches, risky extensions and signs of existing compromise. Nothing changes on the live store.
2. Clean-up and patching
Remove anything attackers left behind, update Magento and extensions, and add patches as tracked code changes.
3. Hardening
Apply the server and admin controls, on staging first and then production.
4. Edge protection
Route the store through Fastly with admin separation and rate limiting.
5. Acceptance tests
Each control has a test that shows it works. We re-run the tests later to confirm nothing has drifted.
6. Ongoing monitoring
Hourly malware and skimmer scans with Sansec eComscan, server and log monitoring with New Relic, and prepared lockdown steps for the next critical flaw.
After a recent wave of attacks on Magento stores, one of our customers gave us their own technical hardening specification. We turned each measure into automation with a test for each, and the same package is now available to every store we host.
If you want a second view on where your store stands, we can run the read-only health check and walk you through what it finds.
Glossary
Backdoor: code an attacker leaves behind to get back in later, even after the flaw is patched.
CDN: a network of servers in front of the store that serves pages quickly and filters traffic.
CSP (Content Security Policy): a browser rule listing which scripts may run on a page, which blocks many skimmers.
CVE: the public ID number for a known security flaw, for example CVE-2025-54236.
CVSS: a 0–10 severity score for a flaw; 9 and above is critical.
Hardening: configuring servers and the store so there are fewer ways in and less damage if one opens.
Hotfix: an emergency fix applied before, or instead of, the full official update.
Magecart: the common name for card skimming attacks on online checkouts.
Patch: an update from Adobe that closes a security flaw in Magento.
PCI DSS: the card industry's security standard for merchants that take card payments.
Rate limiting: capping how often one visitor can request a page, which slows bots and password guessing.
Two-factor authentication (2FA): login with a password plus a code from a phone app.
WAF (web application firewall): rules that recognise and block attack requests before they reach the store.
)
)
)