Magento 2.4.7 Security Patches: Supported Is Not the Same as Patched

If you're on Magento 2.4.7, you're on a supported version. Adobe still ships you security patches, your line doesn't reach end of support until 2027, and nobody is sending you EOL warnings.

That is exactly why 2.4.7 stores are some of the most consistently under-patched installations we see.

The version number is the part everyone tracks. The patch level is the part that determines whether the specific vulnerability being scanned for against your store this week is fixed on your server. They are not the same thing, and Adobe's bulletins are written in terms of the second one.

What Adobe's July bulletin actually said

APSB26-73, published on July 14, 2026, listed the affected versions like this:

Read the 2.4.7 row again. Not "2.4.7 is fine because it's supported." Every patch level from GA up to and including p10 is vulnerable to whatever that bulletin fixed. A store that upgraded to 2.4.7 in 2024, went live, and hasn't touched the patch level since is sitting ten patch releases behind — and each of those ten releases exists because something was found.

"We're on a supported version" is a statement about Adobe's obligations. It says nothing at all about your server.

The gap between patch available and patch applied

This is where the actual risk lives, and there is good data on it.

When CVE-2025-54236 — SessionReaper — was disclosed in September 2025, Adobe shipped an emergency patch ahead of schedule. Ten days later, Sansec found fewer than one in three Magento stores had applied it. Six weeks later, 62% were still unpatched. Mass exploitation started on October 22, and Sansec blocked more than 250 exploitation attempts in a single day.

The pattern before that was the same. CosmicSting (CVE-2024-34102) led to 4,275 confirmed store compromises across seven distinct attack groups. In both cases the patch existed well before the attacks. What didn't exist was a process for applying it.

Attackers do not need a zero-day to get into Magento stores. They need a published CVE, a scanner, and a population of stores that patch on a quarterly cycle. You are not being targeted for being interesting. You're being targeted for being reachable and behind.

Find out what you're actually running

Most teams are less patched than they think, usually because the last upgrade project ended and nothing replaced it. Check, rather than assume:

# The version and patch level Magento reports
bin/magento --version

# What Composer actually resolved — this is the authoritative answer
composer show magento/product-community-edition | grep versions

# For Adobe Commerce
composer show magento/product-enterprise-edition | grep versions

Then compare that against the current patch level for the 2.4.7 line in Adobe's release notes. If the number after the p is lower than the one Adobe published this month, you have a gap, and the size of that gap is the number of security releases you're missing.

While you're there, check whether anyone has applied individual patches on top without bumping the version — it's common, and it means --version under-reports what's fixed:

composer require magento/quality-patches
vendor/bin/magento-patches status

What patching 2.4.7 actually involves

A patch-level update is a fundamentally different piece of work from a version upgrade, and conflating the two is the most common reason patching gets deferred into a project that never starts.

Going from 2.4.7-p8 to the current patch level touches security fixes and bug fixes within the same minor line. It does not change PHP requirements, database requirements, or the framework. Extension compatibility is very unlikely to break. In practice:

# Substitute the current patch level from Adobe's release notes
composer require magento/product-community-edition=2.4.7-pNN --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
bin/magento cache:flush

On a store with a well-behaved codebase that is a staging deploy, a smoke test through checkout, and a production window. Call it a day of work, most of it waiting and testing.

Compare that with the 2.4.7 → 2.4.8 upgrade, which brings PHP, OpenSearch, and extension compatibility along with it — a multi-week project on a customized store. Both are necessary. Only one of them is urgent every month, and if you treat them as the same category of work you will do neither.

Adobe also now ships isolated security patches on a twice-monthly cadence, starting with APSB26-73 on July 14, 2026 — second and fourth Tuesdays. These are targeted fixes you can apply without taking a full patch release, which matters when you need coverage in days and your full-release testing cycle takes weeks. The next one at time of writing is scheduled for August 11, 2026.

The runway you have left

2.4.7 reached general availability in April 2024, and its support window runs three years from there. Which gives you roughly this:

The PHP row is the one that catches teams out. 2.4.7 runs on PHP 8.2 or 8.3. If you're on 8.2, your language runtime stops receiving security fixes at the end of 2026 — before your Magento version does. An unpatched PHP under a patched Magento is not a secure store, and "we're on a supported Magento version" won't cover it.

Moving to PHP 8.3 within the 2.4.7 line is a comparatively small piece of work, and it's worth doing regardless of when you upgrade Magento — 2.4.8 requires 8.3 or 8.4 anyway, so you'd be doing the migration once instead of twice.

What to do this week

1. Establish your actual patch level. Not from memory, not from the wiki. From composer show, on production.

2. Close the gap to the current patch level. If you're more than one or two releases behind, schedule it now rather than bundling it into a future upgrade project. The bundling is how stores end up ten levels behind.

3. Subscribe to Adobe's security bulletins. They arrive on a predictable schedule now. Someone specific should receive them and own the decision, or they land in a shared inbox and nothing happens.

4. Write down your patch SLA. A target of "critical patches applied within 72 hours, everything else within two weeks" is achievable on Magento and would have put you well ahead of the 62% during SessionReaper. A target you haven't written down is not a target.

5. Make patching boring. A staging environment that matches production, a smoke test that covers add-to-cart through order confirmation, and a rollback you've actually rehearsed. Patching is deferred because it's risky; it's risky because it's rare; it's rare because it's deferred.

6. Plan the 2.4.8 move on a calendar. Not urgently — deliberately. You have runway, and the stores that use it badly are the ones that discover in February 2027 that their theme needs rebuilding.

The short version

Being on a supported version means Adobe will make a patch for you. It doesn't mean anyone applied it.

The stores that get compromised are rarely running something exotic. They're running a supported version, several patch levels behind, with no owner for the bulletins and no process that turns a published CVE into a deployed fix. That is a fixable operational problem, and it's considerably cheaper to fix than a card-skimmer incident and the disclosure that follows.

If you're not sure what you're running or how far behind it is, that's a half-day audit, not a project.

Emyrix maintains, patches, and upgrades Magento and Adobe Commerce stores, including managed patch cycles so this stops being something you have to remember. If you want your patch position assessed properly, get in touch — or use our emergency support line if you think you're already compromised.

Version and patch-level details are drawn from Adobe's security bulletins and software lifecycle policy, which are the authoritative sources and worth checking directly for your license type.