Download the PHP package disrex/magento-security-patches without Composer

On this page you can find all versions of the php package disrex/magento-security-patches. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package magento-security-patches

disrex/magento-security-patches

Adobe's security patches for Magento Open Source, Adobe Commerce and B2B, as one Composer package. disrex/magento-patch-installer applies them, checks on every Composer run that they are still applied, and fails the run when one is missing or conflicts.

Every file in patches/adobe/ comes byte for byte from https://repo.magento.com/patch/, and bin/sync-registry refuses a download whose sha256 differs from Adobe's patch registry. registry/patch-registry.json is the registry as it stood at the last sync, so git diff on it shows what Adobe changed.

What a store gets

Store Patches
2.4.7-p10, 2.4.8-p5, 2.4.9 Every monthly isolated patch from July 2026 on, in order, plus VULN-39341 (APSB26-146)
2.4.6-p15 July and August. Adobe serves September and later only to Commerce licence holders
Older patch levels from 2.4.4 on VULN-39341, plus SessionReaper (VULN-32437) below 2.4.8-p3, 2.4.7-p8 and 2.4.6-p13, and CosmicSting (VULN-27015 v2) below 2.4.6-p6 and 2.4.4-p9. The monthly patches need the newest -p of the line, so upgrade first
Adobe Commerce The Open Source patches above, plus the EE line for its magento/product-enterprise-edition version
B2B Also the B2B line for its magento/extension-b2b version (1.4.2-p10, 1.5.2-p5, 1.5.3)
Mage-OS Nothing. Mage-OS has no magento/magento2-base; it ships Adobe's fixes in its own releases

Each area is its own cumulative line, gated on the area's package, so an Open Source store never sees the EE or B2B patches. Adobe's EE and B2B patches only touch EE and B2B modules. Files Adobe serves only to Commerce licence holders are left out, and so is every later month of that line, since a chain may not have a gap. bin/sync-registry prints them as skipped.

Hand-picked hotfixes

Adobe's registry starts in July 2026. Older emergency hotfixes for vulnerabilities that were exploited in the wild live in patches/hotfixes/, maintained by hand; bin/sync-registry never touches that directory.

Patch Vulnerability Applies to
24x-VULN-32437-CE SessionReaper, CVE-2025-54236 (APSB25-88) 2.4.4 to 2.4.4-p15, 2.4.5 to -p14, 2.4.6 to -p12, 2.4.7 to -p7, 2.4.8 to -p2
246x-VULN-27015-CE CosmicSting, CVE-2024-34102 (APSB24-40) 2.4.6 to 2.4.6-p5
244x-VULN-27015-CE CosmicSting, CVE-2024-34102 (APSB24-40) 2.4.4 to 2.4.4-p8

CosmicSting leaks the encryption key, so a store that gets VULN-27015 must rotate its key afterwards; a key stolen before the patch keeps working until then. Version-based scanners such as eComscan keep reporting SessionReaper after the hotfix, because they only look at the version.

Installer 0.1 does not know the optional field and would apply such a patch on every store. The release that adds the first optional patch here must raise the installer requirement to ^0.2.

To add a hotfix: download it from Adobe's own URL, take the patch file out of the zip unchanged, and add an entry to patches/hotfixes/patches.json with a base constraint on magento/magento2-base that covers exactly the versions Adobe lists. Put the URL and both sha256 values in the description, and test it with the installer's end-to-end check on a store of each version it covers.

composer magento-patches:status on a store shows what it has and what it lacks.

Adding it to a project

Without the allow-plugins line, a CI run skips the plugin without a word and exits 0 on an unpatched store. Without trust, the run fails and names this package.

Then add a check after composer install in the build job of .gitlab-ci.yml, so a store that is not fully patched stops the pipeline before anything reaches the server:

Exit code 0 means every patch is applied, 1 means one is missing, 2 is a conflict and 3 a configuration error.

A patch that breaks something in one project can be switched off in that project's root composer.json, with the reason:

Commit magento-patches.lock after the first composer update; it lists every patch the project takes, so each merge request that bumps this package shows which patches arrive or change. Renovate runs Composer without plugins and leaves that file as it was; set up the post-upgrade task from CI and deploys so it rewrites the lock.

Remove other copies of the same patches when a project moves to this package: disrex/stylesmuggler-adobe-patches, Adobe patch files in extra.patches, and a vendor/bin/magento-patches apply MCLOUD-... script for the monthly releases.

Monthly update

Adobe releases on the second Tuesday of the month.

The script downloads what is new, refuses a file whose hash differs from the registry, and regenerates patches/adobe/patches.json. Adobe sometimes changes a patch after release day under the same name, or splits part of it into a new one, as it did with the October 2026 patch for 2.4.8-p5. The script then replaces the file and prints updated, and the installer swaps the old version for the new one on stores that already have it.

Before tagging, run the installer's end-to-end check on a copy of a store on each line:

It installs this package in a copy, checks that every patch is in place, that Adobe's vendor/bin/patch-status lists nothing missing, and that a reinstalled core package is patched again. Then tag the next version: a minor version (0.2.0) for a new month of patches, a patch version (0.1.1) when Adobe re-issues or fixes a file. Renovate opens a merge request in every project for each tag, with the release notes listing the patches.

License

The patch files are Adobe's changes to Magento Open Source and Adobe Commerce, under the same OSL-3.0 licence as Magento. How the installer applies them is documented at https://disrex-group.github.io/magento-patch-installer/.

All versions of magento-security-patches with dependencies

PHP Build Version
Package Version
Requires disrex/magento-patch-installer Version ^0.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package disrex/magento-security-patches contains the following files

Loading the files please wait ...