Magento 2 Security Patches: How to Stay Up to Date

Magento stores are a common target because they handle payments and run on a well known code base. When Adobe publishes a security bulletin, attackers read it too, and automated scans for vulnerable stores often start within days. For some past vulnerabilities, mass exploitation started very soon after the details became public. Applying security fixes is not a task for the next sprint. It needs a routine that works without a crisis.

This article explains the kinds of security fixes Adobe ships for Magento Open Source and Adobe Commerce, how to apply each one, and how to set up a process so a new bulletin is a planned piece of work instead of an emergency.

How Adobe ships security fixes

There are three channels, and it helps to know which one you are dealing with.

Security patch releases

Each supported minor version receives patch releases named with a -p suffix: 2.4.7-p1, 2.4.8-p2 and so on. These contain security fixes and some important functional fixes, without new features. Adobe publishes them on a regular schedule, and announces them with a security bulletin that lists the CVEs and their severity.

A patch release is installed exactly like any Composer upgrade. Moving from 2.4.8-p2 to 2.4.8-p3 is a small change compared to a minor version upgrade, but it still runs setup:upgrade and needs a test pass on checkout.

Isolated hotfixes

When a vulnerability is serious and cannot wait for the next patch release, Adobe publishes an isolated patch for the affected versions. These come as patch files that you apply on top of your current version. Critical issues such as CosmicSting (CVE-2024-34102) were handled this way, with isolated fixes available for versions that could not upgrade immediately.

Quality patches

The Quality Patches Tool distributes individual fixes, mostly functional, some security related. They have IDs like MDVA or ACSD followed by a number. The tool is a Composer package that works on both Magento Open Source and Adobe Commerce.

composer require magento/quality-patches
vendor/bin/magento-patches status
vendor/bin/magento-patches apply MDVA-12345
vendor/bin/magento-patches revert MDVA-12345

status lists the patches that are available for your exact version and whether they are applied. Apply only what you need. Each extra patch is something to check on the next upgrade.

Applying a patch release with Composer

The process is the same as any upgrade, just smaller. On a branch, with a copy of production in your local environment:

composer require-commerce magento/product-community-edition 2.4.8-p3 --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

Use magento/product-enterprise-edition for Adobe Commerce. If your project does not use the root update plugin, update the version constraint of the metapackage in composer.json and run composer update for it. See the 2.4.8 upgrade checklist for the full process when the jump is bigger.

After the update, test the flows that matter: add to cart, checkout with every payment method, customer login, admin login and order management. Security fixes sometimes tighten validation, and an extension that sent slightly wrong data before can start failing.

Applying an isolated patch file

Isolated hotfixes come as diff files. Do not apply them by hand on the server. Add them to your build so every deploy includes them. With cweagans/composer-patches, reference the patch in composer.json against the package it changes:

{
    "extra": {
        "patches": {
            "magento/module-catalog": {
                "Security hotfix from Adobe bulletin": "patches/composer/security-hotfix.patch"
            }
        }
    }
}

Adobe hotfix files are usually written against paths inside vendor/magento and may touch several packages, so check the paths in the diff and split it per package if needed. Then run composer install and confirm the change landed in the vendor files. More on this in the Composer patches guide.

Write down every hotfix you apply. When you later upgrade to a patch release that includes the fix, the patch will fail to apply, and you remove it. Without notes, someone will waste an afternoon finding out why.

What a patch does not fix

A security patch closes the hole. It does not undo what happened while the hole was open. If your store was vulnerable to a critical issue for weeks before you patched, assume someone may have used it and check:

• Admin users you do not recognize, and new integrations or API tokens
• Recently modified files in app, pub, vendor and generated
• Scripts injected into CMS blocks, CMS pages and configuration fields such as the HTML head and footer settings
• For some vulnerabilities, Adobe also recommends rotating the encryption key, because the attack could read it. Follow the bulletin for your case.

If you find anything, follow a proper cleanup process. I wrote a malware cleanup checklist for that situation.

Third party code is part of the attack surface

Many compromised stores were not attacked through core Magento at all. The entry point was an extension with an unauthenticated controller, an upload feature that accepted PHP files, or an old version of a library. Your patching routine should cover:

• composer audit, which checks installed packages against known advisories
• composer outdated --direct, to see which extensions have new versions
• Vendor changelogs and security notices for each paid extension
• Code in app/code that was copied from somewhere years ago and never updated

Adobe also offers a free Security Scan Tool for both editions. You register the domain in your Adobe account and it runs scheduled scans that report missing patches and known malware signatures. It does not replace patching, but it is a useful second check.

A routine that works

The goal is to make security updates boring. What I recommend:

1. Subscribe to the Adobe security bulletins and the Magento release notes, so you know the day a patch comes out.
2. Classify each bulletin. A critical, pre authentication vulnerability means applying the fix within days. Lower severity fixes can go with the next scheduled release.
3. Keep a working local copy of the store that is close to production, with a sanitized database. Without it, every patch becomes a risk. See how to sanitize a database for staging.
4. Keep the deploy repeatable. If deploying requires a person to remember twenty steps, patches get delayed. A script or CI pipeline removes that excuse.
5. Stay on a supported version. Adobe only ships fixes for supported release lines. A store on an end of life version has no clean path to patch the next critical issue.

The last point is the one most often ignored. Patching inside a supported minor version is cheap. Being two minor versions behind when a critical vulnerability appears is what turns a one day job into a rushed upgrade project.

FAQ

How often does Adobe release Magento security patches?

Patch releases follow a regular schedule announced by Adobe, and critical issues can get isolated hotfixes between them. Check the Adobe security bulletins page for the current schedule.

Do Magento Open Source stores get the same security fixes?

Yes. Security fixes are published for both editions as long as the version is still supported. Adobe Commerce only modules get their fixes in the Commerce packages.

Can I apply a security patch without upgrading Magento?

For critical issues Adobe usually publishes isolated patches for supported versions. Add them to your build with composer patches. For everything else, install the next patch release.

What is the difference between a patch release and a quality patch?

A patch release like 2.4.8-p3 is a full version with all security fixes. A quality patch is a single fix applied on top of your version with the Quality Patches Tool.

I am available for freelance Magento and Adobe Commerce work, including patch releases and security fixes. If you need help with this, get in touch.