Magento 2 Patching at Scale

When a Magento CVE lands, the questions are how fast every store gets the fix and how sure you are that it stuck. I built this repo in September 2025 to show the two layers I use to answer them: patch the running stores now, then make sure every project’s next deploy carries the patch for good. The full walkthrough is in how to patch Magento 2 deployments at scale.

#How does live patching work?

It patches the stores that are already running, skipping the normal deploy. That is for the CosmicSting and Session Reaper class of vulnerability, where waiting for a release is the bigger risk. An Ansible playbook applies a patch file straight onto running hosts with ansible.posix.patch, then resets OPcache on each FastCGI socket with cachetool, but only when the patch changed something:

- name: Apply Patch
  ansible.posix.patch:
    src: "{{ patch_file }}"
    basedir: "{{ magento_root }}"
    strip: 1
    state: "{{ (revert is defined and revert | bool) | ternary('absent', 'present') }}"
  register: patch

- name: Flush OPCache
  ansible.builtin.command:
    cmd: cachetool opcache:reset --fcgi="{{ item }}"
  loop: "{{ fastcgi_sockets }}"
  when: fastcgi_sockets is defined and patch.changed

-e revert=1 takes the patch back off. A --limit "client-01,client-02" run tries it on a few stores before the full inventory. The repo puts the whole run at as little as five minutes if you are brave, or a few hours as a slower rolling release.

#How does the Composer layer decide where a patch applies?

By version constraint. Live patches are lost on the next deploy, so the durable layer is a central Composer package of patch definitions that every project requires. Each patch carries a constraint, and only applies where the store’s installed packages match. Dependabot or Renovate then rolls a new patch out to every project through the normal tests, with no rush:

"CVE-2024-34102 (Cosmicsting) - Official Patch": {
    "source": "patches/CVE-2024-34102.diff",
    "depends": {
        "magento/framework": ">=103.0.7 <103.0.7-p2 || >=103.0.6 <103.0.6-p7 || >=103.0.5 <103.0.5-p9 || >=103.0.4 <103.0.4-p10 || >=103.0.3 <103.0.4"
    }
}

The example package ships five patches:

Two example client projects require the package, with full composer.lock files showing the result. The Session Reaper file upload patch is hostep’s work.

Restricting vaimo/composer-patches to known patch sources matters as much as the patches themselves, because by default any dependency can declare one. The supply chain note covers how.

#Where did it go next?

The Session Reaper chain uploads a file through a customer attribute that is not a file type. I fixed that upstream in Mage-OS #174, merged on 8th November 2025.

The Composer layer grew into m2-meta-security-patches, a public package that carries Adobe’s monthly isolated patches as well as the emergency ones, with its own installer.