Magento Isolated Patch Not Applying? How I Fixed the October 2026 Patch on My Own Store

The setup

This site runs Magento Open Source 2.4.9. I keep every Adobe patch file in the repo under patches/, and a Composer post-install-cmd hook reapplies them after every composer install, so a deploy can never quietly ship unpatched vendor code.

Before tonight the folder held two Adobe files: VULN-39341_249.patch, the emergency hotfix for CVE-2026-75650 from September, and 249-2026-09-001-CE.patch, the September monthly patch (APSB26-138). I added 249-2026-10-001-CE.patch from the APSB26-153 October zip and ran a dry run.

The error

Here is the Sanitizer part of that dry run, reproduced on a scratch copy of the stock 2.4.9 file so you can see exactly what GNU patch prints:

$ patch -p1 --dry-run < patches/249-2026-10-001-CE.patch
checking file vendor/magento/framework/View/Element/UiComponent/DataProvider/Sanitizer.php
Hunk #1 FAILED at 50.
1 out of 2 hunks FAILED

The second failure was in vendor/magento/module-email/Block/Adminhtml/Template/Preview.php. Two files out of 22. Everything else checked out fine, which is what makes this kind of failure tempting to force through. Do not. A half-applied security patch leaves you with code nobody tested.

Cause 1: I had skipped July and August

Look at what the October hunk expects to find at line 50 of Sanitizer.php:

-                && preg_match('/\$\{.+\}/s', (string)$datum)
+                && $this->validateSyntax((string)$datum)

Note the /s modifier on the regex. Stock 2.4.9 does not have it. The July patch adds it:

-                && preg_match('/\$\{.+\}/', (string)$datum)
+                && preg_match('/\$\{.+\}/s', (string)$datum)

So October is not a diff against 2.4.9 GA. It is a diff against 2.4.9 plus July plus August plus September. Adobe says this plainly in the APSB26-153 notes (KB ka-49323): you must have applied all earlier monthly isolated patches for your line, in release order. I had written a whole post about the July patch and still never added it to my own repo. That is the honest version.

August has the same dependency, in a less obvious place. July creates vendor/bin/patch-status, Adobe's version tool. August modifies that file. Apply August without July and it fails on a file that does not exist.

The fix for cause 1 is boring: download the missing months and apply them oldest first.

cd ~/patches
for m in jul aug; do
  curl -fsSLO "https://repo.magento.com/patch/2-4-9-$m-2026.zip"
  unzip -o "2-4-9-$m-2026.zip" -d "$m"
done
cp jul/249-2026-07-001-CE.patch aug/249-2026-08-001-CE.patch /var/www/html/patches/

Cause 2: a hand edit in vendor

The Preview.php failure had nothing to do with missing months. During the StyleSmuggler incident in September I had added a small guard to that file directly in vendor, as a stopgap. It never went into a patch file. The October patch adds template validation to the same _toHtml() method, its context lines no longer matched, and the hunk failed.

Hand edits in vendor are invisible. Composer does not know about them, git status does not show them if vendor is ignored, and the next composer install silently deletes them. The only time they announce themselves is when a patch fails on them, usually during a security window.

To find out whether a file was hand edited, build a clean vendor tree from the same composer.lock with scripts switched off, so no patch hook runs, and diff against it:

git clone --depth 1 git@github.com:you/your-store.git /tmp/clean
cd /tmp/clean
composer install --no-scripts --no-dev --ignore-platform-reqs
diff -u /tmp/clean/vendor/magento/module-email/Block/Adminhtml/Template/Preview.php \
  /var/www/html/vendor/magento/module-email/Block/Adminhtml/Template/Preview.php

Your patched files will also differ from stock, by exactly the patches you applied. The diff you care about is anything that is not in a patch file. In my case it was obvious: the guard I wrote in September.

I backed up the edited file, put the stock file back, and let the October patch do the job properly. Its new Validator check on the preview input covers what my stopgap was trying to do.

Cause 3: the hook was not safe once patches stack

With July, August and October added, the dry runs were clean, and I deployed. The deploy rolled itself back. My hook applied July and August on the server, then failed on October, because the hand-edited Preview.php was still in place on live. That part I fixed by restoring the stock file. But the rollback exposed a design bug in the hook that would have bitten on the next deploy anyway.

The old hook checked each patch on its own:

for p in patches/VULN-*.patch patches/*-CE.patch; do
  if patch -p1 -R --dry-run -f < "$p" >/dev/null 2>&1; then
    echo "already applied: $p"
  elif patch -p1 --dry-run -f < "$p" >/dev/null 2>&1; then
    patch -p1 -N -f < "$p"
  else
    echo "ERROR: $p" >&2; exit 1
  fi
done

"If it reverses cleanly, it is applied" works for one patch. It breaks the moment a later patch rewrites lines an earlier one added. Once October is in, the reverse check for July fails, because the line July added is gone:

$ patch -p1 -R --dry-run < patches/249-2026-07-001-CE.patch
checking file vendor/magento/framework/View/Element/UiComponent/DataProvider/Sanitizer.php
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED

The forward check fails too, so the hook declares July broken and exits 1. Same thing between July and August on vendor/bin/patch-status. A fully patched store fails its own deploy.

The fix: find the applied run first

Patches applied in order can be reversed in reverse order. So instead of asking "is July applied?" on its own, the hook asks "are patches 1 to k all applied?" by reversing k down to 1 on a scratch copy of the touched files. It starts with k equal to the total and steps down until a run reverses cleanly. Everything up to k is applied. Everything after k is handled one by one as before.

# succeeds when patches 1..$1 are all applied
prefix_applied() {
    k=$1
    [ "$k" -eq 0 ] && return 0
    tmp="$(mktemp -d)" || return 1
    # copy every file any patch touches into the scratch dir
    printf '%s' "$LIST" | while IFS= read -r p; do
        sed -n 's#^+++ b/##p' "$p"
    done | sort -u | while IFS= read -r f; do
        if [ -f "$f" ]; then
            mkdir -p "$tmp/$(dirname "$f")"
            cp "$f" "$tmp/$f"
        fi
    done
    ok=0; i=$k
    while [ "$i" -ge 1 ]; do
        (cd "$tmp" && patch -p1 -R -f -s < "$ROOT/$(nth "$i")") >/dev/null 2>&1 || { ok=1; break; }
        i=$((i - 1))
    done
    find "$tmp" -depth -delete
    return $ok
}

k=$COUNT
while [ "$k" -gt 0 ] && ! prefix_applied "$k"; do k=$((k - 1)); done

After that loop, patches 1 to k are reported as already applied, and the rest go through the dry run and apply as normal, with --no-backup-if-mismatch so a fuzzy apply never leaves .orig files in vendor. Order matters: the glob puts the VULN hotfix first, then the monthly CE files, whose names sort by date.

The scratch copy is the important part. The real vendor tree is never touched during the check, and the temp dir is deleted every time.

How I tested it before the second deploy

I ran the new hook in the local PHP container from four starting states:

• fully patched (all five applied)
• live's state after the failed deploy (VULN, September, July, August applied, October not)
• the old state (VULN and September only)
• a fresh composer install with no patches

Every run exited 0. A second run from each state reported all five patches as already applied. The patched files ended byte-identical in all four cases, setup:di:compile passed and the storefront returned 200. On the patched build, php vendor/bin/patch-status lists all five as applied and an empty missing_patches. The checklist for finding missing Magento security patches shows how to read that output.