Guides

SessionReaper and the Real Cost of Owning a Magento Store in 2026

July 25, 2026 - Alexandru-Manuel Carabus

SessionReaper hit 81% of Magento stores with attack traffic in six weeks. Here is what CVE-2025-54236 actually was, why patch rates were similarly slow on Adobe Commerce, and what running a self-hosted Magento store responsibly actually requires.

Six weeks in late 2025

On October 22, 2025, mass attack traffic against Magento stores worldwide jumped from isolated probing to a coordinated, automated sweep. By October 24, roughly 31 percent of all Magento stores, Adobe Commerce and Magento Open Source alike, had been hit. By October 26, it was 49 percent. By November 1, security research firm Sansec put the number at 81 percent of the entire installed base: attack traffic, not confirmed compromise, but attack traffic against four out of five Magento stores on earth within ten days of the mass-exploitation wave starting. An estimated 16 to 18 percent of stores were believed to have been actually backdoored.

The vulnerability had a name by then: SessionReaper, tracked as CVE-2025-54236, CVSS score 9.1. If you run a Magento store, or you are evaluating whether to build one, this is the episode you need to understand honestly before anyone sells you anything, including us. We are LIQUIDLAB, and we build and maintain Magento stores for a living. That does not mean we get to skip this part of the conversation. It means we owe you the accurate version of it.

What SessionReaper actually was

Strip away the acronyms and CVE-2025-54236 was a vulnerability that let an attacker take over a Magento store without ever logging in. Unauthenticated remote code execution is the technical term: an attacker sends the store a specially crafted request, and the store executes code on the attacker's behalf, no password, no admin session, no social engineering required. A CVSS score of 9.1 out of 10 reflects exactly how bad that is. This was not a vulnerability that required a careless employee clicking a link. It required only that your store existed on the internet and hadn't been patched.

