How to Install Magento 2 Security Patches
[Updated: March 16, 2026]
SessionReaper compromised 250+ Magento stores in 24 hours. One unpatched vulnerability gave attackers full server access.
Security patches close these gaps before hackers find them. This guide covers every method to install Magento 2 security patches, from Composer upgrades to the Quality Patches Tool.
Key Takeaways
Magento 2 security patches = targeted code updates that fix known vulnerabilities in Adobe Commerce and Magento Open Source. Adobe releases patches on a monthly cadence since January 2026.
Perfect for: Store owners, DevOps teams, Magento developers, agencies managing client stores
Not ideal for: Magento 1 stores (end of life since June 2020, no new patches available)
What Are Magento 2 Security Patches?
A security patch is a targeted code update that fixes a specific vulnerability. Unlike full version upgrades, patches address one or more security issues without changing core features.
Adobe releases two types of patches for Magento:
- Security patch releases fix vulnerabilities across the platform. These are full version bumps (e.g., 2.4.8 to 2.4.8-p1). Composer handles the upgrade.
- Isolated security fixes target a single critical vulnerability. Adobe publishes these between scheduled releases when a threat is urgent.
The Quality Patches Tool manages both types through a single CLI interface.
Adobe identifies vulnerabilities through its security team, external researchers, and the CVE program. Each patch includes a security bulletin (APSB identifier) that documents the fixed vulnerabilities, their severity scores, and affected versions.
Why Security Patches Are Critical
Unpatched stores are open targets. Two recent attacks prove the point.
SessionReaper (CVE-2025-54236, CVSS 9.1): An input validation flaw in the Commerce REST API allowed attackers to hijack customer accounts and gain server access through remote code execution. Over 250 stores fell in 24 hours after the patch release in October 2025. Six weeks later, 62% of Magento stores remained vulnerable.
CosmicSting (CVE-2024-34102, CVSS 9.8): An XML external entity (XXE) vulnerability enabled unauthenticated remote code execution. Attackers exploited this flaw at scale starting July 2024, injecting malware and stealing payment data across thousands of stores.
These are not theoretical risks. Attackers monitor Adobe security bulletins and reverse-engineer patches to build exploits. The window between patch release and active exploitation continues to shrink.
Unpatched stores face:
- Payment data theft through compromised checkout flows
- Ransomware that encrypts server files until payment
- SEO spam injection that destroys search rankings
- Customer account takeover through session hijacking
- PCI DSS compliance violations that revoke payment processing rights
Your store's security best practices depend on applying patches within days of release, not weeks.
Current Patch Versions (March 2026)
Adobe now releases security patches on a monthly cadence since January 2026. The previous quarterly schedule left stores exposed for too long between fixes.
| Release Line | Latest Patch | Release Date | Support Ends |
|---|---|---|---|
| 2.4.8 | 2.4.8-p4 | March 10, 2026 | April 11, 2028 |
| 2.4.7 | 2.4.7-p9 | March 10, 2026 | April 9, 2027 |
| 2.4.6 | 2.4.6-p14 | March 10, 2026 | August 11, 2026 |
| 2.4.5 | 2.4.5-p16 | March 10, 2026 | August 11, 2026 (extended) |
Source: Adobe Commerce Released Versions
Stores running versions below 2.4.5 receive no patches. Upgrade to a supported release line before anything else.
Check the Magento release schedule for upcoming patch dates.
How to Install Magento 2 Security Patches
Four methods exist. Choose based on your deployment type.
Method 1: Composer Upgrade (Recommended)
This is Adobe's recommended approach for on-premises installations. Composer handles dependency resolution and ensures compatibility.
Step 1: Switch to maintenance mode.
bin/magento maintenance:enable
Step 2: Create a full backup.
bin/magento setup:backup --code --media --db
Step 3: Update to the target patch version.
composer require magento/product-community-edition=2.4.8-p4 --no-update
composer update
For Adobe Commerce (enterprise), replace product-community-edition with product-enterprise-edition.
Step 4: Run database upgrades and recompile.
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
Step 5: Flush the cache and disable maintenance mode.
bin/magento cache:flush
bin/magento maintenance:disable
Step 6: Verify the installed version.
bin/magento --version
Confirm your server meets the current system requirements before starting. Magento 2.4.8 requires PHP 8.3 or 8.4, MySQL 8.4 or MariaDB 11.4, and Composer 2.9.3+.
Method 2: Quality Patches Tool (QPT)
The Quality Patches Tool applies individual patches without a full version upgrade. Use it for isolated security fixes and hotfixes between scheduled releases.
Install QPT:
composer require magento/quality-patches
List available patches for your version:
./vendor/bin/magento-patches status
This displays a table with patch IDs, titles, status, and affected components.
Apply a specific patch:
./vendor/bin/magento-patches apply MDVA-XXXXX
Apply multiple patches:
./vendor/bin/magento-patches apply MDVA-XXXXX MDVA-YYYYY
Revert a patch:
./vendor/bin/magento-patches revert MDVA-XXXXX
Revert all applied patches:
./vendor/bin/magento-patches revert --all
After applying or reverting, flush the cache:
bin/magento cache:flush
QPT logs all operations to var/log/patch.log. Review this file to confirm successful application.
Method 3: Manual Patch via SSH
For stores not using Composer, apply patch files through SSH.
Step 1: Download the patch file from your Adobe account portal.
Step 2: Upload the patch to your Magento root directory on the server.
Step 3: Apply the patch.
cd /path/to/magento/root
patch -p1 < patch_file_name.patch
The -p1 flag strips one directory level from file paths inside the patch. If the terminal reports "File to patch," the patch file paths do not match your directory structure. Adjust with -p0 or -p2 as needed.
Step 4: Revert a patch if needed.
patch -R -p1 < patch_file_name.patch
Step 5: Clear the cache.
bin/magento cache:flush
This method gives you granular control but requires manual dependency tracking. Composer upgrades remain the safer choice for production stores.
Method 4: Cloud Deployment (Adobe Commerce Cloud)
Adobe Commerce Cloud uses ECE Tools to manage patches during the build and deploy pipeline.
Step 1: Update the cloud patches package.
composer update magento/magento-cloud-patches
Step 2: For individual patches, add them to .magento.env.yaml:
stage:
build:
QUALITY_PATCHES:
- MDVA-XXXXX
- MDVA-YYYYY
Step 3: Commit and push to trigger a new deployment.
git add -A && git commit -m "Apply security patches"
git push origin main
The Cloud build pipeline validates patch compatibility during deployment. Failed patches block the deploy and log details for review.
Check the ECE Tools release notes to confirm which security fixes each version includes. Some patches ship as part of the Cloud tools package and do not need separate application.
Before You Apply Any Patch
Three steps protect your store from failed patches.
Back Up Your Store
A full Magento backup includes code, database, and media files. If a patch breaks your store, restore from the backup.
Through the CLI:
bin/magento setup:backup --code --media --db
Through the Admin panel: Navigate to System > Tools > Backups and select the backup type.
Store backups on a separate server or cloud storage. Local backups on the same server do not protect against disk failures.
Enable Maintenance Mode
Maintenance mode blocks customer access during the update. Visitors see a "Service Temporarily Unavailable" page.
bin/magento maintenance:enable
Allow specific IP addresses for testing:
bin/magento maintenance:allow-ips 192.168.1.100
Disable after the patch is verified:
bin/magento maintenance:disable
Test in Staging First
Apply every patch to a staging environment that mirrors production. Run through:
- Frontend checkout flow (add to cart, payment, order confirmation)
- Admin panel operations (product edit, order processing, reports)
- Third-party extensions (payment gateways, shipping modules, search)
- API endpoints (REST and GraphQL)
- Cron jobs (indexing, email, sitemap generation)
Patches that pass staging can move to production. Patches that break staging need investigation before deployment.
After Applying Patches
Verification confirms the patch is active and your store functions correct.
Check the installed version:
bin/magento --version
Run the free security scan tool to detect remaining vulnerabilities. Adobe offers this scan through your Commerce account.
Monitor logs for errors after the patch:
tail -f var/log/system.log
tail -f var/log/exception.log
Verify frontend and admin by testing core operations: product pages, checkout, customer login, admin dashboard.
Flush all caches:
bin/magento cache:flush
Reindex if needed:
bin/magento indexer:reindex
Stores running on managed Magento hosting receive patch notifications and can offload the update process to the hosting team. This reduces downtime and eliminates the risk of misconfigured patches.
SUPEE Patches (Magento 1 Legacy)
SUPEE patches were self-installing scripts released for Magento 1.x. Each SUPEE patch contained fixes for one or more security vulnerabilities across Magento 1.5 through 1.9.
Magento 1 reached end of life in June 2020. Adobe no longer releases SUPEE patches or any security updates for Magento 1.
Stores still running Magento 1 face increasing risk. No new vulnerabilities will receive fixes. The recommended path is migrating to Magento 2 (Adobe Commerce or Magento Open Source) on a supported release line.
Notable SUPEE patches from the Magento 1 era:
| Patch | Release Date | Key Fix |
|---|---|---|
| SUPEE-11346 | June 2020 | Cross-site scripting, arbitrary code execution |
| SUPEE-11219 | October 2019 | Remote code execution, request forgery |
| SUPEE-11155 | June 2019 | SQL injection, cross-site scripting |
| SUPEE-10975 | November 2018 | Remote code execution, information disclosure |
These patches are historical reference only. They cannot protect Magento 1 stores against vulnerabilities discovered after June 2020.
FAQ
How often does Adobe release Magento security patches?
Adobe switched to a monthly release cadence in January 2026. Before that, patches came on a quarterly schedule. Isolated security fixes for critical vulnerabilities can drop at any time between scheduled releases.
What is the difference between a security patch and a quality patch?
Security patches fix vulnerabilities that could be exploited by attackers. Quality patches fix bugs that affect store functionality but do not pose a security risk. The Quality Patches Tool handles both types.
Can I skip security patch versions?
Yes. Composer supports jumping from any patch version to the latest. For example, upgrading from 2.4.8-p1 to 2.4.8-p4 applies all security fixes included in p2, p3, and p4.
What happens if a patch breaks my store?
Revert the patch using the same method you applied it. For Composer: restore from your backup or roll back in version control. For QPT: run ./vendor/bin/magento-patches revert PATCH-ID. For manual patches: run patch -R -p1 < patch_file.patch.
Do I need to apply patches if I use Adobe Commerce Cloud?
Yes. Cloud does not auto-apply security patches. You must update the magento/magento-cloud-patches package and redeploy. Some fixes ship with ECE Tools updates, but security patch releases require explicit action.
How do I check which patches are applied to my store?
Run ./vendor/bin/magento-patches status to see all applied and available patches. For the core version, run bin/magento --version.
Is Magento 1 still receiving security patches?
No. Magento 1 reached end of life in June 2020. No security updates are available. Stores on Magento 1 should migrate to a supported Magento 2 release.
What PHP version do I need for the latest patches?
Magento 2.4.8 requires PHP 8.3 or 8.4. PHP 8.2 is compatible for upgrades but not for new installations. PHP 8.1 support was removed in the 2.4.8 release.
How long does it take to apply a security patch?
A Composer upgrade on a staging server takes 10 to 30 minutes depending on the number of extensions. Testing in staging adds time based on your test plan. Budget 1 to 2 hours for the full process including verification.
Can managed hosting providers handle security patches for me?
Yes. Managed Magento hosting providers monitor patch releases and can apply them to your servers with minimal downtime. This is one of the key advantages of managed hosting over self-managed infrastructure.
Conclusion
Security patches protect your Magento store against known exploits. SessionReaper and CosmicSting proved that unpatched stores face real, immediate consequences.
Apply patches within days of release, not weeks. Use Composer for full upgrades, the Quality Patches Tool for isolated fixes, or ECE Tools for Cloud deployments. Test in staging, back up your store, and verify after every update.
Adobe's monthly release cadence means more frequent updates. Build patching into your regular maintenance workflow so it becomes routine, not a fire drill.