Removing Adobe's CVE-2026-75650 Fastly Rules That Break Admin Page Saves

Adobe’s response to CVE-2026-75650 did not stop at the composer patches and the cloud-patches 1.1.21 release. On Adobe Commerce on cloud infrastructure, a set of edge rules also arrived on the Fastly service, added as custom VCL snippets called accord-rce and accord_rce_1.

They are a virtual patch. The point of them is to reject requests carrying the template-directive payloads that the APSB26-146 bulletin covers, at the CDN, before the origin sees them. For a project that cannot deploy the real patch immediately, that is a reasonable stopgap.

The problem is what else they reject.

¶The symptom

Saving a CMS page or block in the admin panel fails. Depending on the theme and the admin’s own error handling you get a Fastly 403 page, a redirect back to the edit form with the content silently unsaved, or a JavaScript error where the save POST returned HTML instead of the JSON the grid expected. Nothing appears in var/log/exception.log or var/log/system.log, because the request never arrived. Magento is not involved.

This is a false positive, and an obvious one once you see it. The snippets match on the shape of a template directive in a request. Page content in Magento is made of template directives: {{block class="..."}}, {{widget type="..."}}, {{media url="..."}}. A content editor saving a page that contains a widget is posting the exact pattern the rule was written to catch. So is anyone saving an email template, a dynamic block or a product description with a media directive in it.

The tell is that the failure follows the content, not the user. Same admin, same page, save a plain paragraph and it works, paste a widget back in and it 403s.

¶Read them before you delete them

Do not delete blind. The snippet contents are not documented anywhere by Adobe, they were pushed to your service rather than committed to your repository, and once the version is gone the only copy is in Fastly’s version history. Record them first:

fastly service vcl snippet describe --service-id="$SID" --version=112 --name=accord-rce
fastly service vcl snippet describe --service-id="$SID" --version=112 --name=accord_rce_1

Swap 112 for your active version. If you do not know it, fastly service describe --service-id="$SID" prints it, and I covered listing and switching versions in more detail in this post on Fastly service versions.

Keep that output. It tells you the type (recv, fetch and so on), the priority and the match itself, which is what you need if you later decide to put a narrower version of the rule back.

¶Clone the active version

Fastly versions are immutable once activated, so you cannot edit the live one. Clone it:

fastly service-version clone --service-id="$SID" --version=active

That prints the new version number, for example Version: 113. Use your own number everywhere below.

¶Delete both snippets

fastly service vcl snippet delete --service-id="$SID" --version=113 --name=accord-rce
fastly service vcl snippet delete --service-id="$SID" --version=113 --name=accord_rce_1

Both. accord_rce_1 is easy to miss because the naming is inconsistent, one hyphenated and one underscored with a numeric suffix, and leaving either in place leaves the 403 in place.

¶Verify, then validate

List what is left on the new version:

fastly service vcl snippet list --service-id="$SID" --version=113

Neither name should appear. Everything else should, including the Adobe Commerce module’s own generated snippets and any custom ones you have added yourself, such as the SessionReaper and PolyShell media blocks.

Then make sure the version still compiles before you put traffic on it:

fastly service-version validate --service-id="$SID" --version=113

This matters more than it looks. Removing a snippet can break a later one that referenced a variable or a backend it declared, and a VCL that fails to compile on activation takes the site down rather than falling back.

¶Activate

fastly service-version activate --service-id="$SID" --version=113

Activation is near instant across the edge. Go and save the CMS page that was failing. It should save.

Rolling back is the same command pointed at the old number, which is the nice part of Fastly’s version model:

fastly service-version activate --service-id="$SID" --version=112

Two things to watch afterwards. The Adobe Commerce Fastly module can push its own VCL from the admin panel, under Stores > Configuration > Advanced > System > Full Page Cache > Fastly Configuration, and clicking upload there creates a further version. That is fine, it clones from active, so it will not resurrect the deleted snippets. But if accord-rce reappears on a new version you did not create, someone or something re-applied it, and on a cloud project that means asking Adobe support who pushed it and telling them why you removed it.

¶Removing the rules does not fix the vulnerability

Worth being blunt about this. The snippets were a virtual patch for CVE-2026-75650. Deleting them because they break content editing puts you back to unmitigated unless the real fix is in place. Confirm it is before or at the same time as you activate the new version:

• On cloud, take the magento/magento-cloud-patches 1.1.21 bump and check vendor/bin/ece-patches status | grep 15587 reports it applied. Note that the entry pins exact patch levels, so a project one patch release behind gets nothing from it.
• Off cloud, apply the VULN-39341 composer patch for your line, or the identical MCLOUD-15587 file out of the 1.1.21 package, then setup:upgrade, setup:di:compile and cache:flush.

I went through both routes, what the patches actually change and where an extended BlockFactory still leaves you exposed, in the patch analysis and the cloud-patches write-up.

If you do want an edge rule as well, write your own from the snippet contents you saved, scoped to the storefront and excluding /admin or whatever your admin front name is. The reason Adobe’s version breaks is that it does not make that distinction.

Adobe’s bulletin is APSB26-146.