Adobe Commerce Security Patches — What Changes vs What Stays
Adobe Commerce security patches arrive on a quarterly cadence (APSB cycle), but not every quarter deserves the same regression budget. After applying every Magento security patch shipped between 2.4.4 and 2.4.9, we see four recurring patch shapes: Admin XSS, Sales/Payment input validation, Adobe IMS / SSO, and Catalog GraphQL. Each shape touches a different set of vendor/magento modules and demands a different test suite. Here is the categorization, the composer recipe to detect impacted code paths, and the per-shape ETA so you can size the next patch window before Adobe ships it.
Adobe Commerce security patches follow a fixed quarterly cadence (the Adobe Product Security Incident Response APSB bulletin)[1] that ships a tar-ball of vendor/magento/* module changes against Adobe Commerce and Magento Open Source 2.4.4 — 2.4.9. Not every patch deserves the same regression budget. After applying every Magento security patch released since 2.4.4 across kishansavaliya.com client projects, four recurring patch shapes emerge — each touching a different surface area of the codebase and demanding a different test suite. Below is the categorization, the modules each shape touches, the tests to re-run, the typical ETA, and the composer show recipe to pre-detect impact before the window opens.
Every Adobe security patch fits one of four shapes — the shape determines the regression budget
Adobe does not publish a patch taxonomy. They ship a CVE list, a list of affected versions, and a tar-ball[2]. Teams that treat every patch as "needs a full regression sprint" burn 40+ hours a quarter and still miss real regressions. Teams that treat every patch as "safe to apply blind" eventually ship a payment gateway outage. The middle path is shape-based regression — categorize the patch in 15 minutes, size the window from a table, and skip the noise.
The CVE number tells you what Adobe fixed. The shape tells you what you need to retest.
The four shapes below cover every Magento security patch shipped between Q2 2024 and Q1 2026. The shape is determined by the vendor/magento namespace the patch lands in — not by the CVE severity score. A CVSS 9.1 Admin-UI XSS is still a 2-hour patch on most stores; a CVSS 6.3 payment-validation tweak can eat a week.
Shape 1: Admin-UI XSS — safe to apply blind on most stores
The most common patch shape. Adobe finds a stored or reflected XSS in an admin-only template — order grid filter, customer attribute, CMS page editor, system configuration field. The fix lands in vendor/magento/module-backend, vendor/magento/module-ui, or one of the module-*-admin-ui family. Customer-facing surface area: zero.
Modules typically changed
magento/module-backendmagento/module-uimagento/module-cms(admin templates only)magento/module-catalog-admin-uimagento/module-customer-admin-ui
Tests to re-run
- Admin login on a non-admin user (RBAC sanity).
- Admin grid filtering on orders, customers, products.
- System > Configuration save round-trip.
- CMS Page editor save with WYSIWYG enabled.
Typical ETA
~2 hours on a stock store, ~4 hours if you have heavily customized admin grids (Amasty Admin Actions Log, ShopGo Admin Activity Log).
Patch hint
composer show -i 'magento/*' | grep -E '(backend|admin-ui)'
# If the patch tar-ball only touches these modules → Shape 1.Shape 2: Sales\Order\Payment input validation — re-test every payment gateway
The expensive shape. Adobe patches an input-validation bug in Magento\Sales\Model\Order\Payment or in one of the module-payment-* base classes. Every third-party payment extension (Stripe, Adyen, Braintree, Klarna, Mollie, PayPal Plus) inherits from these classes — and the patch often changes a method signature or a sanitization regex that downstream extensions silently rely on.
Modules typically changed
magento/module-salesmagento/module-paymentmagento/module-paypalmagento/module-authorizenet-acceptjsmagento/module-braintreemagento/framework(occasional, when the fix is inMagento\Framework\App\RequestInterface)
Tests to re-run
Every payment method that is enabled on production — not just the default one. The CSV of payment-extension-specific regressions we have shipped against this shape:
Payment method Last regression we caught
- Stripe Elements client-secret double-encoding (APSB23-50)
- Adyen Drop-in 3DS challenge URL stripped (APSB24-03)
- Braintree Hosted device-data nonce truncated (APSB24-40)
- Klarna Payments order_id missing from session (APSB25-14)
+ PayPal Express no regression observed in 2.4.4 — 2.4.9Typical ETA
~12 hours on a store with one payment gateway, scaling to 16–24 hours if you run 3+ gateways in parallel (common on multi-country stores).
Patch hint
composer show -i 'magento/*' | grep -E '(sales|payment|paypal|braintree|authorizenet)'
# Plus all third-party payment extensions:
composer show -i | grep -iE '(stripe|adyen|klarna|mollie|worldpay|amazon-pay)'Shape 3: Adobe IMS / AdminAdobeIms — re-test SSO and 2FA
Adobe Commerce-only (does not ship on Magento Open Source). The magento/module-admin-adobe-ims family handles the Adobe IMS single sign-on flow that lets merchants log into the admin via their adobe.com account, plus the magento/module-two-factor-auth integration with Google Authenticator and Duo.
Modules typically changed
magento/module-admin-adobe-imsmagento/module-admin-adobe-ims-apimagento/module-two-factor-authmagento/module-security
Tests to re-run
- Adobe IMS SSO login → admin dashboard reaches load.
- 2FA enrollment for a fresh admin user (Google Authenticator or Duo).
- 2FA challenge on existing admin user re-login.
- Admin password reset flow (sometimes hooks the same security module).
Typical ETA
~6 hours if you run Adobe IMS on production; ~1 hour if you do not (just run the 2FA smoke test). Open Source stores can skip this shape entirely.
Patch hint
composer show -i 'magento/*' | grep -E '(adobe-ims|two-factor-auth)'Shape 4: Catalog / Search GraphQL — re-test PWA and headless
The shape most often missed by Magento teams that own only the backend. Adobe patches a GraphQL resolver in module-catalog-graph-ql, module-search-graph-ql, or module-quote-graph-ql — and the patch changes the field nullability, the response shape, or the available filter arguments. PWA Studio, Hyvä React companion, and Next.js Commerce storefronts crash on first request.
Modules typically changed
magento/module-catalog-graph-qlmagento/module-search-graph-qlmagento/module-quote-graph-qlmagento/module-customer-graph-qlmagento/module-store-graph-ql
Tests to re-run
- Run the headless storefront's full GraphQL query suite against the patched backend.
- Re-generate Apollo / urql / codegen types — diff the schema for breaking changes.
- PDP load → variant switch → add-to-cart → mini-cart refresh end-to-end.
- Search autocomplete and search results page.
Typical ETA
~10 hours if you run one headless storefront; ~16 hours if you run a PWA Studio storefront and a Hyvä React companion in parallel.
Patch hint
composer show -i 'magento/*' | grep 'graph-ql'The patch-shape matrix at a glance
The four shapes mapped to modules, tests, and ETA — pin this table on the upgrade window's Slack channel so the merchant sees the regression budget before they sign the change request.
| Patch shape | Primary modules | Tests to re-run | Typical ETA |
|---|---|---|---|
| Shape 1: Admin-UI XSS | module-backend, module-ui, *-admin-ui | Admin grid, config save, CMS editor | ~2 hours |
| Shape 2: Sales/Payment validation | module-sales, module-payment, module-paypal | Every enabled payment gateway end-to-end | ~12 hours |
| Shape 3: Adobe IMS / 2FA | module-admin-adobe-ims, module-two-factor-auth | SSO login, 2FA enrollment, 2FA challenge | ~6 hours |
| Shape 4: Catalog / Search GraphQL | module-*-graph-ql | Headless storefront query suite, codegen diff | ~10 hours |
The pre-detection recipe — read the patch in 15 minutes
When the next APSB bulletin drops[3], Adobe ships a CSV of affected modules. Translate it to a shape in three commands:
# 1. Pull the patch's list of changed modules from the APSB bulletin.
curl -s https://helpx.adobe.com/security/products/magento/apsb26-XX.html \
| grep -oE 'magento/module-[a-z-]+' | sort -u > /tmp/patch-modules.txt
# 2. Diff against what your store actually has installed.
composer show -i 'magento/*' --format=json \
| jq -r '.installed[].name' > /tmp/installed-modules.txt
# 3. The intersection is the exact set of modules the patch will touch on your store.
comm -12 /tmp/patch-modules.txt /tmp/installed-modules.txtRead the output. If it contains graph-ql, Shape 4. If it contains sales or payment, Shape 2. If it contains adobe-ims or two-factor-auth, Shape 3. Otherwise Shape 1. Schedule the window accordingly.
The composer patch workflow we apply per shape
Magento's official guidance is to apply security patches via the Magento Composer Plugin[4]. The workflow differs per shape only at the smoke-test step.
Apply
composer require magento/magento-cloud-patches:^1.1 --no-update
composer require magento/quality-patches:^1.1 --no-update
composer update --with-all-dependencies
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flushVerify
composer show -i 'magento/*' | grep -E '$(cat /tmp/patch-modules.txt)'
# Every entry should show the patched version.Smoke test (per shape)
Use the test list from the corresponding shape section above. Do not run the "full regression" — it adds 6 hours and catches nothing the shape-specific suite missed.
A patch you cannot rollback in five minutes is a patch you should not apply on a Friday.
Rollback plan that survives a Friday push
Same plan we use for full upgrades. Before applying any security patch:
TAG="pre-patch-$(date +%Y%m%d-%H%M)"
git tag -a "$TAG" -m "Snapshot before security patch APSB26-XX"
tar -czf "backups/vendor-$TAG.tar.gz" vendor composer.lock
mysqldump --single-transaction --no-tablespaces \
-u root -p"$DB_PASS" magento > "backups/db-$TAG.sql"Rollback if the smoke test fails:
git checkout pre-patch-20260520-1040
tar -xzf backups/vendor-pre-patch-20260520-1040.tar.gz
bin/magento cache:flush
bin/magento setup:di:compileRollback time: 4–6 minutes on a stock store. We have triggered this twice in the last year — both times on Shape 2 (payment gateway regression).
What this post is not
This is not a CVE-by-CVE walkthrough. The Adobe Security Bulletins[5] already do that. This is the recurring shape under each quarterly patch so you can size the window before Adobe publishes the bulletin. Next quarter's patch will fit one of these four shapes; the shape determines whether the window is a 2-hour Monday morning or a 16-hour weekend sprint.
Quarterly cadence — what to expect next
Adobe publishes the security calendar at the start of each fiscal year. The cadence since 2.4.4 has been remarkably consistent:
- February APSB — typically Shape 1 + Shape 4 (XSS + GraphQL).
- May APSB — often Shape 2 (payment validation, post-PCI audit cycle).
- August APSB — often Shape 3 + Shape 1 (IMS hardening + XSS).
- November APSB — biggest quarter, usually all four shapes combined.
Block the November window two months early. Black Friday is non-negotiable; a botched November patch eats the merchant's biggest sales week.
FAQ
Do Magento Open Source stores get the same patches as Adobe Commerce?
For Shapes 1, 2, and 4 — yes, the patches are identical and ship simultaneously. For Shape 3 (Adobe IMS), Open Source stores are not affected because the module-admin-adobe-ims family is Commerce-only. The 2FA portion of Shape 3 does apply to Open Source.
Can we skip a quarterly patch if it is only Shape 1 (Admin XSS)?
Technically yes, but it builds technical debt. PCI DSS 4.0 requires "critical" patches within 30 days of release[6]. Most Admin-UI XSS patches are CVSS 8.0+ which falls under "critical". Apply Shape 1 even though the regression cost is low — the audit liability is not worth the saved hours.
How do we test the GraphQL shape (Shape 4) without a staging headless storefront?
Use the GraphQL Voyager schema diff tool against the pre-patch and post-patch schema.graphql dumps:
bin/magento dev:graphql:export-schema > schema-pre.graphql
# apply patch
bin/magento dev:graphql:export-schema > schema-post.graphql
diff schema-pre.graphql schema-post.graphqlAny removed field, changed nullability, or removed argument is a breaking change for the headless storefront. No staging environment required.
What about hot-patches that ship outside the quarterly cadence?
Adobe occasionally ships out-of-band hot-patches for zero-days (CosmicSting, SessionReaper). Treat them as Shape 2 by default — apply within 24 hours, run the payment-gateway smoke test, and accept that you may need a follow-up patch a week later when Adobe ships the "real" fix.
Does this taxonomy apply to Magento 2.4.4 EOL?
Adobe Commerce 2.4.4 reaches end of security support November 28, 2025[7]. After that date, no more patches will ship for 2.4.4. If you are still on 2.4.4 in 2026, the upgrade window is the patch — see our Magento 2.4.9 upgrade guide.
Can we automate the shape detection?
Yes. We ship a small composer plugin to our retainer clients that reads the APSB bulletin URL, intersects with composer.lock, and emits the shape verdict to Slack. Roughly 80 lines of PHP. Not open-source yet; ping us if you want a copy.
Do the times in the ETA column include the merchant communication?
No. Add 1–2 hours for the pre-window brief (downtime estimate, rollback plan, post-window verification) and the post-window report. Half the friction on patch projects is non-technical.
What if a patch touches modules from two shapes simultaneously?
Take the longer of the two ETAs and run both test suites. The November patches usually trigger this (Shape 2 + Shape 4 combined). Do not try to split the patch — Adobe ships them as one atomic composer update.
Related reading
- Magento 2.4.9 upgrade issues — the 5 universal traps
- Magento slow checkout — the 3 actual fixes
- Magento upgrade service
Citations
- Adobe Security Bulletins — Magento product page (helpx.adobe.com/security/products/magento.html)
- Adobe Commerce security patches overview — Experience League
- Adobe Product Security Incident Response (PSIRT) bulletin index
- Magento Quality Patches Tool — Experience League
- Adobe Security Bulletin index — Magento
- PCI DSS 4.0 — Requirement 6.3.3 critical patch timeline
- Adobe Commerce software lifecycle policy
I run quarterly Adobe Commerce patch windows on a fixed-fee retainer with the four-shape regression suite, rollback snapshot, and Slack-delivered shape verdict per APSB bulletin. Fixed quote from $499 audit · $2,499 sprint · ~16h @ $25/hr per quarter. See hire me or my Magento upgrade service.
Related posts
-
When a Magento Patch Breaks Checkout — The 5-Minute Rollback Recipe
You pushed a patch on a Saturday morning. Checkout is now blank, the place-order button does nothing, and Stripe webhooks have stopped firing. This is the 5-minute rollback recipe — four commands, in order — plus the three breakage patterns that cause 90% of post-patch checkout outages on Magento 2.4.4 — 2.4.9 stores, real var/report excerpts, the moment you should stop trying to forward-fix on production, and a 4-item pre-patch staging checklist that prevents the next Saturday call. Written from production incidents I have rolled back at kishansavaliya.com clients between 2024 and 2026.
-
PHP 8.4 + Magento 2 Compatibility — The Implicit-Nullable Trap
PHP 8.4 demoted implicit-nullable parameter types (Type $param = null) to E_DEPRECATED. On Magento 2.4.4 — 2.4.7 vendor code that floods var/log/system.log on every request, and on a hot product page we measured the log growing by 412 MB an hour. Three vendor modules trip every store: Magento_Sales, Magento_Quote, and Magento_Catalog. This post walks the diagnose-grep-patch-verify loop: the one grep that finds every offender across vendor/, the exact patch shape Adobe ships in the 2.4.8/2.4.9 backports, the cweagans/composer-patches workflow when you cannot bump core, the phpstan rule that pins the regression on every future PR, and why the php.ini error_reporting shortcut is a stopgap not a fix.
-
Magento Composer Dependency Conflicts — Diagnose & Fix in 15 Minutes
Every Magento 2.4.7 to 2.4.9 upgrade collides with a composer dependency conflict — laminas-mail pins, symfony/console majors, or php-amqplib downgrades. The official docs recommend hours of trial and error. The faster workflow is `composer why-not`: one command that surfaces the actual blocker in under 60 seconds. This post walks through three production conflict shapes we hit during 2026 upgrades, the exact `composer why-not` invocations, the root-constraint adjustments in `composer.json`, and when to reach for cweagans/composer-patches instead of a version bump. Real package names, real conflict output, real fixes.
