Magento APSB26-73 (July 2026): How to Apply Adobe's First Big Isolated Security Patch

What APSB26-73 is, and why there is no 2.4.9-p1

Until this year, a Magento security release meant a new Composer package. 2.4.8-p4 became 2.4.8-p5, you bumped the constraint, ran composer update, done. In January 2026 Adobe announced a different cadence: monthly security-only isolated patches, plus one cumulative full patch release per line per year, shipped each May. APSB26-73, published July 14, 2026 at Adobe priority 2, is the first heavyweight release under that model.

An isolated patch is a plain diff file, one per release line, and it is non-cumulative. You download it from Adobe KB article ka-37421 and apply it to the codebase directly. Composer never sees it. The latest Composer-installable versions are still the May 12, 2026 wave from bulletin APSB26-49: 2.4.9 GA, 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17, and 2.4.4-p18. There was no June bulletin, and there is no 2.4.9-p1 or 2.4.8-p6 package on repo.magento.com. Adobe refers to the patched state with date-suffixed labels like 2.4.9-2026-jul, and the 2.4.9-line patch carries the internal ID 249-2026-07-001.

If you want the background on what a security patch touches and what it leaves alone (your theme, your modules, the database schema), I wrote that up separately in what changes and what stays in a Magento security patch.

The five CVEs in plain English

Five CVEs headline APSB26-73. Here is the short version:

The scoring on CVE-2026-48358 deserves an honest flag. NVD scores it 10.0: network vector, no privileges required, no user interaction. Adobe’s own vector says 9.1 and requires high privileges. Those two descriptions are not the same bug profile, and I cannot tell you which team is right. My advice does not change either way: a code execution flaw in a component that talks to the outside world is a drop-everything patch.

The Mage-OS project ported the 2.4.9-line patch (249-2026-07-001) into source the same day, which gives us an unusually clear view of what actually changed:

• Guest cart takeover fix. Masked cart IDs were not validated as actually belonging to guest carts, so logged-in customers’ carts could be exposed.
• Stored XSS via inline translation, now with tag and event-handler filtering.
• Template-injection sanitizer bypass using newlines in UI components.
• Template injection through product gallery and counter data.
• Disabled-product disclosure through the GraphQL CatalogUrlRewrite resolver.
• customer_address media hardening: removed from allowed resources, plus more blocked file extensions.

That last one hits close to home: I blocked public /media/customer_address at the nginx level myself after cleaning up a defacement last month. Upstream hardening is overdue.

As of July 18 there is no known exploitation in the wild. Do not let that slow you down. SessionReaper (CVE-2025-54236) went from bulletin to mass exploitation in about six weeks, and attackers diff public patches within days of release.

The exact-version trap: check this before you touch anything

An isolated patch is generated against exactly one code state. Because it is non-cumulative, it contains only the July changes, expressed as diff hunks against the latest May patch level of each line. If your files do not match that state, patch cannot find its context lines and the hunks fail. On an older -p level you get conflicts across half a dozen files, and a partially applied security patch is worse than no patch at all.

The 2.4.5 and 2.4.4 zips sit behind extended-support credentials. B2B merchants are in scope too: B2B 1.5.3, 1.5.2-p5, 1.4.2-p10, 1.3.4-p17, 1.3.3-p18 and earlier are all affected.

One date to circle in red: 2.4.6-p15 plus this isolated patch is the end of the road for the 2.4.6 line. Support ends August 11, 2026. I published a separate post today on your options before Magento 2.4.6 goes end of life, because patching today does not make that deadline go away.

Seven ways to apply APSB26-73

Same patch, seven delivery mechanisms. Pick the one that matches your hosting and your team. All of them assume a staging run first and a maintenance window for production.

1. On-prem, manual: patch -p1 or git apply

Adobe’s documented path. Download the line-specific zip from KB ka-37421, unzip it in the Magento root, dry-run, apply, flush caches:

bin/magento maintenance:enable
unzip 2-4-8-p5-jul-2026.zip
patch -p1 --dry-run < 2-4-8-p5-jul-2026.composer.patch
patch -p1 < 2-4-8-p5-jul-2026.composer.patch
bin/magento cache:flush
bin/magento maintenance:disable

If -p1 complains about paths, try -p2. A pure isolated patch touches vendor code, so there is no setup:upgrade and no di:compile step: flush caches and smoke-test checkout, admin login, and any webhook endpoints. If the docroot is a git checkout, git apply gives you nicer ergonomics:

git apply --check 2-4-8-p5-jul-2026.composer.patch
git apply 2-4-8-p5-jul-2026.composer.patch

2. Adobe Commerce Cloud: m2-hotfixes/

On Cloud you never patch the running containers by hand. Commit the patch file into m2-hotfixes/ in the project root and ece-tools applies it during deploy:

mkdir -p m2-hotfixes
cp 2-4-9-jul-2026.composer.patch m2-hotfixes/
git add m2-hotfixes
git commit -m "Apply APSB26-73 isolated security patch"
git push
# after deploy, confirm it registered:
vendor/bin/magento-patches -n status | grep "27015\|Status"

