← All Magento articles
9 min read

Magento Security Problems: The 2026 Bugs, and the Pattern Behind Them

Magento has had three critical pre-authentication vulnerabilities in under twelve months, and the most recent one scores a perfect 10.0. If you run Adobe Commerce or Magento Open Source, two of them have already been mass exploited and one is still a race you can win.

This is the short version of what happened, what to do about it, and — more useful than either — the pattern that connects every serious Magento breach since 2015.

The one to patch right now: CVE-2026-48358

On 14 July 2026 Adobe published bulletin APSB26-73. It covers 13 vulnerabilities, eight of them rated critical. The headline entry is CVE-2026-48358, which NVD scores CVSS 10.0 — the maximum the scale goes to.

The flaw sits in output encoding around the webhooks component, the plumbing that notifies external systems when something happens in the store — an order placed, a customer created. Improper escaping in that path can be turned into arbitrary code execution. It is unauthenticated and zero-interaction: no account, no login, no admin clicking anything. A well-formed request is the whole attack.

CVECVSSWhat it gives an attacker
CVE-2026-4835810.0Unauthenticated arbitrary code execution via webhooks
CVE-2026-483569.6Plant malicious files on the server
CVE-2026-479948.7Privilege escalation / feature bypass
CVE-2026-479888.6Privilege escalation / feature bypass
CVE-2026-479848.2Privilege escalation / feature bypass
CVE-2026-479958.1Privilege escalation / feature bypass
CVE-2026-479967.6Privilege escalation / feature bypass
CVE-2026-479927.2Privilege escalation / feature bypass

Affected versions are every supported line: 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, 2.4.6-p15 and earlier, 2.4.5-p17 and earlier, 2.4.4-p18 and earlier. Adobe shipped an isolated patch alongside the full release, so "we cannot schedule an upgrade this month" is not a reason to sit on it.

The good news, and the reason this one is worth acting on today: at the time of the bulletin no exploitation had been observed in the wild. That is the cheap moment. Every other entry on this page was patched under fire.

March 2026: PolyShell, and 79.5% of stores in two weeks

PolyShell (CVE-2025-20720, CVSS 9.8, bulletin APSB25-94) is the one that shows how fast this now moves. Sansec disclosed it on 17 March 2026.

The mechanism is almost embarrassingly simple. Magento's REST API accepts file uploads as part of a cart item's custom options. When an option has type file, Magento processes an embedded file_info object holding base64 data, a MIME type and a filename, and writes it to pub/media/custom_options/quote/. No authentication required. Attackers uploaded polyglot files — valid GIFs and PNGs with executable PHP embedded inside, which is where the name comes from.

product-photo.gifGIF89a…valid image header bytes<?php system($_GET['c']);?>…a web shell, in the same fileMagento REST APIchecks it looks likean image → acceptsWeb serversees .php-executable content→ runs itOne upload. Two readers. Nobody had to log in.
The uploader and the web server disagree about what the file is. That disagreement is the whole vulnerability.
Date (2026)What Sansec observed
16 MarchFirst exploitation — one day before public disclosure
19 MarchAutomated mass scanning begins
24 March56.7% of monitored stores had malicious PHP uploaded
30 March79.5% of monitored stores targeted
14 April82% of monitored stores had malicious uploads

The part most write-ups skipped is the part that mattered. The fix shipped in 2.4.9 and was not backported to 2.4.8, 2.4.7 or earlier. Merchants who had dutifully applied every patch on a supported older line were still exposed. "Are we patched?" was the wrong question; "does a fix exist for our release line?" was the right one.

2025: SessionReaper

SessionReaper (CVE-2025-54236, CVSS 9.1) was improper input validation in the Commerce REST API. The chain starts with nested deserialization, ends with a forged customer session, and under the right server conditions becomes unauthenticated remote code execution.

Sansec blocked over 250 exploitation attempts in a single day on 22 October 2025, with PHP web shells and phpinfo probes as payloads — and warned that more than 60% of stores were still unpatched at that moment. By 1 November, 81% of stores had been probed.

A short history of Magento getting hit

Shoplift2015CardBleed2020TrojanOrder2022CosmicSting2024SessionReaper2025PolyShellMar 2026Webhooks RCEJul 2026
Filled markers are incidents with confirmed mass exploitation; the hollow one was patched before attacks were observed. Eleven years, one repeating shape — a public endpoint that cannot be closed, and a patch window measured in days.
YearNameThe flawThe damage
2015ShopliftUnauthenticated admin takeover in Magento 1Nearly every unpatched store compromised within days of publication
2020CardBleedMagento 1 attacks weeks after end-of-life2,806 stores — about 3% of the install base — skimmed in one weekend
2022TrojanOrderCVE-2022-24086 (9.8): input validation in checkoutEmergency patch, already exploited. Seven Magecart groups hitting ~38% of stores by November
2024CosmicStingCVE-2024-34102: XXE via nested deserialization4,275 stores hacked by seven groups. Whirlpool, Ray-Ban, National Geographic, Segway and Cisco among the victims
2025SessionReaperCVE-2025-54236 (9.1): REST API deserialization250+ attempts blocked in a day; 81% of stores probed within ten days
Mar 2026PolyShellCVE-2025-20720 (9.8): unauthenticated file upload79.5% of monitored stores targeted in two weeks; fix not backported below 2.4.9
Jul 2026Webhooks RCECVE-2026-48358 (10.0): unauthenticated code executionPatched before observed exploitation — for now

