Search intent: urgent informational — Magento developers, agencies and merchants who need to know if their store is affected by APSB26-73 and how to patch it today. This guide covers the bulletin at a glance, every affected version, all thirteen CVEs with scores, what the vulnerabilities actually are at code level, step-by-step application for Cloud, on-premises, Open Source and Mage-OS, verification, and the pitfalls that break builds. It complements our Magento 2 developer guide and CI/CD deployment guide.

APSB26-73 — the four-step application path, and the non-cumulative gotcha that causes most failed patch attempts by CodeAtoZ

APSB26-73 is the July 2026 entry in Adobe’s monthly security release cadence for Commerce. The essentials: bulletin ID APSB26-73, published 14 July 2026, priority rating 2, thirteen CVEs resolved across Adobe Commerce, Magento Open Source, Adobe Commerce B2B and Adobe Commerce Events. The vulnerability impacts break down as arbitrary code execution, privilege escalation and security feature bypass. Eight issues are rated critical, three important and two moderate. Crucially, Adobe alongside APSB26-73 also shipped an isolated patch (internally identified as 249-2026-07-001), which lets you remediate without taking a full version upgrade — reducing the integration risk that normally delays security work.

A Priority 2 rating in Adobe’s scheme means there is elevated risk but no known active exploitation; Adobe’s guidance for Priority 2 is to apply the update within a reasonable window rather than as an emergency. Read the official Adobe Security Bulletin for APSB26-73 and the Adobe severity and priority rating definitions for the source detail. Our view: treat APSB26-73 as a this-week job, not a this-quarter job, because of the 9.6 unauthenticated upload issue.

The scope of APSB26-73 is broad — it reaches every supported release line, including the current 2.4.9. Note the “and earlier” qualifier on each entry: if you are behind the listed patch level, you are affected too. Check your version with bin/magento --version before anything else.

Two things worth flagging about the APSB26-73 scope. First, Magento Open Source is only supported back to 2.4.6 here, while Adobe Commerce reaches back to 2.4.4 — if you are on Open Source 2.4.5 or older you are outside the supported window entirely and should be planning an upgrade, not just a patch. Second, if you run Adobe Commerce B2B, it has its own affected version track and its own patch; patching core alone leaves the B2B-specific stored XSS issue (CVE-2026-47995) unaddressed.

Here is the complete APSB26-73 vulnerability list, ordered by CVSS base score. The columns that matter most operationally are “Auth required” and “Admin required” — the issues needing neither are the ones an anonymous internet attacker can reach, and they should drive your urgency.

The headline item in APSB26-73 is CVE-2026-48356 at CVSS 9.6 — an unrestricted upload of a file with a dangerous type, leading to privilege escalation, requiring no authentication and no admin privileges. Its vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:L: network-attackable, low complexity, no privileges needed, though it does require user interaction and crosses a scope boundary. That combination — remote, unauthenticated, high confidentiality and integrity impact — is why APSB26-73 deserves prompt attention despite the Priority 2 label.

Also notable: CVE-2026-48358 (9.1, arbitrary code execution) applies to webhooks only, per Adobe’s note — so its relevance depends on whether you use Commerce webhooks. And five of the thirteen issues (CVE-2026-48356, 47988, 47984, 47997, 47998, 48001) need no authentication at all, meaning they are reachable without a login. Adobe credits the reporting researchers for APSB26-73 as 0x0.eth, T.H. Lassche, Sudhanshu Rajbhar (sudi), wohlie, akashhamal0x01, s (howtoplay) and schemonah — several through Adobe’s HackerOne bug bounty programme.

Adobe’s bulletin gives categories, not mechanics. But because the Mage-OS project ports Adobe’s isolated patch to source and documents what changed, we can see what the APSB26-73 fixes actually do at code level — detail that is genuinely useful when assessing your own exposure. The Mage-OS 3.2.0 security release notes describe the following changes.

Guest cart takeover. The guest cart endpoints did not verify that a masked cart ID actually resolved to a guest cart — meaning a masked ID could be used to reach a signed-in customer’s cart. The fix makes every guest-facing entry point (cart, items, coupons, billing and shipping addresses, payment and shipping methods, totals, gift messages) validate cart ownership before acting, and promotes quote address validation from REST-only to all entry points including GraphQL. This is the most consequential functional change in APSB26-73 and maps to the unauthenticated incorrect-authorization CVEs.

Stored XSS via inline translation. Translated content is now stripped of script, iframe, object, form, style and similar tags along with on* event handlers, and external links are filtered out. Template-injection sanitiser bypass. The UI component data sanitiser could be evaded by embedding a newline inside a ${...} payload; it now matches across newlines. Template injection via product data. Product gallery and product-view-counter data injected into JSON is no longer treated as an interpolatable template. Disabled product disclosure via GraphQL. Disabled products could be surfaced through the CatalogUrlRewrite GraphQL URL resolver.

