m2-meta-security-patches Swaps vaimo for a New Patch Installer

Since Adobe's isolated patches started rolling out monthly, m2-meta-security-patches has been stretching vaimo/composer-patches well past what it was built for. Dozens of patch files, stacked in order, re-evaluated on every install, against a package set that differs on every store.

The quirks piled up: patches reported as applied against files that no longer carry them (#162), whole patches dropped in silence when a module replaces one of their targets (#7), any installed dependency free to patch your codebase (#157).

#What upgrading involves

Run both of these before composer update, or it stops partway:

composer config --no-plugins allow-plugins.samjuk/magento-patch-installer true
composer config --json extra.magento-patches.trust '["samjuk/*"]'

Composer will not run a plugin it has not been told to trust, and the installer will not read patches from a package nobody has named. One-time setup.

You do not remove vaimo yourself. It is a dependency of the meta-package, so the update removes it, and it reverts its own patches on the way out before the new installer re-applies them from scratch. On a live Magento 2.4.7-p10 store that was 59 of 59 targets applied, one command, no manual steps.

Miss the two lines and the update stops and says so. Add them, run composer install, and it recovers fully. It fails loudly rather than half-patching, which is the behaviour worth having in a security tool.

#It does not fight your other patch tools

If your store runs vaimo or cweagans for its own patches, they keep working.

• No Composer conflict is declared. The plugin conflicts with nothing, so it installs alongside either tool. vaimo, for contrast, declares conflict: cweagans/composer-patches: *, so those two genuinely cannot coexist. That is vaimo's constraint, not mine.
• Command namespaces do not collide. vaimo owns patch:*, cweagans owns patches-doctor, patches-repatch and patches-relock, mine uses magento-patches:*. That last one changed in 0.2.0. It started as patches:*, which dodged vaimo's namespace but not the confusion: Composer treats patch as an abbreviation of patches, so composer patch:status quietly reached my plugin, because vaimo has no such command. Coexisting is only worth anything if you can tell which tool answered.
• It only touches patches it has been told to trust. It reads its own extra.magento-patches declarations from named packages. vaimo's and cweagans' extra.patches are not its business and are left alone.
• It runs at a different point in the lifecycle, after the install completes, rather than before the autoloader is dumped where vaimo sits.

One caveat. If another tool patches the same file in a way that moves the hunks, my plugin reports a CONFLICT for that target rather than applying over it or skipping quietly. Intended, but overlapping patch sets on one file need a human decision.

#What it fixes

Those three in detail, plus one that only shows up on Adobe Commerce. Every one was hit on a real store.

Patches silently stopped being applied. vaimo decides a patch is applied by reading a record of what it applied before, never by looking at the file. A composer reinstall magento/magento2-base puts an unpatched root file back and vaimo still reports [APPLIED]. Your patch tool says the store is patched, the file on disk says otherwise. Found via the August isolated patch, which updates lib/web/underscore.js, a file owned by magento2-base but living at the project root. Reported as vaimo/composer-patches#162, still open. Now every patch is re-checked against the files on disk on each Composer run, so a reverted patch gets re-applied.

Patches that silently never applied at all. If one file in a patch belongs to a package some module replaces, vaimo drops the entire patch without saying so. Reported by a user running outeredge/magento-disable-graphql, which replaces magento/module-catalog-url-rewrite-graph-ql (issue #7). Now patches split per file: the uncoverable target is named in the output and skipped, the rest still applies.

Any installed dependency could declare a patch against your codebase. My February post flagged this and told you to whitelist your patch sources by hand. Reported as vaimo/composer-patches#157, still open and unanswered. Now only packages named in extra.magento-patches.trust may patch anything, so February's advice is the default rather than homework.

Community Edition patches installed on Adobe Commerce and reported success. Verified on a real Adobe Commerce store: patches applied cleanly to the packages both editions share and reported everything green, while the EE-specific code Adobe patches separately went untouched. The meta-package now declares a Composer conflict with magento/product-enterprise-edition and magento/product-b2b-edition, so the install is refused. Mage-OS is still supported, which is why it is a conflict rather than a requirement on magento/product-community-edition.

#Two commands worth knowing

composer magento-patches:status -v   # what is applied, per patch and per target
composer magento-patches:verify      # non-zero exit if anything is missing

Put magento-patches:verify in your pipeline as its own step. A plugin Composer has not been told to trust is skipped silently, and the build still exits 0 having applied nothing.

#This is a beta

2026.09.11-beta2 is tagged a pre-release on purpose. Stores on a stable constraint do not pick it up: one requiring >=2026.02.01 still resolves to 2026.09.08, because Composer filters the beta out on stability.

Opt in with:

composer require samjuk/m2-meta-security-patches:2026.09.11-beta2@beta

Tested so far:

• 82 Magento and Mage-OS images in CI, 2.4.2 through 2.4.9
• live upgrade from vaimo on Magento 2.4.7-p10, 59 of 59 targets applied
• clean install on Magento 2.4.9 with the Hyvä theme, 57 of 57
• the Adobe Commerce refusal has a regression test, because there is no licensed Adobe Commerce image to prove it against at run time

That is CI and a handful of stores, not a proven production track record. Which is why it is a beta, and why I would rather have the feedback now, while the design is still cheap to change.

Issues and findings on SamJUK/magento-patch-installer, or on the release itself.