CosmicSting deserves its own sentence, because it is the clearest illustration of why "it only reads files" is never reassuring. It let an attacker read arbitrary files — including app/etc/env.php, which holds the encryption key. With that key you forge API tokens, and with those you rewrite CMS blocks and inject a card skimmer. A file-read bug became a data breach in three hops, and chained with the PHP filter-chain trick (CVE-2024-2961) it became full code execution.

1Read any fileXXE gives arbitraryfile read2Steal the keyapp/etc/env.phpholds it3Forge API tokensthe key signs them4Inject a skimmerrewrite CMS blocksA file-read bug became a card breach in four hops.
CosmicSting, end to end. Patching closes step one; it does nothing about a key that already walked out the door.

Why the same thing keeps happening

It is tempting to read the list above as "Magento is insecure." That is the wrong lesson, and it will not help you. The honest reading is structural, and it comes down to three things.

1. The attack surface has to stay open. Checkout, the REST API, webhooks — every one of these incidents landed on an endpoint that must accept unauthenticated traffic from strangers, because that is what a shop is. You cannot firewall away your own checkout.

2. Self-hosted means patching is a human decision. A SaaS platform patches every tenant at once, whether they noticed or not. Magento patches when someone schedules a maintenance window. That difference is the entire reason 60–80% of stores are still exposed a week after disclosure.

3. The window has collapsed. PolyShell was exploited one day before public disclosure and mass-scanned within 72 hours. In 2015 you had weeks. In 2026 you have days, and sometimes you are already behind when you read the bulletin.

2015 · Shopliftabout two weeks2022 · TrojanOrderabout a week2025 · SessionReaperabout three days2026 · PolyShellexploited one day BEFORE disclosureTime between public disclosure and mass exploitation. The last bar runs the wrong way.
The window has not narrowed. It has inverted.

What to actually do

Nothing here is exotic. It is the same short list every time, and the stores that stay clean are the ones that treat it as routine rather than as an incident response.

Where this leaves the platform

Magento remains the most capable open ecommerce platform there is, and that capability is inseparable from the trade-off: you own the server, so you own the patching. Merchants who treat security patches as a standing two-week cadence rather than a fire drill have quietly sat out most of the incidents on this page.

The ones who got hit were, almost without exception, not unlucky. They were late.

Frequently asked questions

What is the most serious Magento vulnerability right now?

CVE-2026-48358, patched in Adobe bulletin APSB26-73 on 14 July 2026. NVD rates it CVSS 10.0 — the maximum. It is an unauthenticated, zero-interaction flaw in the webhooks component that can lead to arbitrary code execution, meaning an attacker with no account and no login can end up running code on the store. Adobe reported no known exploitation in the wild at the time of the patch.

Which Magento versions are affected by APSB26-73?

Every supported line: Adobe Commerce and Magento Open Source 2.4.9, 2.4.8-p5 and earlier, 2.4.7-p10 and earlier, 2.4.6-p15 and earlier, 2.4.5-p17 and earlier, and 2.4.4-p18 and earlier. Adobe also published an isolated patch so merchants can apply the fix without a full upgrade.

What was PolyShell?

PolyShell (CVE-2025-20720, CVSS 9.8, bulletin APSB25-94) was an unauthenticated unrestricted file upload in the Magento REST API, disclosed by Sansec on 17 March 2026. The cart’s custom-options endpoint accepted a base64 file payload and wrote it to disk, so attackers uploaded polyglot files — valid GIFs or PNGs with PHP embedded. Sansec observed exploitation from 16 March, and by 30 March 79.5% of the stores it monitors had been targeted.

Does patching Magento always fix the vulnerability?

Not always. The PolyShell fix shipped in 2.4.9 and was not backported to 2.4.8, 2.4.7 or earlier, so merchants on a fully patched older line were still exposed and needed a version upgrade rather than a patch. Checking that a fix exists for your specific release line matters as much as applying patches promptly.

Why does Magento keep having critical security problems?

Almost every major Magento breach shares one shape: a pre-authentication entry point that must stay open to the public — checkout, the REST API, webhooks — combined with self-hosted software that only gets patched when a human decides to patch it. The exploit window is now measured in days, and attackers automate mass scanning within about 72 hours of disclosure, which is faster than most merchants schedule maintenance.

Sources

Running Magento and wondering what else is quietly costing you? WisWes installs on Magento in a few minutes, and the rest of our Magento writing covers the less alarming side of the platform. If you are weighing platforms entirely, the pricing page shows what running an AI seller actually costs.

Turn questions into checkout.

WisWes drops into your store and guides shoppers from browsing to buying. 14-day free trial — no card.