Where Magento 2 patches live now, and how to apply them safely

The link that used to work no longer works. Someone forwards a security bulletin, you click through to the Adobe help page for it, and you get a 404 or a redirect to a generic security landing page. The bulletin ID looked right. The patch is presumably real. But the page that told you which package version contains the fix is gone, and the next hour goes to guessing which of four Adobe properties actually holds it now.

This is not a one-off. Adobe has moved Magento patch distribution several times: from the old magento.com download portal, to composer-delivered patch releases, to the Quality Patches Tool, to knowledge base articles on Experience League, with Cloud getting its own delivery path on top. Old blog posts and old Stack Exchange answers still point at the retired locations. The fix is to stop searching by URL and start searching by source type.

Patches now come from four places, not one

Security bulletins and patch releases. Adobe still publishes security bulletins under the APSB naming scheme, but the bulletin page is an index, not a download. The actual fix ships as a composer package version with a -p suffix on the release line you are already on. If you are on a supported minor line, the security-only patch is a version constraint change in composer.json followed by composer update, not a file you download. When a helpx URL dies, go to the Adobe security bulletin index and to the Adobe Commerce release notes on Experience League. Both list the patch release the bulletin maps to.

Quality Patches Tool (QPT). Functional bug fixes that Adobe has backported but not yet rolled into a release ship through the magento/quality-patches composer package. Each patch has an ID, typically prefixed ACSD or MDVA, and the tool knows which core versions each one applies to. This is where most "known issue in this version, fixed in the next" problems get their interim fix.

Knowledge base hotfixes. Support-issued patches that have not been packaged into QPT yet live as attachments on Adobe Commerce Knowledge Base articles on Experience League. These are plain .patch files. They are the least discoverable of the four, and the most likely to be handed to you by Adobe support in a ticket rather than found by search.

Vendor-bundled fixes. Extension and theme vendors ship their own compatibility and security fixes inside their own package releases. A core patch release can break a third-party module, and the vendor's fix is a version bump on their package, not anything Adobe publishes.

Bookmark the source types. The URLs will move again.

Security patches are a composer version bump

The old model, download a zip and run a shell script, is dead for security patches. On a supported line, the security-only release is just a new version of the metapackage. Check what you are on:

composer show magento/product-community-edition

or magento/product-enterprise-edition on Adobe Commerce. Then move the constraint to the patch release named in the bulletin, run composer update scoped to the metapackage, run bin/magento setup:upgrade, and test. Security-only releases are meant to be low risk, but "meant to be" is not the same as "is". Run them on a staging copy with production data first.

If you are on a line that no longer receives security-only releases, there is no patch to bump to. That is the real message of a dead helpx link on an old install: the problem is not the URL, it is that you are outside the supported window. The fix is a minor upgrade, which is a project, not a patch. That is the kind of work we scope under Magento 2 operations.

Magento Open Source users have the same composer path. Mage-OS also publishes its own distribution with patch releases if you prefer a community-maintained source.

Quality patches go through the tool, not by hand

Install QPT once:

composer require magento/quality-patches
vendor/bin/magento-patches status

status prints every patch the tool knows about, whether it applies to your core version, and whether it is already applied or already included in a release you have. That last column is the important one. Apply a specific patch by ID:

vendor/bin/magento-patches apply ACSD-XXXXX

and revert to back it out. The tool refuses patches that do not target your version, which is the main reason to prefer it over applying the same diff with git apply. On Adobe Commerce Cloud, the same package is invoked during deploy, and you list required patch IDs in .magento.env.yaml rather than running the command by hand.

Do not apply QPT patches speculatively. Apply the ones that fix a bug you have reproduced. Every applied patch is a diff against vendor/ that has to survive the next upgrade.

Hotfix files go through composer-patches, with a manifest

For .patch files from knowledge base articles or support tickets, the reliable route is cweagans/composer-patches. Put the files in a tracked directory, m2-hotfixes/ is the Cloud convention and works fine off Cloud too, and declare them in composer.json:

"extra": {
  "patches": {
    "magento/module-sales": {
      "KB hotfix: order grid timeout": "m2-hotfixes/sales-order-grid.patch"
    }
  }
}

Now composer install reapplies them on every build, and a patch that fails to apply fails the build loudly. That failure is a feature. It means the target file changed, usually because an upgrade already contains the fix or moved the code, and you need to decide rather than silently ship a half-applied diff.

Avoid patching vendor/ by hand with patch -p1. It works until the next composer install, which is usually the next deploy, and then it is gone with no record it ever existed.

Keep a patch ledger and re-verify it on every upgrade

The failure mode we see most often is not a missing patch. It is a patch nobody remembers, applied by a previous developer, reasons unknown, still sitting in composer.json three minor versions later. Keep a PATCHES.md in the repo with one line per patch: ID or file, source URL, what it fixes, date applied, and the core version it targeted.

Then make re-verification part of every upgrade checklist:

1. Before bumping core, run vendor/bin/magento-patches status and note which applied patches are included in the target release. Those get removed from .magento.env.yaml or your apply script.
2. Bump the core constraint and run composer update. Any composer-patches entry that fails is a candidate for removal, not a reason to force it.
3. For each remaining hotfix, re-read the knowledge base article. Adobe updates them to note which release absorbed the fix.
4. Re-run the Adobe Commerce security scan against the staging URL and confirm the bulletin list is clean.
5. Update the ledger.

The whole loop takes an hour on a well-kept install. It takes days on one where patches were applied ad hoc and never written down.

What to do next

Run magento-patches status and composer show on your production codebase today, and compare the output to whatever patch notes exist. If the answer is "there are no patch notes", start the ledger now, with whatever you can reconstruct from composer.json and git history. If you are on a line that no longer receives patch releases, the patch question is moot and the upgrade question is urgent.

If you would rather hand that audit to someone who does this routinely, get in touch and we will scope it.