Adobe's October 2026 Cloud Patch for Magento 2.4.8-p5 Is Missing a Security Fix

The copy of the October 2026 security patch that ships inside magento/magento-cloud-patches 1.1.22 for Magento 2.4.8-p5 was not the same patch Adobe first published in its own patch registry. It left out one file: the change to vendor/magento/framework/Validator/EmailAddress.php. Every other release line in the same package has it. Adobe has since moved that change into a separate patch, 248p5-2026-10-002-CE.

If you are on 2.4.8-p5 and you rely on cloud-patches for your security fixes, either because you are on Adobe Commerce Cloud or because your build runs vendor/bin/ece-patches apply, you are not fully patched for October.

You can check your own project in a few seconds:

# Is your project missing the change? (run from the Magento root after patches are applied)
grep -n "QUOTED_LOCAL_PART_PATTERN" vendor/magento/framework/Validator/EmailAddress.php \
  || echo "Missing the October 2026 EmailAddress fix"

If the grep finds nothing, the validator change is not in your codebase.

¶Fix

Add Adobe’s 248p5-2026-10-002-CE patch yourself. ece-patches applies anything in m2-hotfixes/ after its own required and optional patches, so that is the place for it:

curl -sS -o m2-hotfixes/248p5-2026-10-002-CE.patch https://repo.magento.com/patch/248p5-2026-10-002-CE.diff
sha256sum m2-hotfixes/248p5-2026-10-002-CE.patch
# 73ed0c04b685db9f321d6bdf6815edb03f74a9f680eb2e0f015e69453f890fe9

On macOS, swap sha256sum for shasum -a 256. The patch contains only the EmailAddress.php change:

diff --git a/vendor/magento/framework/Validator/EmailAddress.php b/vendor/magento/framework/Validator/EmailAddress.php
--- a/vendor/magento/framework/Validator/EmailAddress.php
+++ b/vendor/magento/framework/Validator/EmailAddress.php
@@ -9,6 +9,13 @@
 
 class EmailAddress extends LaminasEmailAddress implements ValidatorInterface
 {
+    /**
+     * Quoted Pattern
+     *
+     * @var string
+     */
+    private const QUOTED_LOCAL_PART_PATTERN = '/^"/';
+
     /**
      * @var string[]
      */
@@ -55,4 +62,18 @@ public function setValidateTld(bool $shouldValidate)
     {
         $this->getHostnameValidator()->setOptions(['useTldCheck' => $shouldValidate]);
     }
+
+    /**
+     * @inheritdoc
+     */
+    public function isValid($value)
+    {
+        if (is_string($value) && preg_match(self::QUOTED_LOCAL_PART_PATTERN, $value)) {
+            $this->setValue($value);
+            $this->error(self::INVALID_FORMAT);
+            return false;
+        }
+
+        return parent::isValid($value);
+    }
 }

In plain terms, it makes Magento’s email validator reject addresses with a quoted local part, such as "something"@example.com, which the underlying Laminas validator otherwise accepts. It is part of the October 2026 security patch. The registry lists several CVEs against the patch as a whole and does not say which file fixes which, so I am not going to guess.

Check it applies against your patched tree before you commit it:

git apply --check m2-hotfixes/248p5-2026-10-002-CE.patch

If a later cloud-patches release ships 002 itself, ece-patches treats your copy as already applied rather than failing the build, but delete it from m2-hotfixes/ at that point anyway so it does not linger.

The longer-term fix is to stop trusting a repackaged copy. Adobe publishes a sha256 for every patch in its registry, so check what you apply against that.

This is also why I built a small open-source Composer plugin, deployecommerce/magento-community-patches, that applies Adobe’s published Magento Open Source patches directly and checks each one against the registry sha256 before applying it. It works alongside cloud-patches too: where a cloud-patches copy leaves out part of Adobe’s published patch, as the 2.4.8-p5 one did here, the plugin applies the missing files itself and says so in the install output.

¶Why it happens

I found this while patching several stores for October. Adobe publishes a machine-readable patch registry at https://repo.magento.com/patch/patch-registry.json. Every entry carries applies_to, area, requires, cves, released, file_name and a sha256 of the patch file.

The entry for 2.4.8-p5 is 248p5-2026-10-001-CE, released on 13 October 2026. Its sha256 was:

6bc72973a4fba37334395c02390f305ccf105e14bb4977c1c7a4a82220dd073b

It requires the July, August and September 2026 patches (248p5-2026-07-001-CE, 248p5-2026-08-001-CE and 248p5-2026-09-001-CE). The monthly isolated patches are sequential and not cumulative, so each month assumes the ones before it are already applied.

The file you could download publicly from https://repo.magento.com/patch/248p5-2026-10-001-CE.diff hashed to that value, as did the copy in Adobe’s October zip.

magento/magento-cloud-patches 1.1.22 was released on the same day, described as “Applies security fixes from APSB26-153”. It carries its own copy of the 2.4.8-p5 patch as patches/MCLOUD-15634__Oct_2026_monthly_release_ce__2.4.8-p5.patch, and that file hashes to:

d94dbb74b6572a96847ceb82edd716a236fedfe7ea368ce334355e29ccee21d4

Different hashes do not have to mean different changes, so I compared the files each patch touches. The cloud copy touches 21 files. Adobe’s registry patch touches 22. The only file missing from the cloud copy is vendor/magento/framework/Validator/EmailAddress.php.

I then checked the other release lines in the same cloud-patches release. The October CE patches for 2.4.4-p18, 2.4.5-p17, 2.4.6-p15, 2.4.7-p10 and 2.4.9 all touch 22 files and all include the EmailAddress.php change. Only 2.4.8-p5 is missing it.

That gap is not covered anywhere else in the package either. The EE and B2B October patches in cloud-patches never contain the change, because it is framework code and lives in the CE patch. So Adobe Commerce projects on 2.4.8-p5 that rely on cloud-patches are missing it too, not just Magento Open Source ones.

It is also harder to spot than it used to be. Since 1.1.15 in July 2026, Adobe only distributes magento/magento-cloud-patches through repo.magento.com and an Adobe Commerce entitlement is needed to download it. The public GitHub repository stops at 1.1.14, so there is no public diff to look at. Comparing hashes against the registry is the quickest way to notice when the two drift apart.

Thanks to Pieter Hoste for the heads up on the standalone patches being fixed.