How to Check Missing Magento Security Patches on 2.4.9: A 7-Step Checklist

Step 1: know what should be there

Since July 2026 Adobe ships Magento security fixes as monthly isolated patches instead of Composer releases. On 2.4.9 GA, this is the full list so far:

The monthly ones all landed on the second Tuesday. The zips follow one naming pattern, https://repo.magento.com/patch/2-4-9-jul-2026.zip, 2-4-9-aug-2026.zip and so on, and a zip can also hold EE, B2B or PageBuilder files for Adobe Commerce stores. The months build on each other, so a store on 2.4.9 needs every row above, applied in order. The details of the newest one are in my APSB26-153 October patch guide.

Step 2: confirm the exact base version

composer show magento/product-community-edition | grep ^versions
# versions : * 2.4.9

Isolated patches are built against one exact version per line: 2.4.9, 2.4.8-p5, 2.4.7-p10. If this prints 2.4.8-p4, every patch check below is meaningless. Your first job is the Composer upgrade to the latest -p level of your line, and then the patches.

Step 3: does vendor/bin/patch-status exist?

php vendor/bin/patch-status --version
# patch-status 1.0.2

This is the fastest test I know. vendor/bin/patch-status is Adobe's Commerce Version Tool, and it is not shipped with 2.4.9. The July 2026 patch creates it, and the August patch updates it. Adobe's own APSB26-153 notes say the same thing: if the tool is not installed, apply the July isolated patch to get it.

• File missing: July is missing, so everything after July is suspect too.
• File present but version 1.0.0: July is in, August probably is not. On my store, August moved it to 1.0.2.
• File present after a fresh composer install: good sign, it means your build reapplies the patches.

That last point matters more than it looks. composer install rebuilds vendor from scratch. If your patches were applied by hand on the server, the next build wipes them, including this tool.

Step 4: run patch-status and read it properly

php vendor/bin/patch-status
php vendor/bin/patch-status --format=csv
php vendor/bin/patch-status --no-cache

It compares your code against Adobe's registry at repo.magento.com/patch/patch-registry.json, so it needs network access and your Magento Marketplace keys. It reads them from the COMPOSER_AUTH environment variable, then auth.json in the project root, then the global Composer auth.json. The registry and patch diffs are cached under var/patch_metadata/ for an hour; --no-cache forces a fresh fetch. Every run also appends one summary line to var/log/patch_status.log, which gives you a free history.

Real output from this store tonight, trimmed:

{
    "base_version": "2.4.9",
    "installed_components": {
        "CE": "2.4.9",
        "PageBuilder": "2.2.7",
        "Inventory": "1.2.9"
    },
    "applied_patches": [
        "249-2026-07-001-CE",
        "249-2026-08-001-CE",
        "249-2026-09-001-CE",
        "249-2026-10-001-CE",
        "249-VULN-39341-CE"
    ],
    "missing_patches": [],
    "unknown_patches": [],
    "vulnerability_status": {
        "CVE-2026-103849": { "status": "PROTECTED" },
        "CVE-2026-75650": { "status": "PROTECTED" },
        "CVE-2026-92910": { "status": "NOT_APPLICABLE" }
    },
    "registry_source": "remote",
    "warnings": []
}

What each part tells you:

• missing_patches: the list you actually care about. Empty is the goal.
• unknown_patches: the tool could not decide. Adobe has a KB note (ka-50927) for 2.4.8-p5 stores that see UNKNOWN after applying October. Treat UNKNOWN as "check by hand", never as "fine".
• vulnerability_status: PROTECTED, VULNERABLE, UNKNOWN or NOT_APPLICABLE per CVE. NOT_APPLICABLE shows up for code you do not run, like B2B-only issues on Open Source.
• registry_source: remote means it compared against Adobe's live registry. If it says none, there was nothing to compare against and the rest of the report means little.

The tool itself prints a warning that its output format is not final, so pin your scripts to field names loosely and re-check after each month's patch.

Step 5: check each patch file with a dry run

I do not trust a single tool for security status, so I keep a second check that needs no network. If your patch files live in the repo (they should), loop over them in order:

cd /var/www/html
for p in patches/VULN-*.patch patches/*-CE.patch; do
  if patch -p1 -R --dry-run -f -s < "$p" >/dev/null 2>&1; then
    echo "applied   $p"
  elif patch -p1 --dry-run -f -s < "$p" >/dev/null 2>&1; then
    echo "MISSING   $p"
  else
    echo "CONFLICT  $p"
  fi
done

MISSING is clear. CONFLICT needs thought, because it has three possible causes:

• The patch is applied, but a later month rewrote some of its lines. On my store, once October is in, July shows CONFLICT on Sanitizer.php, and once August is in, July also conflicts on vendor/bin/patch-status. This is normal for stacked patches.
• A hand edit sits on the patched lines.
• The base version is not what the patch expects.

To separate the first case from the other two, reverse the whole stack, newest to oldest, on a copy of the touched files. If the full run reverses cleanly, every patch in it is applied. I explain that technique, and the Composer hook built on it, in the post on an isolated patch that would not apply.

Step 6: look for leftovers and hand edits

find vendor -name '*.rej' -o -name '*.orig'

.rej files mean a patch partly failed at some point and someone carried on anyway. .orig files mean a hunk applied with fuzz and GNU patch kept a backup. Neither should exist on a production store. Apply future patches with --no-backup-if-mismatch so the second kind never appears.

Hand edits in vendor are the hardest to spot, and they are what made my October patch fail on Preview.php. If a dry run fails on one file only, diff that file against a clean composer install --no-scripts build of the same lock file before you blame Adobe.

Step 7: fail the build when something is missing

The manual check is good once. A pipeline check is good forever. After the build step, where your patch hook has already run:

php vendor/bin/patch-status > var/patch-status.json
jq -e '.missing_patches | length == 0' var/patch-status.json
jq -r '.vulnerability_status | to_entries[]
       | select(.value.status == "VULNERABLE") | .key' var/patch-status.json

jq -e exits non-zero when the expression is false, so the job fails if anything is missing. The second line prints any CVE still marked VULNERABLE for the deploy log.

A monthly routine that takes 20 minutes

1. Second Tuesday: read the new bulletin on Adobe's security page. If the pattern holds, the next one is due November 10, 2026.
2. Download your line's zip, add the right files to patches/, CE first.
3. Dry run on staging. Any FAILED hunk: stop and find the cause.
4. Deploy through the normal pipeline so the hook applies it, then setup:di:compile and a cache flush.
5. Run patch-status, confirm missing_patches is empty, and save the output with the release.
6. Smoke test checkout, admin login and whatever area the bulletin touched.

If you would rather not own this every month, it is the core of my Magento security audit and hardening service, and the background on what a patch does and does not change in your store is in what changes and what stays in a security patch.