Magento's August problem is a calendar, not a CVE

Two things landed in the Magento world this month and they've been bolted together into a single panic.

On 14 July, Adobe published APSB26-73: fourteen CVEs, eight of them critical, headlined by an unauthenticated file upload flaw scored 9.6. On 11 August — six days from when I'm writing this — Magento Open Source 2.4.6 reaches end of standard support.

Both are real. But the framing doing the rounds, roughly "critical RCE plus EOL equals your store is about to be owned", gets the risk backwards. The patch is an afternoon's work. The calendar is the thing that will actually cost you money, and it's the thing almost nobody is planning for properly. Here's what's actually true, including a couple of things the internet has flatly wrong.

What's actually in APSB26-73

Fourteen CVEs. Eight critical, four important, two moderate. Priority 2, which in Adobe's language means no known exploitation and a thirty-day patch window rather than a drop-everything emergency. Affected products are Adobe Commerce, Adobe Commerce B2B, Magento Open Source, and the Adobe Commerce Events webhooks plugin.

The headline bug is CVE-2026-48356 — CWE-434, unrestricted file upload, no authentication required, 9.6 in Adobe's scoring. That much is right.

What's been lost in the retelling is the UI:R in the vector string. It requires user interaction. Someone has to click something or land on a crafted page. That doesn't make it safe — a targeted phish at an admin user is not a high bar — but it is not the drive-by, zero-click, spray-the-internet bug that CosmicSting was. NVD's own analysis on 29 July actually dropped it to 9.3 after reassessing the availability impact.

If I were ranking these by "what would realistically hit an average store", the file upload flaw isn't first. That would be CVE-2026-47988 (8.6) and CVE-2026-47984 (8.2). Both are authorisation bypasses, both are PR:N/UI:N. No credentials, no victim, no clicking. They score lower and they're the ones a scanner can throw at the internet at scale.

The 10.0 that isn't

One correction worth making loudly, because several agency blogs are repeating it: CVE-2026-48358 has not been rescored to 10.0 by NVD, and it is not an unauthenticated RCE.

Go and read the NVD record. It carries Adobe's CNA score of 9.1, with PR:H in the vector — privileges required, high. You need an authenticated admin. NVD hasn't published an independent assessment at all; the record is still flagged as undergoing enrichment and the change history shows no rescore. It also only affects the webhooks component, which plenty of stores don't run.

I don't think anyone's being deliberately dishonest. Someone got it wrong, everyone copied it, and now it's in a dozen posts. But if you're using that number to justify an emergency change window, you're spending political capital on the wrong bug.

The EOL thing everyone is getting wrong

The line going around is "2.4.5 and 2.4.6 both reach end of life on 11 August 2026." Half right.

2.4.6 ends standard support on 11 August 2026. That's the real one. 2.4.5 ended standard support on 12 August 2025 — a year ago. What ends on 12 August 2026 is its extended support, which is an Adobe Commerce paid tier. If you're running Open Source 2.4.5, you haven't received a patch in twelve months. That's not a deadline approaching, that's a description of your current state.

There's a second split that matters more than the version numbers:

• Adobe Commerce licence holders on 2.4.6 have extended support to August 2027 and a security-only period running to May 2028. You have time. Not infinite time, but time.
• Magento Open Source has no extended tier. End of standard support is the wall. On 12 August, a 2.4.6 Open Source store stops receiving security patches, permanently.

So before anything else: run bin/magento --version and confirm which edition you're actually licensed for. That single check decides whether you're looking at a six-day problem or a two-year one.

While you're in there — 2.4.4 has been fully out of support since April, and PHP 8.1, which 2.4.4, 2.4.5 and 2.4.6 all run on, hit EOL on 31 December 2025. Even a perfectly patched 2.4.6 is sitting on an unsupported PHP runtime.

Why the CVE isn't the emergency

Adobe says no known exploitation. CISA hasn't added anything from this bundle to the KEV catalogue. Fine. The reason I'm still telling clients to patch this week has nothing to do with this bulletin's current threat level and everything to do with what reliably happens after any bulletin drops.

SessionReaper is the cleanest example. Emergency patch in September 2025. Mass exploitation began on 22 October. Six weeks after the fix shipped, 62% of stores were still unpatched. Sansec found roughly 81% had already been probed. The disclosure didn't kill those stores. The gap between "patch available" and "patch applied" did.

