Adobe’s shipped its July 2026 isolated security patch, APSB26-73, covering the 2.4.6, 2.4.7, 2.4.8 and 2.4.9 lines. If you’re trying to work out whether you need it, and how to actually get it applied without breaking your build, here’s the short version.
Am I affected?
APSB26-73 applies to the latest patch release for each supported minor line. If you are not on the latest patch release for your minor version, you will need to catch up first before applying this month’s patch.
2.4.6-p152.4.7-p102.4.8-p52.4.9
These are independent patches for Community Edition (CE) and Commerce/B2B (EE) which are all bundled in the patch downloads — check the official patch download page.
Isolated patches are non-cumulative
Unlike the old quarterly -p releases, isolated patches are not cumulative. Each patch is built against one specific prior patch level, and will only apply cleanly there. APSB26-73 for the 2.4.8 line only applies to 2.4.8-p5 — not p4, not p3. If you’re behind, the patch will fail to apply (or worse, partially apply) until you catch up first.
I tested this directly: force-applying the 2.4.8 patch against 2.4.8-p4 fails with real hunk conflicts across half a dozen files, not just a version-check refusal. It’s not a formality, the underlying code has genuinely drifted.
Practically, this means:
- Skipping a previous patch means you can’t just apply this month’s patch and call it done. You need last month’s first.
- Automated patch tooling that pins to a version range instead of an exact version is going to silently break the day the code underneath shifts.
Gotcha: the nginx.sample.conf hunk breaks fresh installs
The distributed patch files for July also touch nginx.sample.conf. On a fresh/CI install that file doesn’t exist yet at patch time — it’s copied into the project root by a Composer plugin that runs after patches are applied. So the hunk fails, and it takes the whole composer install down with it.
It’s not a version-gating problem, the file target just doesn’t exist yet in that install order. Applying it against vendor/magento2-base instead wouldn’t reliably fix it either, since that copy step won’t overwrite an existing root-level file — you’d end up with the vendor copy patched and the project-root copy not, which is worse.
Simplest fix: drop the nginx.sample.conf hunk from the patch entirely. It’s a sample file, not something you should have live in production anyway. I’ve done this in m2-meta-security-patches 2026.07.14-p1 — if you’re applying Adobe’s patch files directly rather than through the meta-package, strip that hunk yourself before running composer install on a clean checkout.
Applying it manually
Adobe includes a Commerce Version Tool (vendor/bin/patch-status) with each CE patch, which reports which monthly patches are installed, which are missing, and which CVEs you’re covered against. It’s only available after you’ve applied the CE patch file once — see Adobe’s KB article for the full download/apply process.
Applying it automatically
If you’re maintaining more than one store, manually tracking exact patch levels per site gets old fast. I maintain m2-meta-security-patches — a Composer meta-package that bundles Adobe’s isolated and emergency patches with exact version constraints, so composer update only ever applies a patch when your installed modules genuinely match what it was built for.
composer require samjuk/m2-meta-security-patches:">=2026.07.14"Supply chain note:
vaimo/composer-patcheslets any dependency declare patches by default. Restrict it to this package:composer config --json "extra.patcher" '{"sources":{"packages":["samjuk/m2-meta-security-patches"]}}'— see restricting vaimo/composer-patches to trusted packages for gotchas that make this silently no-op if done wrong.
Pair it with Dependabot/Renovate and you get a PR the moment a new patch is relevant to your exact version — no manual tracking required. See my earlier post on the meta-package approach for the full reasoning.
Related reading
- Adobe’s official isolated patch process — KCS ka-37421
- Adobe’s Isolated Patch Strategy: A Community Response
- Magento 2 Polyshell RCE: Technical Breakdown, PoC & Patch Guide — for context on why applying patches promptly and correctly actually matters