APSB26-73: Adobe Commerce & Magento July 2026 Security Update

Every Magento security bulletin starts a race. Adobe publishes the fix; attackers download it, diff the patched code against the vulnerable code, and work backwards to an exploit. For the worst Magento bugs of recent years that reverse-engineering gap has been measured in weeks, not months — SessionReaper (CVE-2025-54236, patched in September 2025) went from bulletin to mass exploitation in roughly six weeks. Today, Adobe says it is not aware of any exploits in the wild for anything in APSB26-73.

That window is the whole story of this article. Patch inside it and APSB26-73 is routine maintenance. Patch after it closes and you are racing automated scanners that already know exactly which endpoints to probe.

The bulletin fixes five vulnerabilities. Adobe rates the update Priority 2 overall; the two lead CVEs are independently scored critical by NVD:

Severity scores for the two lead CVEs are from the NIST National Vulnerability Database; the remaining three are as categorised in Adobe's bulletin. Together they cover the three impact classes Adobe names: arbitrary code execution, privilege escalation and security feature bypass.

CVSS reserves 10.0 for a very specific combination: exploitable over the network, with low complexity, no privileges and no user interaction — and consequences that break out of the vulnerable component's own scope. CVE-2026-48358 ticks every box (NVD vector: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).

The flaw sits in output encoding around Adobe Commerce's webhooks functionality — the plumbing stores use to notify external systems when events happen (an order placed, a customer created). Improper escaping of output in that path can be turned into arbitrary code execution. In plain terms: a well-crafted request from someone with no account and no login could end with attacker-controlled code running inside your store. That is the same class of outcome as the worst Magento CVEs in history — the ones behind mass card-skimming campaigns.

No public exploit exists today. But a 10.0 with no authentication requirement is precisely the kind of bug that gets reverse-engineered first.

The second critical (9.6) is an unrestricted upload of a dangerous file type. Attacks built on this class of bug follow a well-worn chain: upload a file the application should have rejected — typically a PHP webshell dressed up as something innocent — find the path it landed on, execute it, and from there work laterally: inject checkout skimmers, dump customer data, plant persistence.

This is the layer where defence-in-depth actually earns its keep, because unlike a kernel bug these are web-layer attacks — the kind a web application firewall inspects on the way in. Sentinel, EveryHost's Magento security suite, filters malicious upload attempts and webhook abuse at the WAF, and its daily malware scanning is built to catch webshells that arrive by any other route. Sentinel now reports directly into your WHMCS client-area dashboard, so you can watch attacks being neutralised and see scan results for your own store without asking us. To be clear about the limits: a WAF is mitigation while you patch, not a substitute for the patch — novel exploits don't always match known attack patterns.

The remaining three fixes deserve more attention than they'll get. CVE-2026-47994 is a stored cross-site scripting flaw that enables privilege escalation by injecting scripts into the admin backend — the pattern behind many real Magento admin takeovers, because the script executes in the browser of whichever administrator next views the poisoned record. From an admin session, an attacker can create users, install "extensions" and reach everything your staff can reach.

CVE-2026-47988 and CVE-2026-47984 are both incorrect authorization flaws: the first circumvents default system rules, the second grants unauthorized access to resources. Authorization bypasses rarely make headlines on their own — their real value to an attacker is as links in a chain, turning a low-value foothold into reach the account was never supposed to have. Bulletins get exploited as packages, not as single CVEs; the patch closes all five doors at once, which is the point.

Every currently supported line is affected:

Adobe Commerce B2B and the Adobe Commerce Events SDK (1.6.0 to 1.20.0 — fixed in 1.21.0) are also in scope. The webhooks component features in both lead CVEs, so stores using webhook integrations should treat this as especially urgent.

The delivery mechanism matters as much as the fix. Under the patching model Adobe introduced this year, in-between fixes ship as isolated patches rather than full -p releases — and they are not cumulative. Each zip applies against one exact patch level: the 2.4.8 file assumes 2.4.8-p5, and community testing confirms it fails with merge conflicts on 2.4.8-p4. If you're behind, the path is: latest -p release first, then the isolated patch on top.

Applying it, in outline:

1. Back up files and database; work on staging first.
2. Confirm your exact version: bin/magento --version
3. Download your line's patch zip from Adobe's APSB26-73 knowledge-base article and apply it with Adobe's composer patch process.
4. Verify: vendor/bin/magento-patches -n status
5. Smoke-test storefront, checkout and admin; then repeat on production.

Some stores can't take a maintenance window this week — mid-campaign, mid-upgrade, or waiting on an agency. If that's you, reduce the attack surface while you schedule the patch:

• Audit your webhooks. Both lead CVEs touch the webhooks component. List every configured webhook and integration; disable anything unused or unrecognised.
• Put a WAF in front of the store and confirm rules for file-upload abuse are enabled — the highest-value mitigation for CVE-2026-48356 until the patch lands.
• Scan writable directories (media, var, pub) for PHP files that shouldn't be there — the tell-tale of a webshell that arrived before you read this.
• Review admin accounts and sessions. Remove stale users, enforce two-factor authentication, and check recent admin logins for anything unfamiliar — the stored-XSS flaw targets exactly this surface.
• Book the window now. Mitigations buy days, not months. The next bulletin is due 28 July; make this patch routine before the next one arrives.

APSB26-73 includes a fix for the 2.4.6 line, but regular support for Magento 2.4.6 ends on 11 August 2026 — four weeks from this bulletin. After that date, bulletins like this one will keep being published, will keep describing vulnerabilities that exist in your codebase, and will no longer come with a patch you can apply. Apply the July patch now, and use the remaining window to start the upgrade — our Magento 2.4.6 end-of-life guide covers the realistic 2.4.8-vs-2.4.9 decision and timeline.

APSB26-73 is also a small piece of history: it is the first Adobe Commerce bulletin published under Adobe's new twice-monthly security schedule, which began on 14 July 2026. Security fixes now land on the second and fourth Tuesdays of each month — so the next possible drop is 28 July. Faster fixes are good news, but they double the number of dates your patching process needs to watch; our patch cadence and maintenance windows guide shows how to make that routine rather than reactive. For background on how this bulletin compares to May's, see our coverage of APSB26-49.

For stores on managed Magento 2 hosting, our engineers are staging and applying the July isolated patches now — matched to each store's exact patch level, tested against checkout and admin before production rollout, prioritising stores that use webhook integrations. Sentinel WAF rules covering malicious upload patterns and webhook abuse are active fleet-wide in the meantime, and results are visible in each customer's WHMCS dashboard.

If you're hosting elsewhere and unsure whether your provider even saw this bulletin — that, honestly, is the finding. The gap between "Adobe published a fix" and "the fix is on your server" is the single clearest difference between UK Magento hosting specialists and generic hosts. It's also a fair test to run on us: call and ask what we patched this week.