The pattern repeats. CosmicSting took 4,275 stores — about 5% of the entire install base — with payment skimmers. PolyShell hit 471 stores in a single hour back in March.

“Attackers don't need a zero-day. They need a published bulletin and a merchant who's busy.”— Every post-bulletin campaign of the last two years

Every one of those campaigns ran against a vulnerability that already had a patch sitting on Adobe's servers. That's the real risk model. Not "is this CVE scary", but "how long will my store sit on a published, weaponisable bug".

The bit that actually needs planning

Black Friday is 27 November 2026. Cyber Monday is the 30th. Most Magento shops freeze code from late October through the first week of December. That's not conservatism, it's sanity. Nobody wants to debug a static content deploy at 2am on the biggest revenue day of the year.

Work backwards. If freeze starts late October and you want a fortnight of production soak before it, your last sensible deploy date for a major version upgrade is somewhere around mid-October. It's the first week of August. You have roughly ten weeks.

Ten weeks is enough. Comfortable, even. But it's ten weeks for a 2.4.6 to 2.4.8 upgrade, and in my experience about 60% of that effort isn't the core version bump at all. It's third-party extension compatibility, custom code that doesn't survive PHP 8.3 and 8.4 (implicit nullable types, dynamic properties, loose type juggling), and a full checkout regression pass against your payment provider.

If you don't start in August, you don't start. You enter freeze on an unpatchable build and stay there through peak — carrying an EOL platform through the highest-traffic, highest-attack-volume six weeks of the retail year, with a code freeze stopping you doing anything about it. That's the pincer. Not the CVE.

What I'd actually do

This week: apply the APSB26-73 isolated patch. Adobe shipped these as isolated patch files rather than Composer packages, and each one only applies to the latest patch level of its line — the 2.4.6 patch expects 2.4.6-p15. So get current on your line first, patch, then verify with the new Commerce Version Tool. On Cloud, use Cloud Patches and don't double-apply.

Then do the boring things. Enforce admin 2FA. Prune the admin accounts belonging to people who left two years ago. Review recent admin logins. Most of the critical CVEs in this bundle target the admin surface, and the stored XSS ones are only worth anything with a live admin session.

And before assuming you're clean, scan. eComscan, MageReport, Adobe's own Security Scan Tool. After the last two years, "we haven't noticed anything" is not evidence. Look for PHP files where they shouldn't be (pub/media, var, media/custom_options/), admin users you don't recognise, unfamiliar cron entries, and injected script tags in CMS blocks.

Next ten weeks: target 2.4.8, not 2.4.9. 2.4.8 is supported into 2028 and wants PHP 8.3 or 8.4, MySQL 8.4 or MariaDB 11.4, OpenSearch 2.19 (Elasticsearch is gone), and Valkey 8 or Redis 7.2. 2.4.9 is the newer release and it will be the right target eventually, but it needs PHP 8.4/8.5 and OpenSearch 3, which is the single most common thing that turns a two-week upgrade into a six-week one. Take 2.4.8 now and schedule 2.4.9 for Q1, when there's no revenue on the line.

The compliance bit

Worth saying quickly, because it changes who needs to care. PCI DSS 4.0.1 requirement 6.3.3 says you install critical and high severity patches within one month. An EOL platform doesn't receive patches, so 6.3.3 isn't something you're failing — it's something you structurally cannot satisfy. Requirements 6.4.3 (inventory and authorise every script on your payment page) and 11.6.1 (detect unauthorised changes to payment page content) have been mandatory since March 2025, and they exist specifically because of Magecart.

If a merchant goes into peak season on an unsupported platform, there's a conversation with their acquirer waiting to happen. Better to have it in August on your own terms than in January after an incident.

The short version

• Patch APSB26-73 this week. It's an afternoon, and the SessionReaper numbers show that latency, not disclosure, is what actually gets stores compromised.
• Check your edition before you panic about the 11th. Adobe Commerce buys you until 2027. Open Source doesn't.
• Put the 2.4.8 upgrade in the calendar for September, not November. The vulnerability isn't the thing that's going to hurt you — running an unpatchable platform through Black Friday is.

If you're on 2.4.5 or 2.4.6 and you're not sure what the upgrade actually involves for your store, that's a conversation we have most weeks. Happy to have it.