Magento 2.4.6 Lost Support a Month Ago. Nothing Broke — That Is the Problem.

On 11 August 2026, Adobe stopped shipping security patches for Magento 2.4.5 and 2.4.6.

If you run a store on either version, here is what happened on that day: nothing. The site came up. Orders went through. Checkout worked. The admin panel loaded exactly as it had the week before. No banner appeared, no email arrived, and nothing in the application told anyone that the arrangement had changed.

That is the trap, and it is worth being precise about why.

What Actually Stopped

End of support does not disable software. What ends is the flow of fixes coming toward you.

Before that date, when a researcher disclosed a vulnerability in Magento, a patch followed. You applied it, and the window between disclosure and exposure was measured in days. After that date, for those two versions, the disclosure still happens — the patch does not. Every CVE filed against 2.4.5 or 2.4.6 from now on stays permanently open, regardless of severity.

There is a second detail that catches people running Magento Open Source specifically. Adobe Commerce customers have historically had extended support arrangements available to them. Open Source has no such tier. There is nothing to buy, no paid extension to negotiate, no enterprise account manager to call. End of regular support is simply the end.

And if you are on 2.4.5, the situation predates last month: that line left standard support in August 2025. Merchants who read "2.4.5 and 2.4.6" as a single event in 2026 have, in the 2.4.5 case, already been running unpatched for a year.

The Asymmetry That Makes This Expensive

A running store looks identical whether or not it is patched. That symmetry is what makes the risk hard to feel and easy to defer.

The asymmetry is on the attacker's side, and it runs in one direction:

• Disclosure is public. Vulnerability databases, advisories and release notes are open. The same document that tells a defender what to fix tells an attacker what to look for.
• Version detection is trivial. Magento installations are fingerprintable at scale from the outside. Nobody needs to guess which stores are on which version; it can be enumerated.
• The patch is the map. When a fix lands for a supported version, the diff describes the vulnerability precisely. Attackers read patches for supported lines and apply the knowledge to the unsupported ones, where the same code is still running and no fix is coming.
• The gap only widens. A supported store's exposure window closes each time it patches. An unsupported store's exposure window has no closing mechanism at all. Every month adds to it and nothing subtracts.

This is why "we have not had a problem yet" is a statement about the past twelve months and not a forecast. The thing that changed in August is not the probability of a given attack succeeding — it is that the remedy no longer exists.

PCI DSS Turns a Security Question Into a Compliance One

If your store takes card payments, the argument stops being about risk appetite and becomes about a standard you have already agreed to.

PCI DSS expects systems in scope to be running current security patches. It is not a vague aspiration in the standard — patch management is a named requirement, and an unsupported platform is the textbook case of being unable to meet it. You cannot apply a patch that does not exist, and "the vendor no longer publishes one" is not an accepted compensating control. It is the reason a compensating control would be demanded in the first place.

A few things follow from that which merchants routinely get wrong:

• Being SAQ A does not empty your scope. Moving the card fields into a hosted iframe or a payment provider's JavaScript reduces what you handle, but the page that loads that script is still yours. If the platform serving it is compromised, the script can be swapped. This is precisely the mechanism behind years of digital skimming incidents, and it is why the standard now pays attention to the integrity of the payment page itself.
• "It passed the scan" is a smaller claim than it sounds. An ASV scan reports what it detects. It is not a statement that your platform is supported, and a clean scan on an unsupported version is a description of the scanner's coverage, not of your position.
• The question arrives at the worst moment. Nobody asks what version you are on while things are calm. It gets asked during an assessment, during a payment provider's review, or after an incident — three moments where the honest answer is expensive.

There is also an insurance dimension worth checking before you need it. Cyber policies increasingly ask about patching practices, and running software the vendor has publicly stopped supporting is the kind of detail that surfaces during a claim rather than during underwriting.

Why Waiting Costs More Than Moving

The instinct when budget is tight is to defer a year. With platform upgrades, deferral is not neutral — the bill grows while you wait, for reasons that have nothing to do with inflation.

An upgrade's cost is driven by distance, not by the current version number. Each release you skip adds schema changes, deprecated APIs, and PHP requirements that your extensions have to cross in one jump rather than in stages. A store one version behind is a project. A store four versions behind is an archaeology exercise, because the people who wrote the customisations have often moved on and the extensions they depended on may no longer have maintained equivalents.

