Why an unpatched store is an open door
Every security patch exists because a vulnerability was found. Until that patch is applied to your store, the vulnerability is still there — and once it's public, it's effectively a published map to your front door. Attackers don't hand-pick targets; they run automated scanners across the web looking for stores with known, unpatched weaknesses, and they hit whatever they find.
The most common outcome for a compromised store is Magecart-style skimming: malicious JavaScript is quietly injected into your checkout, silently capturing customers' card details in real time and shipping them to an attacker-controlled server. There's usually no visible symptom. You often don't find out until customers report fraud or your payment processor does — by which point the damage, and the liability, are already done.
This is not hypothetical. When Magento 1 reached end-of-life in 2020, the "CardBleed" campaign compromised 2,806 Magento stores — around 3% of the install base — in what security firm Sansec described as the largest automated skimming campaign it had recorded since it began monitoring in 2015. Many of those stores had no prior history of security incidents. They were simply running software that no one was keeping patched.
And there's a compliance layer merchants underestimate: if you process card payments, running unpatched or unsupported software is a direct PCI-DSS exposure. Maintaining a secure, patched environment is part of the standard — a qualified assessor will flag an unpatched store, and the cost of a breach (forensics, chargebacks, potential fines, downtime, and lost trust) dwarfs the cost of keeping current.
The gap that catches even supported stores
Here's the point most coverage misses, and the one that matters most:
Adobe releasing a patch does not mean your store is patched.
Being on a supported version only means patches are available to you. Every one of those releases still has to be reviewed, tested against your store's specific extensions and customizations, and deployed to production without breaking your storefront. A supported store with unapplied patches is exposed to exactly the same known vulnerabilities as an end-of-life store — the door is just as open.
In practice, this is where stores get hurt. Patches get skipped because a release landed during a busy period, or because someone worried it might break a customization, or because there was simply no process and no owner. Weeks pass. Then an automated scanner finds the gap. The version was "supported" the entire time — it made no difference, because the patch was never applied.
So the real security question isn't "is my version still supported?" It's:
Is someone reliably applying every relevant patch to my specific store — and moving fast when a critical vulnerability drops?
Why patching has to be proactive and continuous — not a scramble
Effective patching is a rhythm, not an event. A few realities make ad-hoc, do-it-when-we-remember patching fail:
- The exposure window is short. Once a vulnerability is disclosed, automated attacks begin scanning within hours to days. Patching "next quarter" isn't a plan — critical fixes need to go out fast.
- Magento and Adobe Commerce stores are heavily customized. You can't blindly apply a patch to a store with third-party extensions and custom code — it may break checkout, integrations, or the theme. Every patch needs to be tested against your build before it goes live. This is exactly why blind or automated patching, and why DIY patching without proper staging, so often goes wrong.
- Someone has to be watching. New security releases and zero-day advisories don't announce themselves on your calendar. Without active monitoring, you find out you needed a patch after it mattered.
- Timing around peak season is its own risk. Merchants freeze changes during their busy periods — reasonable — but that freeze can leave critical patches unapplied for months unless someone plans for it deliberately.
Why this needs a reliable partner — not just "we'll get to it"
Patching sits in an awkward gap. It's too specialized and too consequential to leave to whoever has spare time, but it's rarely urgent enough to interrupt roadmap work — until it's a breach. That's precisely how stores drift into exposure.
A reliable patching partner closes that gap by making it someone's standing job to:
- Monitor continuously for new Adobe security releases and critical vulnerabilities affecting your version and edition.
- Assess which patches actually apply to your store, and prioritize by severity.
- Test each patch against your specific extensions and customizations in a staging environment, so applying it doesn't break the storefront.
- Deploy on a predictable monthly cadence for routine hardening — with rapid, out-of-cycle deployment when a critical CVE can't wait.
- Document what was applied and when, which is exactly what your PCI-DSS obligations and any future audit will ask for.
The value isn't just the patching itself — it's the removal of the failure modes above: no skipped releases, no "we'll do it after the busy season," no discovering a zero-day after the scanners already have.
Where end-of-life fits in
End-of-life is simply the point where this problem becomes permanent. When a version stops receiving patches, its vulnerabilities can never be officially fixed — the door stays open by design, and attackers actively hunt for stores on those versions.
Two nuances catch merchants out here, and both matter for planning:
- Extended support is an Adobe Commerce–only benefit. Adobe's lifecycle policy is explicit that the one-year extended-support extension applies to Adobe Commerce customers, not the Magento Open Source code base. A Magento Open Source store loses patches at the end of its regular support window — with no extension.
- The same version number can be in two different positions depending on your edition.
| Your version | Magento Open Source and Adobe Commerce (no extended support) |
| 2.4.4 and below | Unsupported — no patches |
| 2.4.5 | Regular support ended Aug 9, 2025 — unsupported now |
| 2.4.6 | Support ends Aug 11, 2026 |
| 2.4.7 | Support ends April 9, 2027 |
| 2.4.8 | Support ends April 11, 2028 |
If you're already past support — particularly Magento Open Source on 2.4.5 or earlier — you're not "approaching" risk; you're in it now. And if you can't upgrade immediately, that's exactly the situation where managed patching keeps you protected while the larger upgrade is planned.
How Evrig keeps your store locked
Evrig provides managed security patching for Adobe Commerce and Magento Open Source stores. We monitor for new Adobe security releases and critical vulnerabilities, assess what applies to your store, test each patch against your specific extensions and customizations, and deploy on a regular cadence — with priority handling when a critical CVE requires fast action. You get a documented, predictable process instead of a recurring scramble.
We're an ISO 27001–certified team with a US (Minneapolis) + India presence, so security coverage and responsiveness aren't afterthoughts. Whether you're on a current version or planning a larger upgrade, we keep the door closed in the meantime.
Not sure whether your store is fully patched? Get a free store security audit — we'll check your version, edition, and patch status and tell you exactly what's exposed. Or talk to our team about managed monthly patching.