Customer address media hardening. This is the one that matters for the 9.6 upload issue: the customer_address directory is removed from the allowed media resources, additional dangerous file extensions (hta, mhtml, mht, htc, xht, shtm, php8) are blocked, and nginx.conf.sample gains a deny all rule for /media/customer_address/.

location /media/customer_address/ {
    deny all;
}

Adobe distributes the APSB26-73 remediation as an isolated patch, delivered out-of-band. An important structural point: the isolated patch content is not published to any Magento git tag or Composer package — you download a patch file. The full instructions live in Adobe’s APSB26-73 release note and the composer patch application guide.

Step 1 — Confirm your exact patch level. Run bin/magento --version. Isolated patches for APSB26-73 are tested exclusively against the latest security-only release for each supported line. If you are on 2.4.8-p4, the 2.4.8 patch will not apply — you must first catch up to 2.4.8-p5.

Step 2 — Download the patch for your version. Each line has its own file:

Files are hosted under repo.magento.com/patch/. For 2.4.5-p17 and 2.4.4-p18 the download sits behind authentication: when the browser prompts, enter your Composer public key as the username and your private key as the password. Note that patch downloads bundle independent patches for Community Edition (CE) and Commerce/B2B (EE) — apply the one matching your edition.

Step 3 — Apply it. The procedure differs by hosting model. For Adobe Commerce on Cloud infrastructure, create an m2-hotfixes directory in your project root if it does not exist, drop the .composer.patch file in, then commit and push — the deploy pipeline applies it:

mkdir -p m2-hotfixes
cp /path/to/VULN-XXXXX-2.4.x_COMPOSER.patch m2-hotfixes/

git add -A
git commit -m "Apply APSB26-73 isolated security patch"
git push origin

For Adobe Commerce on-premises and Magento Open Source, upload the patch to your installation root and apply it with patch, then flush the cache:

# unzip the downloaded patch bundle first
unzip 2-4-8-p5-jul-2026.zip

# from the Magento root directory
patch -p1 < VULN-XXXXX-2.4.8_COMPOSER.patch

# if -p1 fails, try -p2
# patch -p2 < VULN-XXXXX-2.4.8_COMPOSER.patch

bin/magento cache:flush
bin/magento setup:upgrade      # if the patch touches schema/DI
bin/magento setup:di:compile   # production mode
bin/magento setup:static-content:deploy -f

For Mage-OS users the path is different and simpler: Mage-OS 3.2.0 ports the APSB26-73 patch to source, so you upgrade rather than apply a patch file by hand.

composer require mage-os/product-community-edition=3.2.0 --no-update
composer update
bin/magento setup:upgrade

Confirming remediation is not obvious, because APSB26-73 does not change your reported Magento version number. Two tools help. First, the Quality Patches Tool, which reports patch status — filter its output for the VULN identifier from your patch file:

# install the tool, then check status (VULN-27015 is Adobe's example)
vendor/bin/magento-patches -n status | grep "27015|Status"

# expected: the patch row reports  Applied

Second — and new with this release — Adobe introduced the Commerce Version Tool, a standalone executable bundled with each monthly security patch. It reports which monthly security patches are installed, which are missing, and which CVEs your installation is protected against. That last capability is genuinely useful for audit trails and for answering “are we covered for APSB26-73?” definitively. Two caveats: it works for both on-premises and Cloud, but it only becomes available after you apply the CE patch file, and Adobe reiterates that Commerce security patches are non-cumulative and must be applied in sequence.

One privacy note worth knowing: Adobe’s patch also ships a vendor/bin/patch-status tool that reports installed-patch state back to Adobe’s registry using your repo.magento.com credentials. Mage-OS deliberately omits this tool from its distribution — so if you diff Mage-OS against Adobe’s APSB26-73 patch and notice it missing, that is by design, not an incomplete port.

Most failed APSB26-73 deployments come down to a handful of predictable problems. Here is the decision table we work through.

The pitfall that causes the most wasted hours with APSB26-73 is the non-cumulative nature of isolated patches. Unlike the old quarterly -p releases, each isolated patch is built against one specific prior patch level and applies cleanly only there. Teams assume “latest patch = applies to everything on the 2.4.8 line” and lose an afternoon to rejected hunks. Check your exact version, catch up if behind, then patch. And as with any change of this kind: staging first, production second, with a recent backup in hand — Adobe explicitly recommends testing on Staging or Integration before Production.