Monthly isolated security patching policy
To help Adobe Commerce customers apply critical security fixes sooner, Adobe Commerce now delivers monthly isolated security patches on Patch Tuesday (the second Tuesday of the month). See the Adobe Commerce release schedule for dates. These patches are available for Adobe Commerce on Cloud, Adobe Commerce on-premises, and Magento Open Source installations.
An isolated security patch file contains only the code needed to resolve one or more specific security vulnerabilities, delivered as a narrowly scoped code-diff file rather than a full Composer package. Because the changes are specific to security vulnerabilities, they can be reviewed, tested, and applied faster than a security patch release, without triggering the broader dependency resolution and regression testing that a security patch version upgrade requires. Every monthly isolated security patch file is folded into the next full security patch release, so customers can get all the released isolated patch files through the next security patch (-pN) release.
How isolated patches fit with other patch types
Isolated security patches are one of several types of patches Adobe Commerce provides to keep customers secure and up-to-date.
The two types of security patches play different roles:
-
Isolated patches contain only vulnerability fixes and are not cumulative. They don’t bundle previously released isolated patch files. Merchants must apply patches in order, as each new patch assumes earlier ones are in place. To apply an isolated security patch, the installation must be on the latest security-only patch release for its supported line, because isolated fixes are tested exclusively against that version.
-
Security patches (
-pN) are released annually for all supported release lines and deployed through Composer. They include all previously released security, compliance, and quality hotfixes. Adobe may release additional security patches if necessary.
Monthly isolated patch benefits
Vulnerability discovery has accelerated across the industry. AI-assisted analysis tools can now scan large codebases and surface flaws far faster than manual review, shrinking the window between disclosure and exploitation. A monthly isolated patch cadence closes this gap by providing fixes as soon as they are ready instead of waiting for the next scheduled security patch release.
The goal is speed without unnecessary overhead. A ready fix does not sit in queue until the next security patch release, and merchants do not patch more often than necessary. Isolated security patch files resolve that tension: each is a narrow, security-only diff — far simpler to review and apply than a security patch release, because its scope is deliberately limited.
This approach works because single-purpose patches skip the dependency resolution and full regression testing required for Composer releases, allowing them to be built, validated against a known baseline, and shipped quickly. On Cloud infrastructure, these fixes are bundled into Cloud Patches for Commerce — a package merchants update as part of their Composer and deployment workflow. Once updated, the fix applies automatically during deployment with no separate patch file to locate or apply. The manual patch-file workflow described in security bulletins is for on-premises and Magento Open Source installations that do not run the Cloud pipeline.
Apply monthly isolated patches
To apply the monthly isolated security patch file and stay current on the latest fixes, follow the process below:
-
Check the release schedule.
New monthly isolated patch files ship according to the release schedule. Review the corresponding security bulletin for affected components and CVEs. Each bulletin links to release notes with step-by-step instructions for installing that month’s isolated patch file.
-
Check the security status of your Commerce installation using the Commerce Version Tool.
The tool reports which monthly patches are currently installed, which are missing, and which CVEs the installation remains exposed to. This provides a definitive assessment of what action is required, rather than relying on the version number alone.
-
Confirm your baseline version.
Isolated patches are only tested against the latest security-only
-prelease for your line. If you’re behind on that baseline, apply it first. -
Apply all missing patches in order.
Because they are not cumulative, you cannot skip to the newest file.
note NOTE Cloud customers: Check your installed Cloud Patches for Commerce version first. The fix may already be included and applying it manually can create a conflict, or duplicate the fix. -
Match files to your installed components.
Apply only the file that corresponds to your CE, EE, B2B, or other component version.
-
Re-run the Commerce Version Tool to confirm.
Verify the new patch shows as installed and the relevant CVEs now report as protected.
-
Test, then deploy.
Validate in staging before promoting to production, per your normal change process.
Cloud customers can also use Adobe Commerce Patching Automation to apply or revert patches through the Admin panel instead of the manual git and Composer steps above.
Patch actions by deployment type
-p version, download the file matching each installed component, apply in sequence, and verify with the Commerce Version Tool.FAQ
Monthly isolated security patching is a new release policy. The following questions address common concerns.
Do I need every previous isolated patch applied, or just the latest security patch release?
You need both. Before applying an isolated patch, update to the latest security-only -p release baseline. Each patch is tested only against that baseline. Isolated patches are not cumulative, so apply any missed patches in sequence.
For example, if you’re on the current -p release baseline but missed July and August’s isolated patches, apply July, then August, then September. The next full -p release resets the sequence because it includes all previously issued isolated fixes.
Why not just ship one Composer package instead of separate patch files?
In an installation with multiple components—CE, EE, B2B, and Page Builder—a monthly release might require separate patch files because each file targets a specific installed component version. Combining all fixes into one Composer package would reintroduce dependency-resolution issues and require full-surface regression testing—the risks isolated patches are designed to avoid. Cloud customers do not need to apply patches manually. Cloud Patches for Commerce delivers the same fixes through the existing deployment pipeline.
With patches layered on patches, how do I know what security state my installation is in?
With the release of monthly security patches, Adobe Commerce introduced the Commerce Version Tool, a standalone utility that reports which patches are installed or missing and which CVEs your installation is protected against. Rather than relying on version numbers, the tool reads patch metadata and provides machine-readable output for reporting and continuous integration (CI).
Does this mean Adobe has stepped back from cumulative, versioned security releases?
No. The annual -p release remains the primary, cumulative security checkpoint. Isolated patches supplement that cadence for CVEs that cannot safely wait for it. They do not replace -p releases. If you apply the scheduled security patch release for your line each year, you remain on a fully supported path and receive every fix that was ever issued as an isolated file in between.
Doesn’t shipping fixes outside of Composer make a default install less secure?
No. The delivery mechanism does not affect the fix’s security outcome. An isolated patch applies the same code change later included in a full patch (-p) release. Whether the fix is delivered as a Composer package or a standalone file has no bearing on its effectiveness. Merchants who do not apply the patch remain at their existing security baseline until the next scheduled security release. Applying isolated patches can reduce exposure by delivering fixes sooner, rather than waiting for a full release cycle.