The specific mechanism involved how Magento's checkout and customer-session handling deserialized certain input, a class of bug security researchers have seen before in Magento's history (it shares a family resemblance with 2022's similarly severe "Cosmic Sting" issue). Adobe disclosed and patched the underlying flaw in September 2025. That is the part worth sitting with: a fix existed for weeks before the mass-exploitation wave began. Sansec's monitoring found that as late as September 19, fewer than one in three Magento Open Source stores had applied it. By October 23, the day before attacks intensified, only 38 percent of stores were patched. The vulnerability was not a zero-day surprise. It was a known, published, fixable issue that most of the ecosystem simply had not gotten around to closing, and attackers noticed.

Sansec also found that Adobe's initial public patch left a related file-upload attack vector unaddressed, meaning even some merchants who did patch promptly were not fully covered until a follow-up fix landed. That detail matters for the next section.

The 81 percent number, read correctly

It is tempting to read "81 percent of Magento stores hit" as "Magento is unsafe" and stop there. That is not the honest reading, and it is not even the useful one. Attack traffic reaching a store is not the same as a store being compromised, Sansec's own estimate puts actual backdoor installation at 16 to 18 percent, a serious number but a very different one from 81 percent. What the full figure actually measures is how fast and how completely mass-scanning botnets find every unpatched, internet-facing instance of a widely deployed open-source platform once a working exploit is public. That speed is not a Magento-specific flaw. It is a property of running any self-hosted software at scale on the open internet.

What the 81 percent number really demonstrates is a distribution problem, not a design problem. Magento Open Source, run self-hosted, puts the patching decision, and the patching timeline, in the merchant's or their agency's hands. Nobody pushes the fix to you automatically. There is no platform-level force-update the way there is on a fully managed SaaS product. If your store, or your hosting provider, or your agency, does not treat security patching as a standing operational responsibility rather than a periodic afterthought, the gap between "patch exists" and "patch applied" is exactly the gap SessionReaper walked through. That is the real lesson: self-hosted Magento demands ongoing operational discipline as a condition of ownership, not a nice-to-have. It is a genuine cost of the platform, and pretending otherwise would make this article a brochure instead of an honest assessment. If you are weighing that operational reality against a full replatform, our migration playbook lays out what that ownership actually involves month to month, not just at go-live.

The Adobe Commerce parallel

Here is the detail that should reshape how you think about this, because it cuts against the easy sales pitch. If SessionReaper were purely a "cheap open-source software is risky, pay for the enterprise version" story, you would expect Adobe Commerce, the paid, officially supported edition, to have patched dramatically faster. It did not. Sansec's monitoring showed Adobe Commerce Cloud's own initial patch rate running only modestly ahead of Magento Open Source's, roughly one in two Commerce instances patched at a point where roughly one in three Open Source instances were. Both editions share the same core codebase and the same vulnerability. Both editions were exposed to the same automated attack wave. Both editions relied on the same thing to close the gap: someone with operational authority over the store actually applying the fix in a reasonable window.

This is not an argument for buying Adobe Commerce for safety. Adobe Commerce's license cost scales into tens of thousands of dollars a year depending on GMV band, and SessionReaper shows that spend does not buy you a materially faster patch cycle. What closes the gap is the same thing on both editions: a team, in-house or contracted, whose job includes watching for security bulletins and acting on them promptly. That is a people-and-process problem, not a licensing-tier problem.

What a serious Magento operation actually looks like

If self-hosted Magento demands operational discipline, the honest next question is what that discipline actually consists of. It is not exotic. It is a short list, applied consistently, month after month, whether or not anything is on fire.

Patch cadence means subscribing to Adobe's security bulletins and Sansec's threat research, and treating a critical CVE as a same-week event, not a next-sprint item. Monitoring means having something watching your store's file integrity, admin login attempts, and outbound traffic patterns, so a compromise gets caught in hours rather than discovered by a customer complaining about fraudulent charges. Incident response means having a written plan before you need one: who gets paged, what gets isolated, how customers get notified if data was exposed. Backup verification means not just running backups, but periodically proving you can actually restore from one, because an untested backup is a belief, not a safeguard. A web application firewall filters out the obvious mass-scan traffic before it ever reaches your application layer. And staging-environment testing means every patch gets applied and verified somewhere that isn't your live storefront first, so a security fix doesn't become its own outage.

This is what LIQUIDLAB Support and Development is built around: an ongoing relationship, billed hourly under a contractual SLA with the rate confirmed in writing after discovery, where patch cadence, monitoring, and incident response are standing responsibilities rather than a one-time project deliverable. We also use LIQUIDLAB AI™, our internal tooling for code review, bug triage, and deployment work, to catch regressions and flag risky changes faster during that ongoing work. It does not write your marketing copy or plan your SEO; its scope is code and deployment, full stop. None of this is glamorous. It is the unglamorous part of Magento ownership that determines whether the next SessionReaper is a Tuesday-afternoon patch or a Sunday-morning incident.

Shopify's honest tradeoff here

Give Shopify its due: this entire category of problem is one Shopify absorbs on your behalf. Patching, infrastructure hardening, and platform-level vulnerability response are Shopify's job, not yours, and that is a genuine, non-trivial advantage if your organization has no appetite for owning any of the list above. You are trading it for something real in return: you do not control the code, you do not control the infrastructure, and you inherit whatever architectural limits the platform imposes, the same tradeoff we cover in detail in our pillar guide to Magento versus Shopify. Neither direction is free. One spends money and flexibility to buy operational simplicity. The other spends operational discipline to buy control. SessionReaper is the clearest recent illustration of exactly what that second bill actually looks like.

Where to go from here

If you are a Shopify merchant looking at Magento's flexibility and wondering whether you could actually own the operational side of it, that is precisely the conversation worth having before any migration decision, not after. Book a free strategy call with LIQUIDLAB and bring your real question: not "is Magento safe," but "what would running Magento responsibly actually take for a store like mine, and are we set up to do it."