There is a second, quieter cost. Third-party extension vendors follow Adobe's support calendar. When a version goes out of support, the vendors serving it eventually stop testing against it too. The longer you sit on an unsupported line, the more of your extension estate becomes genuinely unsupported rather than merely old — and replacement, not upgrade, becomes the only path.

The version you are running also sets a floor on your PHP version, which sets a floor on everything else in the stack. Deferring the Magento upgrade defers the PHP, search and cache decisions behind it, and those have their own end-of-life calendars that do not wait for yours.

The Extension Matrix Is What Turns a Range Into a Date

Ask three agencies how long a Magento upgrade takes and you will get three ranges, all of them wide. That is not evasiveness. It is an honest reflection of the fact that the variable is not Magento.

Magento's own upgrade path is reasonably well-trodden. What differs between a six-week project and a six-month one is the estate sitting on top of it: third-party extensions, custom modules, theme overrides, and integrations with the ERP or the WMS or the accounting system that someone built in a hurry three years ago.

The artefact that converts that uncertainty into a plan is an extension compatibility matrix — a line for every extension and custom module, and for each one an answer to four questions:

1. 1Is there a version compatible with the target release? If yes, this is a version bump and a regression test.
2. 2Is the vendor still maintaining it? A recent release date matters more than the current version number. An extension last updated in 2023 is a liability even if it works today.
3. 3Is it still doing something the business needs? Estates accumulate. It is common to find extensions that no longer serve any purpose, and deleting one is faster and cheaper than migrating it.
4. 4If none of the above, what replaces it? Some functionality has to be rebuilt, and knowing that in week one is very different from discovering it in week nine.

Build that matrix before writing any code. It is the difference between a scoped project and an open-ended one, and it is the single most useful thing you can produce even if you do not start the upgrade immediately. A store owner who has the matrix can make an informed decision about timing. One who does not is choosing between unpriced options.

The other discipline worth insisting on is rehearsal. The upgrade should run end-to-end on a clone of production before it runs on production. Every unpleasant surprise — a module that will not install, a schema conflict, a theme regression in checkout — is significantly cheaper the first time it happens on a machine nobody is buying from.

This Is Not Really a Magento Problem

The failure mode here is not specific to Magento, and recognising that is useful because it tells you where else to look.

We wrote recently about why WordPress sites keep getting compromised through their plugin ecosystem, and the central observation there applies exactly: software that stops being maintained does not announce it. It keeps working perfectly, which is precisely the problem. Nothing about the site looks wrong until a vulnerability is disclosed and there is no patch coming.

A WordPress plugin abandoned by its author and a Magento version abandoned by its vendor are the same event at different scales. In both cases the software continues to function, the risk accrues invisibly, and the moment of discovery is chosen by someone other than you.

The defence is the same in both cases, and it is unglamorous: know what you are running, know whether each piece is still maintained, and treat "still receiving security updates" as a property you actively verify rather than assume.

What to Do This Month

If you are on 2.4.5 or 2.4.6, the useful next steps are small and mostly free:

• Confirm your exact version and patch level. Not what the documentation from the last project says — what the system reports today. It is more common than it should be for a store to be a patch release behind where everyone believes it is.
• Inventory the extensions and when each was last updated. This is the raw material for the matrix, and it can be produced in an afternoon.
• Decide your target release deliberately. The supported lines have different runways and different PHP requirements, and the right answer depends on your extension estate rather than on which number is highest. It is worth being explicit about whether you are buying two years of runway or four.
• Check what your payment provider and your PCI documentation actually say. Better to find the requirement yourself than to have it found for you.
• Write down the decision, including a decision to wait. If the answer is "not this quarter", that is a legitimate business call — but it should be a recorded one with a date attached, not a deferral that quietly becomes permanent.

The Bottom Line

Nothing broke on 11 August. Nothing will break tomorrow either, and that is the entire difficulty: the cost of this decision is invisible right up until it is not, and by then the choice about timing belongs to someone else.

An unsupported e-commerce platform is a compliance problem before it is a security incident, and it is a budget problem before it is either — because the longer it runs, the more it costs to leave.

If you want a clear view of where your store stands, our Magento consulting practice covers upgrade planning, security posture and the delivery pipeline underneath it, and the assessment includes the extension compatibility matrix described above. Or talk to our team if you would rather start with a conversation than a document.