Magento Upgrades and Security Patching
A Magento upgrade moves your store to a newer release, and a security patch fixes a flaw within the release you already run. Both are safest done the same way: tested on a staging copy first, then applied to the live store in an agreed maintenance window, with a rollback plan. This page covers which versions Adobe still supports, how a Magento 2 upgrade works, how we apply patches, the recent attacks that make speed matter, and Adobe's own security and performance checklists.
Is your store at risk?
Work down this list. Each line is tied to a source further down the page.
- Is your Magento version past the end of standard support? 2.4.6 and earlier are.
- Are you on Magento Open Source 2.4.6 or earlier? Normal patch downloads are limited to 2.4.7 and later.
- Have you applied the September 2026 hotfix for CVE-2026-75650, Adobe bulletin APSB26-146? It has been exploited in the wild and is rated CVSS 10.0.
- Have you applied the fix for CVE-2025-54236 (APSB25-88), also exploited in the wild?
- Was your store unpatched during an attack window, even briefly? Patching does not remove backdoors or invalidate stolen keys.
- Is your server on an unsupported PHP or database version? PHP 8.1 reached end of life on 31 December 2025, and MySQL 8.0 support ended on 30 April 2026.
- Is two-factor authentication off for the admin, or is the admin URL still the default?
- Are you missing a weekly run of Adobe's free Security Scan?
- Can the web server write to your code directories in production?
- Are `.git` folders, logs, database dumps or phpinfo files reachable from the web?
- Is nothing protecting the payment page from malicious scripts?
- Do you lack a tested backup from before your last change?
Which Magento versions are still supported
As of 11 October 2026, Adobe's lifecycle policy puts 2.4.7, 2.4.8 and 2.4.9 in standard support, with 2.4.7 the first to leave it, on 31 May 2027. 2.4.6 and earlier are past standard support (Adobe lifecycle policy). Adobe's extended and security-only cover for older lines is for Adobe Commerce customers: "Open Source merchants can only download patches for version 2.4.7 or later" (Adobe KB, APSB26-138). Old PHP matters too: Adobe flags PHP 8.1 and 8.2 as putting "PCI compliance at risk".
For every date, the Adobe Commerce Cloud deadlines and what each status means, see Magento end of life dates.
How we approach a Magento 2 upgrade
A Magento 2 upgrade has two halves: getting the server ready for the target release, and moving the store's code onto it.
What Adobe asks you to do first. Adobe's upgrade prerequisites are: update all software, verify that a supported search engine is installed, convert the database table format, set the open files limit, verify that cron jobs are running, set the data converter batch size, verify file system permissions, set the pub directory root, and install the Composer update plugin (Adobe upgrade prerequisites). The server stack must match one of Adobe's listed combinations for the target release, and for 2.4.9 Adobe says to upgrade MariaDB to 12.3 before upgrading Magento (Adobe system requirements).
What Adobe says about the upgrade itself (Adobe: perform an upgrade):
- The upgrade command is now `composer require-commerce` rather than `composer require`.
- "Starting the upgrade process while asynchronous processes, such as message queue consumers, are running may cause data corruption", so cron and the queues are stopped first.
- The store goes into maintenance mode for the upgrade, followed by `composer update`, clearing the caches and generated code, `bin/magento setup:upgrade`, and maintenance mode off.
Checking extensions. Adobe's Upgrade Compatibility Tool "is available for Adobe Commerce instances only" (Adobe). On Magento Open Source, every extension and customisation is checked by testing on staging.
Backups and rollback. Magento's built-in backup "is deprecated as of 2.1.16, 2.2.7, and 2.3.0", and Adobe recommends "investigating additional backup technologies and binary backup tools (such as Percona XtraBackup)" (Adobe backup and rollback). In practice, rollback means a fresh database and file backup taken just before the change, with the previous code ready to redeploy.
Our sequence:
- Audit the current version and patch level, PHP, database, search engine, extensions and custom code.
- Choose the target release and check Adobe's requirements for it.
- Upgrade the server stack where the target needs it.
- Clone production to staging.
- On staging, run the upgrade, update extensions, compile and deploy static content, then test.
- Fix incompatible extensions and custom code, and test again.
- Agree a maintenance window and take a fresh backup.
- On production: maintenance mode on, cron and queue consumers stopped, deploy, upgrade, clear caches, maintenance off, cron back on.
- Test checkout, payments, email, search and the admin.
- Keep watching the logs, and keep the backup until you sign off.
On an EveryHost server, we prepare the stack and the staging copy for the upgrade and work alongside your developer or agency, who upgrade and test the store's code. Tell us your version and extensions, and we will set out who takes each step.
How we apply Magento security patches
Adobe published six Adobe Commerce security bulletins in 2025, and six so far in 2026 including one out-of-band emergency fix (7 September), checked on 11 October 2026. Most fall on the second Tuesday of a month (Adobe security bulletins). Adobe's stated minimum is one security release a year per supported line (Adobe release schedule), so the real pace is faster than the minimum suggests.
On EveryHost servers, each Magento security patch is applied in staging first, then coordinated to production with you. Emergency hotfixes such as September 2026's VULN-39341 follow the same staging-first route. For what -pN version numbers mean, see Magento security patches explained, and for planning review windows around Adobe's releases, see our Adobe Commerce patch cadence guide.
Recent Magento attacks, and why patch speed matters
| Name | CVE and Adobe bulletin | Severity | Exploited? |
|---|---|---|---|
| CosmicSting | CVE-2024-34102, APSB24-40, 11 June 2024 | Critical, CVSS 9.8 | Adobe: "exploited in the wild in limited attacks". Added to CISA's catalogue on 17 July 2024. |
| SessionReaper | CVE-2025-54236, APSB25-88, 9 September 2025 | Critical, CVSS 9.1 | Adobe: "aware of CVE-2025-54236 being exploited in the wild". Added to CISA's catalogue on 24 October 2025. |
| PolyShell | CVE-2026-48356 | File upload through the REST API | Sansec reports attacks from March 2026, a fix in 2.4.9, and a backport in July 2026 (Sansec). |
| StyleSmuggler | CVE-2026-75650, APSB26-146, 7 September 2026 | Critical, CVSS 10.0 | Adobe: "aware of CVE-2026-75650 being exploited in the wild". Added to CISA's catalogue on 8 September 2026. |
CISA dates come from its Known Exploited Vulnerabilities catalogue, checked 11 October 2026.
The pattern is the same each time: a critical flaw, confirmed exploitation, and many stores slow to patch. Security firm Sansec measured only a quarter of stores patched a week after the CosmicSting fix (Sansec), and only 38% patched by 23 October 2025, six weeks after the SessionReaper fix. By 26 October it estimated that 16 to 18% of all Magento stores had a backdoor (Sansec). Those figures are Sansec's own telemetry. Patching late also doesn't undo a compromise: after CosmicSting, "existing secret keys were not invalidated automatically" (Sansec), so stores that had been exposed needed their keys rotated as well.
Magento security essentials
Adobe's own Magento security checklist (Adobe: secure your Commerce site, checked 10 October 2026):
- Two-factor authentication. "In 2.4.0, 2FA is enabled by default on the Admin Panel", and "Adobe strongly recommends against disabling the 2FA module" (Adobe 2FA FAQ).
- A non-default admin URL, not "admin" or "backend".
- reCAPTCHA on the admin, against brute force.
- Least privilege when assigning admin roles.
- Keep patched, including security patches and hotfixes.
- Adobe's Security Scan Tool, which is free, covers Adobe Commerce and Magento Open Source sites, runs "over 21,000 security tests", and recommends weekly scans (Adobe Security Scan).
- A web application firewall, to analyse traffic and spot suspicious patterns. If you want an edge WAF, we recommend putting Cloudflare in front of your store.
- Read-only code in production. Adobe recommends removing write access from `app/code`, `lib`, `pub/static`, `app/etc`, `generated/code`, `generated/metadata` and `var/view_preprocessed` (Adobe file permissions).
- Nothing exposed: "Ensure no accessible log files, .git directories, SQL tunnels, database dumps, or php info files exist."
- Locked configuration, using `lock config` and `lock env` so critical values cannot be changed in the admin.
If a store is compromised, Adobe's guidance is to "Reset all credentials, including the database, file access, payment and shipping integrations", remove suspicious accounts, audit the admin logs, scan for malware and keep monitoring (Adobe incident response).
Sentinel, our Magento-tuned security monitoring, is included with every EveryHost plan at no extra cost. It reads your server's logs, blocks abusive sources at the server firewall, and our engineers review what it finds. Managed VPS plans include Sentinel Plus, with bot protection, file integrity monitoring and stricter blocking rules at the server firewall. Dedicated and high availability plans include Sentinel Pro, which adds active tuning during an attack and priority response from our engineers. Sentinel is not a web application firewall, a CDN or a proxy, and it does not sit in front of your store, so if you want an edge WAF or CDN as well, we recommend Cloudflare alongside it. See Magento security and Sentinel for more.
Magento speed optimisation: what actually works
Most Magento speed optimization starts on the server, and Adobe's own guidance is specific:
| Step | What Adobe says |
|---|---|
| Varnish full page cache | "Magento highly recommends using Varnish as the full page cache server for your store." The built-in page cache is for development. |
| Redis or Valkey for cache and sessions | Adobe recommends Redis for sessions and a separate instance for the default cache. Its current requirement tables list Valkey for current patches, so set it to match your Magento version. |
| OpenSearch | Required: every 2.4 install must use OpenSearch or Elasticsearch for catalogue search. |
| PHP and OPcache | Use a PHP version supported by your release. Suggested OPcache settings include `opcache.memory_consumption=512`, `opcache.max_accelerated_files=60000` and `opcache.validate_timestamps=0`. |
| Production mode | Serves static files generated at deployment, and logs errors instead of showing them. |
| Indexers on schedule | "We recommend using Update on Schedule for performance purposes." |
| Asynchronous email | Moves order and checkout email "to the background". |
| Front-end files | Minify CSS, JavaScript and HTML. Bundling "isn't recommended for stores where the first page load time is extremely critical", and HTTP/2 is "a good alternative to using JS bundling". |
Sources: Adobe software recommendations, Adobe configuration best practices, Adobe application modes.
The theme. Hyvä, a lightweight Magento front end, has been free and open source since 10 November 2025, under OSL3 and AFL3 (Hyvä). In the HTTP Archive's August 2026 mobile data, 68% of Hyvä sites passed Core Web Vitals against 44% of Magento sites overall (HTTP Archive, checked 10 October 2026). That is a correlation, not proof that the theme alone causes it.
Google's "good" thresholds are a Largest Contentful Paint within 2.5 seconds, an Interaction to Next Paint of 200 milliseconds or less, and a Cumulative Layout Shift of 0.1 or less, at the 75th percentile of visits (web.dev).
See our Magento performance stack for how we set this up, and Magento Hyvä hosting for what the theme needs from a server.
Related pages
For ongoing help after an upgrade, see Magento support and maintenance. If you are still on Magento 1, see Magento 2 migration. For what a server needs, see Magento hosting, our managed Magento VPS and Magento hosting UK plans, or compare Magento hosting on AWS vs managed UK hosting.
Frequently asked questions
Plan your Magento upgrade
Tell us your version and extensions, and we will tell you what an upgrade involves.