How to Install Magento 2 Security Patches (Composer & Manual)

If you manage a Magento 2 store, applying security patches on time is one of the most important maintenance tasks you’ll do. Unpatched stores are a common target for card skimmers, admin takeovers, and data exfiltration scripts, and Adobe releases patches specifically to close these gaps.

This guide covers how to install Magento 2 security patches using both Composer (the recommended approach for most modern setups) and manual patch files (still used for hotfixes that haven’t been rolled into a Composer metapackage release yet). You’ll also learn how to verify a patch applied correctly, what to do when a patch fails, and how to avoid breaking your store in the process.

This is written for Magento Open Source and Adobe Commerce developers who are comfortable with the command line and have SSH access to their environment. It assumes you already have Composer and the Magento CLI (bin/magento) working.

What Is a Magento 2 Security Patch?

A Magento 2 security patch is a targeted code fix released by Adobe to address a specific vulnerability — things like SQL injection, XSS, remote code execution, or authentication bypass issues. Patches are documented in Adobe’s Security Bulletins (found on the Adobe Experience League / Helpx security pages) and are usually referenced by an APSB identifier, for example APSB24-XX.

Security patches differ from general code fixes in two ways:

• They’re usually small, isolated changes to specific files rather than full feature updates.
• They’re time-sensitive. Once a bulletin is public, the underlying vulnerability becomes known to attackers, so delaying installation increases risk.

Adobe distributes these fixes in two main ways:

1. Composer package updates – the patched code is included in a new release of the magento/product-community-edition or magento/product-enterprise-edition metapackage, or in a dedicated quality patch.
2. Standalone .patch files – plain-text diffs you apply directly to your codebase with the patch or git apply command, typically used when you can’t immediately upgrade to a new Magento version.

Why You Need to Apply Magento 2 Security Patches

A few practical reasons this matters beyond “it’s good practice”:

• PCI compliance. If you process card payments, your PCI DSS assessment will typically require evidence of timely patching.
• Public disclosure risk. Once Adobe publishes a bulletin, the vulnerability details (and sometimes proof-of-concept exploits) become public. Automated bots scan for unpatched Magento stores within days of disclosure.
• Admin and customer data protection. Many Magento security patches address vulnerabilities that expose customer PII, admin session tokens, or payment data.
• Extension compatibility. Waiting too long between patches makes each subsequent patch installation harder, since your codebase drifts further from what the patch was written against.

Prerequisites

Before installing any Magento 2 security patch, make sure you have:

• SSH access to the server (or local dev environment) with permission to run Composer and bin/magento commands.
• Composer 2.x installed (check with composer --version); most current Magento 2.4.x releases require Composer 2.
• A staging or local environment that mirrors production. Never apply an untested patch directly to production.
• A full backup of the codebase, database, and media files, or a way to roll back (Git tag, snapshot, etc.).
• Read access to Adobe’s Security Bulletins for your Magento version, so you know which patch ID or version range applies to you.
• Composer authentication keys (public and private key from your Magento Marketplace account) configured in auth.json, since Magento’s private repo requires them.
• Familiarity with your current Magento version: bin/magento --version.

How to Install Magento 2 Security Patches

There are two supported paths. Use Composer whenever possible — it’s the approach Adobe recommends for anything running Magento 2.3+ on a Composer-based install. Fall back to manual patch files only when a Composer-based fix isn’t available yet for your exact version.

Method 1: Installing a Security Patch via Composer

This is the preferred method because Composer tracks dependency versions, resolves conflicts, and keeps your composer.lock file consistent.

Step 1: Check your current version and the target patched version

Confirm your installed version:

bin/magento --version

Then check Adobe’s Security Bulletin for the patch you need — it will list which Magento version(s) contain the fix. Sometimes the fix ships in a minor release (e.g., 2.4.6 → 2.4.6-p1), and sometimes as a standalone quality patch package.

Step 2: Put the site into maintenance mode

bin/magento maintenance:enable

This prevents customer-facing errors while you update dependencies and recompile.

Step 3: Update the affected Composer package

If the fix is part of a patched Magento release (a “-pX” release), update the core packages:

composer require magento/product-community-edition=2.4.6-p1 --no-update
composer update magento/product-community-edition --with-all-dependencies

Adobe Commerce (Cloud/on-prem Commerce) users should use magento/product-enterprise-edition instead of product-community-edition.

If the fix is distributed as a dedicated quality patch package rather than a full version bump, require that package directly, for example:

composer require magento/quality-patches

The magento/quality-patches package ships a CLI tool for listing and applying individual patches:

vendor/bin/magento-patches list
vendor/bin/magento-patches apply <PATCH-ID>

Replace <PATCH-ID> with the identifier shown in the list output that matches the bulletin you’re addressing. Flag: exact patch identifiers change with every bulletin, so always cross-check the ID against Adobe’s official advisory rather than guessing from a blog post.

Step 4: Run setup upgrade and recompile

bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f

setup:upgrade applies any database schema/data patches bundled with the update. di:compile regenerates the dependency injection cache, which is required after any core code change in production mode. static-content:deploy rebuilds static assets — skip this only if you’re running in developer mode.

Step 5: Clear cache and disable maintenance mode

bin/magento cache:flush
bin/magento maintenance:disable

Step 6: Verify the patch applied correctly

Check the patch status:

composer show magento/product-community-edition

or, for quality patches:

vendor/bin/magento-patches status

