Critical CVE Response Runbook — Adobe Commerce & AEM

When an Adobe Commerce or Experience Manager bulletin drops, the teams that fare well aren’t the ones with heroics — they’re the ones who already decided what happens next. This is a working template for that decision. It’s deliberately practical, it favors controls Adobe already recommends, and every timeline in it is a target to calibrate, not a promise. Take what fits your environment and your contracts; discard the rest.

Whose signal you follow, and why

A quick orientation, because it sets the entire posture of this runbook.

The CVE system, briefly. A CVE is a catalog number — assigned by a CVE Numbering Authority (CNA) and coordinated by MITRE under CISA. Adobe is its own CNA. It runs its own Product Security Incident Response Team (PSIRT); it investigates, reserves the CVE, builds the fix, publishes the advisory (the APSB bulletins), and scores it — with both a CVSS base score and Adobe’s own Priority rating, its read on exploitation likelihood and how fast to move. NIST’s National Vulnerability Database re-scores the same CVE independently, usually a few days later. So for any Adobe vulnerability there are effectively two voices: Adobe, and everyone else.

Who is contractually on the hook. When an agency or GSI implements Adobe Commerce or Experience Manager, it is building on a platform the customer licenses from Adobe, under Adobe’s contract. The security of that platform — the core code, the patches, the disclosure timeline — is Adobe’s to provide. Adobe owns the PSIRT, the bulletins, the fixes, and the severity ratings. That isn’t a courtesy; it’s the deal the customer paid for.

So the default posture is alignment, not second-guessing. Because Adobe is the party contractually responsible for the platform’s security footprint, their severity and release cadence are the authoritative signal. When Adobe and a third party disagree on urgency, weight the one who has to stand behind the fix. Adobe is, in effect, publishing a roadmap: as they map out the vulnerability picture, their Priority ratings and patch cadence are the prescribed path to a secured platform. The implementer’s job is to be an excellent support vehicle for that roadmap — apply Adobe’s patches quickly, follow their cadence, and use judgment to cover the gap while a fix rolls out.

What this is not. It is not a mandate to take the storefront offline every time a CVE appears — over-reaction is its own failure mode, and it spends the credibility you need for the moment something genuinely warrants an emergency change. And it is not blind trust: you still watch for active exploitation (CISA KEV, public proof-of-concept) and apply compensating controls in the window. But the baseline is disciplined alignment with Adobe, not adversarial re-adjudication of every score.

Where your own judgment carries more weight. Adobe owns the platform. It does not own your configuration, your custom code, your hosting, or your third-party extensions — the Amasty-class supply chain. Those are yours, and that is exactly where independent scrutiny and faster reaction pay off, because no vendor is standing behind them for you.

Before the next bulletin: standing controls

The cheapest CVE to respond to is the one your architecture already blunted. Put these in place while it’s calm, and most future bulletins become a routine dependency bump instead of a fire drill.

• Put the admin behind Adobe IMS SSO. Move Commerce (and AEM) admin authentication to Adobe Identity Management — central sign-on, enforced MFA, instantly revocable access. A large share of these CVEs are only dangerous if the attacker can reach admin; IMS plus network isolation quietly downgrades that whole category on your own infrastructure.
• Lock every endpoint. Admin, REST and GraphQL, integration tokens, file-upload paths. Least privilege, IP-allowlist or VPN-gate what you can, and treat each surface as a target rather than a convenience.
• Centralize entitlements in IT. IMS org membership and Commerce/Experience Cloud licensing provisioned and de-provisioned through IT gives you one control plane and guarantees access dies the moment someone rolls off.

Scan the extension layer

Adobe’s bulletins cover the platform. They say nothing about the third-party modules running inside it with the store’s full privileges — the surface Sansec’s incident data keeps naming as the most common way in. That layer is yours to watch, and it has a public list: magevulndb, Sansec’s database of Magento and Adobe Commerce extensions with known security issues.

It ships as a scanner for n98-magerun, the standard Magento CLI. Install it once:

mkdir -p ~/.n98-magerun2/modules
cd ~/.n98-magerun2/modules
git clone https://github.com/gwillem/magevulndb.git

Then run it from any store root, in a build step or on a schedule:

n98-magerun2.phar dev:module:security -q

It reloads the latest data on every run and returns an exit code you can gate on: 0 clean, 1 a known-vulnerable module is installed, 2 the data couldn’t load. Put it in CI as a required step and exit 1 blocks the deploy automatically, with no human in the loop. Composer-managed shops can get comparable coverage from Roave’s SecurityAdvisories at install time; magevulndb’s advantage is that it also covers Magento 1 and installs composer never managed.

One caveat, so nobody reads too much into a green result: a clean scan means no known issue, not no issue — it’s a floor, not a ceiling. But the floor catches the failure mode that dominates real incidents: a store quietly running a module version with a public, catalogued, already-patched vulnerability. Ever having checked is most of the battle.

Severity → target response

A CVSS score is not a priority; it’s an input to one. The failure mode is treating “Critical” as a feeling instead of a trigger for a response you’ve pre-agreed.

* Targets, not guarantees. Calibrate to your environment, change-control constraints, and — for agencies — each client’s managed-service agreement. An SLA you can’t hit is worse than one you can.

