Adobe Commerce development
Storefront design
Performance & SEO
AI & agentic commerce
Release tracker
Adobe delivers Magento security fixes in three ways. Security patch releases (the "-p" versions, such as 2.4.8-p5) are cumulative and are the main checkpoint for each release line. Isolated security patches are small, non-cumulative patch files released monthly between -p releases, and they only apply if you are already on the latest -p version for your line. Hotfixes are emergency fixes for critical issues such as zero-day vulnerabilities. Most stores need all three: stay on the latest -p release, apply each isolated patch in order, and act on hotfixes straight away.
This guide explains each type, gives a decision flow for your version, and covers how to test patches safely.
The three kinds of security patch
| Type | What it is | Cumulative? | When it arrives |
|---|---|---|---|
| Security patch release (-p) | A full release of your line, numbered -p1, -p2 and so on, containing security fixes plus fixes from prior patch releases. It can also include hotfixes and compliance changes. | Yes. Each -p includes everything before it, including earlier isolated patches. | On Adobe's published release schedule |
| Isolated security patch | A standalone patch file with fixes for one or more specific vulnerabilities only. Not a full Composer package. | No. Missed patches must be applied in order. | Monthly, on Patch Tuesday (the second Tuesday of the month) |
| Hotfix | An emergency fix for a critical issue, such as an actively exploited vulnerability, for all customers on a supported version. | No, and Adobe notes a hotfix does not address all security issues. | When needed |
Adobe also publishes non-security quality patches for bugs, available through the Quality Patches Tool. They are useful, but they are not a substitute for the security patches above.
How -p version numbers work
A -p release is your release line plus a patch number. 2.4.7-p10 is the tenth security patch release for 2.4.7. Moving from 2.4.7-p9 to 2.4.7-p10 is a small, contained change. Moving from 2.4.7-p10 to 2.4.8 or 2.4.9 is a version upgrade, which is a much bigger project. As of May 12, 2026, the latest patches were 2.4.8-p5, 2.4.7-p10, 2.4.6-p15, 2.4.5-p17 and 2.4.4-p18, alongside the 2.4.9 release.
Adobe notes that security enhancements and compliance changes in a -p release may be backward incompatible. That is why even "small" patch releases need testing.
Decision flow: which patch applies to you
Work through these questions in order. Stop at the first one that gives you an action.
- Is your release line still receiving security fixes?
- 2.4.7, 2.4.8 and 2.4.9 are in standard support (2.4.7 until May 31, 2027).
- 2.4.6 is in extended support until August 31, 2027, with quality and security patches for the core application.
- 2.4.4 and 2.4.5 are in a security-only period until May 31, 2027, with limited isolated security fixes only.
- Anything older receives nothing. Action: plan a version upgrade. Patching is no longer an option.
- Are you on the latest -p release for your line? If not, action: upgrade to it first. Isolated patches are tested only against the latest -p version, so applying them to an older patch level is unsupported.
- Has Adobe issued a hotfix for a critical vulnerability that affects you? If yes, action: apply it now, with a short, focused test, and follow any extra steps in the bulletin. Some bulletins require more than code changes, for example rotating keys or credentials.
- Have isolated patches been released since your -p version? If yes, action: apply every one you have not applied, oldest first, using the file that matches each installed component (for example Commerce, B2B).
- Are you on Adobe Commerce on Cloud? Check your Cloud Patches for Commerce version first. Adobe says the fix may already be included and applied automatically during deployment.
- Is a new -p release out? If yes, action: schedule it. It replaces the isolated patches you applied and resets your baseline.
Our Magento release tracker lists the current -p version and support status for each line, which answers the first two questions quickly.
How to apply and test each type
-p releases
Apply a -p release like a small upgrade: update the version constraint with Composer on a branch, run the database upgrade and compile on staging, then test. Use the testing steps from our Magento upgrade checklist, scaled down. Focus on checkout, payments, customer login, Admin access and integrations, since security changes often touch authentication, forms and APIs.
Isolated patches
On-premises and Magento Open Source stores download the patch file from the bulletin's Knowledge Base article and apply it. Adobe's recommended process is:
- Confirm you are on the latest -p release for your line.
- Download the patch file for each component you have installed.
- Apply missed patches in release order, on staging first.
- Check which patches are applied with Adobe's Commerce Version Tool.
- Test, then deploy to production through your normal release process.
Keep the patch files in version control and apply them in your build, not by hand on the live server. That way every environment gets the same code and the patches survive the next deployment.
Hotfixes
Treat a hotfix as an emergency change. Apply it to staging, run a short smoke test of checkout and Admin login, then deploy. Read the bulletin fully, because it may include steps beyond the code change.
Why patching matters for compliance
Adobe's upgrade guide states that merchants must be on the latest patch or security patch to remain PCI-compliant. Adobe also says PCI compliance is the merchant's responsibility to assess, so if you take card payments, confirm your position with your qualified security assessor. This is general information, not legal or compliance advice.
Patching also covers only the Magento code. Adobe does not fix third-party dependencies such as PHP or your database once they reach end of life, so keep the hosting stack current as well.
A simple patching routine
- Monthly, after Patch Tuesday: check Adobe's security bulletins, apply new isolated patches on staging, test and deploy.
- When a new -p release ships: schedule it within a few weeks, outside peak trading.
- When a hotfix is issued: apply it the same day if it affects you.
- Every quarter: check your support end date and plan the next version upgrade before you need it.
Patching reduces risk but does not remove it. If you see signs of compromise, such as unknown Admin users or changed checkout files, follow our guide on what to do if your Magento store is hacked before you patch, so evidence is not lost.
FAQ
Are isolated patches enough on their own?
No. They supplement -p releases and assume you are already on the latest one. Adobe describes the -p releases as the primary cumulative security checkpoint.
Do Magento Open Source stores get security patches?
Yes. Adobe's monthly isolated patching policy covers Magento Open Source as well as Adobe Commerce on-premises and on Cloud, and -p releases are published for both editions.
Can I apply isolated patches to an old -p version?
It is not supported. Adobe tests isolated patches only against the latest -p release for each line, so upgrade to that first.
Keeping patching on schedule
The hard part of patching is not the commands but the routine: checking every month, testing properly and never falling behind. Mistri's Magento support and maintenance service takes on that routine, including monthly isolated patches, -p releases and urgent hotfixes.
Sources
Security patch release notes (Adobe Experience League); Monthly isolated security patching policy (Adobe Experience League); Adobe Commerce lifecycle policy (Adobe Experience League); Adobe Commerce upgrade guide overview (Adobe Experience League).
