Adobe Gates magento-cloud-patches Behind an EE Entitlement

It is now official. Adobe’s release notes for magento/magento-cloud-patches say you need an Adobe Commerce EE entitlement to download the package, so you cannot use it to patch Magento Open Source any more. Anyone who tried to pull a recent release with an Open Source key has known that for about a month. The documentation has now caught up.

That note sits at the top of the cloud-patches release notes on Experience League, last updated on 13 October 2026, the same day 1.1.22 shipped the October security fixes.

¶Why Community/Open Source Stores Used It

On paper, cloud-patches is the package that applies required patches to Adobe Commerce on cloud infrastructure. In practice it also worked on any Magento install, cloud or not, Open Source or not. Add it with Composer, run vendor/bin/ece-patches apply in your build and every monthly isolated security patch for your exact version arrived with a package bump. Your own m2-hotfixes/ directory applied on top.

For an agency patching a lot of Open Source stores every month, that saved a lot of work. One composer update per project instead of downloading each month’s patch by hand, checking it against the right version and committing it into the repository.

It was always a workaround. The package was built for Cloud and nobody promised it would keep working for Open Source.

¶Annoyance

Adobe wants stores patched, and patched quickly. Every security bulletin says so, and the move to monthly isolated patches exists to make that easier. Taking away the simplest way Open Source stores had to keep up with those patches works against that.

Nothing secret is being protected here. The Open Source patches themselves are still public. Gating the package does not stop anyone getting the fixes, it just makes every developer patching an Open Source store do more work to get them. More work means patches go on later, and later is the one thing a security patch should not be.

There was zero need for Adobe to be this hostile about it.

¶What is still public

Adobe publishes a machine-readable patch registry at https://repo.magento.com/patch/patch-registry.json, and it does not need credentials. Every entry carries the versions it applies to, the patches it requires, the CVEs it addresses, the release date, the file name and a sha256 of the patch file. The patches download from the same place, also without credentials:

curl -s https://repo.magento.com/patch/patch-registry.json | jq '.'
curl -sO https://repo.magento.com/patch/248p5-2026-10-001-CE.diff

That is enough to patch an Open Source store without cloud-patches. Find the entries for your version, apply them in the order the requires field gives, since the monthly patches are sequential and not cumulative, and check each file against its sha256 before you commit it.

It is also a better source than cloud-patches was. Yesterday I found that the October 2.4.8-p5 patch inside cloud-patches 1.1.22 is missing a file that Adobe’s own registry patch contains. A repackaged copy can drift. The registry is what Adobe actually published.

¶Next

I have released a small open-source Composer plugin, deployecommerce/magento-community-patches, that ships Adobe’s published Magento Open Source patches byte for byte, checks each one against its registry sha256 and applies the ones for your installed version in order on every composer install and composer update. It is the part of cloud-patches that Open Source stores actually relied on, without the entitlement and without the repackaging. Version 1.0.0 is on Packagist:

composer config allow-plugins.deployecommerce/magento-community-patches true
composer require deployecommerce/magento-community-patches

The other option, which Stephan Hochdörfer raised when I posted about this on LinkedIn, is Mage-OS. If Adobe keeps making Open Source harder to run, more stores will ask whether they should still be on it.