Read the bulletin as an attack graph, not a leaderboard

• Score the batch, not the bug. If one bulletin ships an authorization bypass and an RCE that “requires admin,” assume the chain exists — the low-privilege bug is the on-ramp to the high-privilege one.
• CVSS tells you how bad; other signals tell you how soon. Weigh Adobe’s own Priority rating, CISA KEV, EPSS, and any public proof-of-concept alongside the base score.
• Mind the scoring splits — but let Adobe anchor the schedule. When NIST and Adobe disagree (usually on “privileges required”), the gap is useful for sizing your compensating-controls window and understanding the worst case — but Adobe’s Priority rating and release cadence are what you schedule against, because Adobe owns the fix. Don’t let a higher third-party number stampede you into over-reaction.

The first 24–48 hours on a Critical

1. Confirm exposure. Which environments run the affected product, version, or extension? Keep the inventory that makes this a lookup, not a scramble.
2. Decide patch vs. mitigate per environment.
3. Open the emergency-change ticket with an owner and a deadline.
4. Notify stakeholders — short, factual, no speculation.

Compensating controls: buying time in the gap

You rarely get to patch a production platform blind within an hour. So you buy time:

• Virtual-patch at the edge. A WAF rule (Fastly on Adobe Commerce Cloud, or Cloudflare/Akamai/on-prem) that blocks the exploit signature buys days to test the real fix. Reputable rules for high-profile Magento CVEs typically appear within a day of disclosure.
• Segment the admin panel. IP-allowlist, VPN, or IMS-gate it. The single highest-leverage control for Commerce, because it neutralizes the “attacker needs admin” assumption so many CVEs depend on.
• Disable or lock down the affected surface. Turn off an optional vulnerable feature; rate-limit and tighten a file-upload path at the proxy.
• Last resort: take the surface offline. Reserved for an unauthenticated, actively-exploited Critical with no patch and no workable mitigation. Deciding in advance that you’re willing to pull it is what keeps that call from taking six hours while you’re being drained.

Rolling out the fix without stranding your teams

Here’s the trap most mature shops walk into. The moment a CVE publishes, your artifact scanner — JFrog Xray is the common one — flags the vulnerable magento/* and extension versions in Artifactory. If the policy blocks downloads on Critical, every team’s composer install breaks at once — including teams doing entirely unrelated work — because the platform package sits in everyone’s dependency tree, and Adobe’s fixed build usually isn’t mirrored yet. The governance meant to protect production has just halted all of development.

The resolving principle is simple: block promotion to production, not day-to-day development.

1. Split the repositories. Resolve feature work against a permissive dev/virtual repo where the scanner warns and tracks; gate a strict, release-bound repo where a Critical violation fails the build. Nothing vulnerable ships; nobody’s local build dies.
2. Seed the fix before you flip the block. Sync or upload Adobe’s fixed build (e.g. the -2026-jul security patch) into your registry first, then tighten policy on the vulnerable version. Never block the old build before the new one resolves.
3. Use time-boxed exceptions, never permanent bypasses. Where you must keep building against a not-yet-fixed package, apply an expiring ignore rule scoped to that specific CVE and to dev repos only — with an owner and a hard expiry date.
4. Carry the fix on a dedicated, prioritized branch. Put the composer patch or update on its own security/<bulletin> branch — tested and released separately, given merge priority — so it never waits on, and never blocks, feature work.

Automating the remediation path

The remediation path is mechanical enough to largely hand to machines, with humans reserved for the exceptions:

• Auto-open the work. On a new bulletin, file the tracking issue automatically and let a coding agent — GitHub Copilot’s agent, an autonomous agent, or Renovate/Dependabot for clean version bumps — open the remediation PR overnight: the composer constraint change or patch application. Mornings then start at “review a green PR,” not “triage a blank ticket.”
• Gate on end-to-end tests. Run the PR through a Playwright suite over the critical journeys — checkout, admin login, PLP/PDP, cart. Green makes it eligible for fast or automatic merge; red routes it to a human. Bulletin → auto-PR → test gate → prioritized release becomes a near-hands-off pipeline.

The point isn’t to remove judgment — it’s to spend your judgment on the hard 10%, not on the mechanical 90%.

After the patch

The fix closes the door; it doesn’t evict whoever’s already inside. After remediating a Critical, audit CMS blocks, admin users, and integration tokens that predate the patch. For Commerce, assume payment-data skimming is the endgame and verify accordingly.

The structural option

Everything above assumes you’re the one holding the patch pipeline. That’s a legitimate posture — but it’s a choice. On Adobe Commerce as a Cloud Service, security updates are applied continuously by Adobe, and extensions run out-of-process through App Builder rather than as in-process code in your vendor/ — which removes whole classes of third-party-module risk rather than patching them one at a time. It carries real trade-offs in control and customization, but for teams doing the math on the operational load above, it belongs in the conversation.

Signals to watch

Adobe PSIRT bulletins · CISA Known Exploited Vulnerabilities (KEV) · NIST NVD · EPSS · independent research (e.g. Sansec) · extension-vendor advisories.

This runbook is an independent, community resource — a starting template, not a compliance standard. Adapt the specifics to your own environment, tooling, and contractual obligations. Not affiliated with, endorsed by, or sponsored by Adobe, Inc.