Confirm the version or patch ID matches what the bulletin specifies, then manually test the specific vulnerability path if Adobe’s bulletin describes reproduction steps (e.g., a specific form or endpoint).

Method 2: Installing a Security Patch Manually (.patch file)

Use this when Adobe releases a standalone .patch file for your exact version and a Composer-based update isn’t yet available, or when you’re on a highly customized codebase where a full version bump isn’t feasible.

Step 1: Download the official patch file

Download the .patch file only from Adobe’s official Security Bulletin page or your Adobe/Magento partner portal. Never apply a patch file from an unverified third-party source — you’d be trusting arbitrary code changes to your production codebase.

Step 2: Copy the patch to your project root

scp MDVA-XXXXX.patch user@yourserver:/var/www/magento/

Step 3: Do a dry run first

Before applying anything for real, test whether the patch applies cleanly:

patch -p1 --dry-run < MDVA-XXXXX.patch

or, if the patch was generated with Git:

git apply --check MDVA-XXXXX.patch

If this reports no errors, you’re clear to apply it. If it reports “hunks failed” or “does not apply,” see the troubleshooting section below before proceeding.

Step 4: Apply the patch

patch -p1 < MDVA-XXXXX.patch

or

git apply MDVA-XXXXX.patch

The -p1 flag strips the leading directory level from file paths in the diff, which is the standard convention for Magento-distributed patches.

Step 5: Recompile and clear cache

Same as the Composer method:

bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

Step 6: Confirm the change

Open the modified files listed in the patch and confirm the diff was applied (or use git diff if your codebase is under version control). Commit the change with a clear message referencing the bulletin ID so future upgrades don’t accidentally overwrite it.

Complete Example: Applying a Quality Patch End to End

# 1. Enable maintenance mode
bin/magento maintenance:enable

# 2. Require the quality patches package
composer require magento/quality-patches

# 3. List available patches and find the relevant ID
vendor/bin/magento-patches list

# 4. Apply the specific patch
vendor/bin/magento-patches apply ACSD-12345

# 5. Rebuild
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f

# 6. Clear cache and go live
bin/magento cache:flush
bin/magento maintenance:disable

# 7. Verify
vendor/bin/magento-patches status

How This Works

• Composer version pinning ensures the exact patched code your bulletin references gets pulled in, rather than a loosely compatible range that might miss the fix.
• setup:upgrade runs any data or schema patches bundled with the release — some security fixes touch database-level logic (e.g., ACL rules), not just PHP files.
• di:compile matters because Magento’s production mode relies on a pre-generated dependency injection cache. If you skip this after a code change, you may still be serving the old, unpatched compiled code.
• Maintenance mode avoids serving half-updated code to customers mid-deployment, which can cause 500 errors or checkout failures.

Common Errors and Troubleshooting

“Patch does not apply” / hunk failures This usually means your codebase has diverged from the version the patch was built against — often due to a previous manual edit to the same file, or because you’re on a different patch level than expected. Compare the file version against the exact release the patch targets; if you’ve customized the file, you’ll need to manually merge the security fix into your customization rather than applying the raw patch.

Composer dependency conflicts Running composer update magento/product-community-edition sometimes surfaces conflicts with third-party extensions pinned to specific Magento versions. Run composer why-not magento/product-community-edition 2.4.6-p1

to see which package is blocking the update, then check if that extension has a compatible release.

White screen or 500 error after applying a patch Usually caused by skipping di:compile or static-content:deploy, or by a stale cache. Run:

rm -rf generated/code/* generated/metadata/*
bin/magento setup:di:compile
bin/magento cache:flush

vendor/bin/magento-patches command not found This means the magento/quality-patches package either isn’t installed or Composer’s bin directory isn’t in your path. Confirm with composer show magento/quality-patches, and run commands with the full path if needed.

Patch appears applied but vulnerability still reproducible Check whether a CDN or full-page cache (Varnish, Fastly) is serving a cached response from before the patch. Purge the CDN cache in addition to Magento’s internal cache.

FAQ

Do I need Magento Commerce (Adobe Commerce) to get security patches, or does Open Source get them too?

Both Magento Open Source and Adobe Commerce receive security patches. Some bulletins apply to both editions; others are specific to Commerce-only features (like B2B or Commerce-specific modules), so always check which editions a given bulletin covers.

Can I apply a security patch without Composer?

Yes, if Adobe has released a standalone .patch file for your version. This is common for older Magento versions still under extended support, or for stores not fully managed through Composer.

What’s the difference between a security patch and a quality patch?

Quality patches (via magento/quality-patches) bundle a broader set of bug fixes, some of which are security-related. Security-specific bulletins from Adobe will tell you explicitly whether the fix is delivered as a quality patch, a version bump, or a standalone patch file.

Will applying a patch break my custom extensions?

It can, if an extension overrides the same file or class the patch modifies. This is why testing in staging first, and checking your extension vendors’ compatibility notes, matters before deploying to production.

How do I know which patches I’ve already applied?

Run vendor/bin/magento-patches status if you’re using the quality patches tool, or check composer show magento/product-community-edition for your current version against Adobe’s bulletin history. Keeping a changelog of applied patch IDs is still the most reliable method long-term.

What happens if I don’t install a security patch?

Your store remains vulnerable to the specific issue described in the bulletin. Since bulletins are public once released, this significantly raises the risk of automated exploitation, particularly for well-known Magento vulnerabilities that get widely scanned for across the web.