m2-meta-security-patches

At the end of 2025 Adobe announced a move from quarterly -p releases to monthly isolated security patches, shipped as loose patch files. Every store then has to pick out the ones for its version, apply them in order, and keep them applied through every Composer install. I wanted that to be one composer require that Dependabot or Renovate keeps current, so I built it and released it on 1st February 2026.

#How does it pick the patches for a store?

By version. Isolated patches are listed per release line and matched on the installed magento/magento2-base. The older emergency patches match on magento/framework version ranges instead. As of release 2026.10.09 the package carries:

• Adobe’s isolated patches 2026-07-001, 2026-08-001 and 2026-09-001, for 2.4.6-p15, 2.4.7-p10, 2.4.8-p5 and 2.4.9.
• Emergency patches for CosmicSting (CVE-2024-34102), Session Reaper (CVE-2025-54236), APSB25-94 and StyleSmuggler (VULN-39341, CVE-2026-75650).

Isolated patches stack: September’s will not apply unless August’s is already on. The definitions say so per release line, in patches/isolated/patches.json (trimmed):

"2.4.6-p15": {
    "base": { "magento/magento2-base": "2.4.6-p15" },
    "cumulative": true,
    "patches": [
        { "id": "2026-07-001", "source": "2026-07-001/2.4.6-p15-CE.patch", "label": "July Isolated" },
        { "id": "2026-08-001", "source": "2026-08-001/2.4.6-p15-CE.patch", "label": "August Isolated" },
        { "id": "2026-09-001", "source": "2026-09-001/2.4.6-p15-CE.patch", "label": "September Isolated" }
    ]
}

CI applies the package across 70 Magento and 12 Mage-OS versions, listed in tests/matrix.json and run on the Magento CI testing images.

#How does the installer know a patch is applied?

It looks. magento-patch-installer is a separate Composer plugin that takes every verdict from git and the files on disk, not from a record of what it applied last time.

Each patch is split into one fragment per target file, then each fragment is checked with git apply. If git apply -R --check succeeds, the change is already on that file. If git apply --check succeeds, it can go on. A file that is there but matches neither side is a conflict: reported against that one file, and never overwritten.

The installer’s own page covers the rest: exit codes, the deploy gate, and running alongside vaimo or cweagans.

#What went wrong

The package started on vaimo/composer-patches, and that held until the monthly patches piled up. vaimo reported patches as applied against files that no longer carried them, found when the August patch touched lib/web/underscore.js (vaimo#162). It dropped whole patches without a word when a module replaced one of their targets (#7). And it let any installed dependency declare patches, which my February post told people to lock down by hand.

From 2026.09.11-beta2 the package applies through its own installer instead. On a live Magento 2.4.7-p10 store the switch applied 59 of 59 targets in one command. The write-up has the upgrade steps. Release 2026.10.09, on 9th October 2026, was the first stable release to use it.