3. cweagans/composer-patches: pin it for CI

For teams where every environment is built from composer install, reference the patch in composer.json so it reapplies on every build:

"extra": {
    "patches": {
        "magento/magento2-base": {
            "APSB26-73 isolated security patch (249-2026-07-001)": "patches/2-4-8-p5-jul-2026.composer.patch"
        }
    }
}

One real gotcha here: the July patch modifies nginx.sample.conf, a file that does not exist yet during a clean composer install checkout, so that hunk fails on fresh installs. Strip the nginx.sample.conf hunk from the copy you commit if your pipeline builds from a clean checkout.

4. Community meta-package

composer require samjuk/m2-meta-security-patches:">=2026.07.14"

Maintained by Sam James, built on vaimo/composer-patches. It bundles the isolated patches so a normal composer flow picks them up. It is third-party and not Adobe-official, so read what it pins before trusting it on production. For a solo store it is the least ceremony of any option here.

5. Catch up first if you are behind

On 2.4.8-p3? 2.4.7-p8? The isolated patch will not apply. Upgrade to the latest patch level of your line first, then apply the July patch on top:

composer require-commerce magento/product-community-edition=2.4.8-p5 --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
# now apply the isolated patch using method 1, 2, or 3

Treat the catch-up and the patch as one change window. Shipping the -p5 upgrade and "doing the patch next sprint" leaves you exposed to a published 10.0 for weeks.

6. Full jump to 2.4.9, then still patch

composer require-commerce magento/product-community-edition=2.4.9 --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile

The counterintuitive part: 2.4.9 GA shipped May 12 and predates this bulletin, so after the jump you still apply the July isolated patch (2-4-9-jul-2026.zip) on top. If you take this route, read my post on the five universal 2.4.9 upgrade traps before you start; a minor-line jump is a different animal than a patch.

7. Mage-OS: upgrade to 3.2.0 instead of patching

Mage-OS released 3.2.0 on the same day, July 14, with the 249-2026-07-001 fixes ported directly into source. No patch file juggling, just a version bump:

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

3.2.0 also fixes a Mage-OS-specific installer issue: a world-readable env.php backup written without a .php extension, now written with 0600 permissions. Day-one security parity is exactly the argument Mage-OS has been making.

Verify the patch actually landed

Here is the part that surprises everyone the first time:

bin/magento --version
# still prints 2.4.8-p5. This is expected.
vendor/bin/patch-status
# reports isolated patch coverage across CE, EE, B2B, PageBuilder

The version string does not change because Composer metadata did not change. Adobe’s docs use date-suffixed labels for the patched state, but no built-in command prints them. The Commerce Version Tool, exposed as vendor/bin/patch-status, is the authoritative check, and it covers the B2B and PageBuilder patches you might otherwise forget.

Then verify behavior, not just files: place a guest order, log into the admin, and exercise any webhook integrations, since Webhooks is where the 10.0 lives. On staging, keep the patch --dry-run output around. If the dry run was clean on staging but noisy on production, the two environments were not on the same code state, and that is a finding worth chasing on its own.

Rollback plan: build it before you patch

Every patch window needs a pre-agreed exit. Tag the pre-patch state (or take a full code backup if you deploy from artifacts), and know the reverse command for the apply method you used:

git tag pre-apsb26-73

# reverse a patch applied with patch -p1:
patch -R -p1 < 2-4-8-p5-jul-2026.composer.patch

# reverse a patch applied with git apply:
git apply -R 2-4-8-p5-jul-2026.composer.patch

bin/magento cache:flush

If checkout breaks after the patch and you need the full triage sequence, not just the reverse command, I keep a dedicated playbook for exactly that: the patch-broke-checkout rollback recipe. Reversing this particular patch also reverses the guest-cart and webhook fixes, so treat rollback as a short-lived state while you debug, not a resting place.

What I would do, store by store

My honest ordering, as of July 18:

• Today: run composer show magento/product-community-edition on production and staging. Half the pain in this bulletin comes from environments quietly not on the same level.
• Already on 2.4.9 / 2.4.8-p5 / 2.4.7-p10: staging first, then production this week with method 1 (on-prem) or method 2 (Cloud). The apply itself takes minutes; the smoke test takes longer than the patch.
• Teams with CI: method 3, with the nginx.sample.conf hunk stripped, so no future composer install silently builds an unpatched image.
• Behind a patch level or more: method 5 as one combined window. Priority 2 plus a 10.0 plus the SessionReaper precedent means this is a this-week job, not a next-quarter ticket.
• On 2.4.6: patch now, and book your exit plan before August 11. This patch is the last one your line gets.
• On Mage-OS: take 3.2.0 and move on with your life.

If you are more than one patch level behind on a production store, this stops being a five-minute job and becomes a small project with a test matrix, and that is exactly the shape of work I take on through my Magento upgrade service.

Sources: Adobe security bulletin APSB26-73, Adobe KB ka-37421 (patch downloads), Adobe Commerce release schedule, NVD: CVE-2026-48358, Mage-OS 3.2.0 release notes.