EveryHost: Magento Dedicated Hosting UK
    Peak season 2026 · part 1 of 4: Secure

    Securing a Magento store before the freeze

    Everything you have not patched by 30 October, you are trading through

    By Simon Bumford, Founder of EveryHost••7 min read

    TL;DR

    Peak season is when rising attack traffic collides with a code freeze. After the end of October most merchants stop deploying, which means whatever is unpatched on 30 October is what you trade through Black Friday on. This is the list, in the order it matters.

    This is part of the Magento Black Friday readiness checklist. Black Friday 2026 is 27 November. If you want to change anything structural, the deadline that binds is 2 October.

    What the traffic actually looks like

    In a normal 24 hours across the Magento servers we run we log roughly 6,000 attack events from around 1,500 distinct sources spread over 300 networks. That is a quiet Tuesday, not an incident.

    The largest single category is not aimed at Magento at all. It is WordPress probing: requests for /wp-login.php and /wp-config.php.bak against stores that have never run WordPress. Attackers spray the whole internet and see what answers.

    The second largest is credential hunting. In one 48 hour window we logged 7,270 requests for a .env file across 730 different spellings. They are not trying to break Magento. They are hoping somebody left a password file where a web server will hand it over.

    Patch level, and the order matters

    Know your exact patch level, not your major version. The difference between 2.4.7 and 2.4.7-p9 is nine months of security fixes.

    Adobe's isolated patches must be applied in order. July before August, August before September. Skipping one does not leave you half patched, it stops the next one applying cleanly.

    Version currency is not always enough. StyleSmuggler, disclosed in September 2026, affected every version including 2.4.9, and the first confirmed victim was fully patched to August. Being current is necessary and it is not sufficient.

    The things that are almost always wrong

    Anything under app/etc/ or var/ reachable over HTTP. It should return 404. A 403 is worse than a 404, because it confirms the path is worth pursuing.

    A stray .env, .git directory or database dump in the web root. Usually left behind during a deploy by someone who meant to remove it in a minute.

    Admin accounts belonging to people who left, and admin accounts without two-factor authentication.

    An admin URL still on /admin.

    Security alerts arriving in a mailbox nobody reads. Receiving an alert is not the same as acting on one.

    Set the freeze and mean it

    Pick your code freeze date, put it in writing, and tell your agency. Around 30 October is normal for a November peak.

    The failures that hurt during peak are almost never traffic. They are a deploy that went out on a quiet Tuesday and quietly broke a payment method nobody tested.

    Agree what counts as an exception before you need one. Security fixes ship. Nothing else does.

    Frequently Asked Questions

    Run bin/magento --version on the server, which gives the full version including the -p suffix. Do not rely on the admin footer or on what your agency told you last year. If you cannot run a command, ask whoever can, and ask for the exact string rather than a summary.

    Security patches yes, everything else no. That is exactly what the exception rule in your code freeze is for. The risk of shipping an emergency security fix in November is real but it is smaller than the risk of trading a known exploited vulnerability through your busiest fortnight.

    No, and this catches people out. A 403 tells an attacker the path exists and is protected, which makes it more interesting, not less. A 404 tells them nothing. If your configuration returns 403 for app/etc/ you have revealed something you did not need to.

    A web application firewall works at the web layer, so it helps with a large part of this and it cannot help with everything. Kernel level privilege escalation is exploited from an account already on the machine, below the layer any WAF inspects. No WAF stops those, and any host telling you otherwise is overselling. That class of risk is answered by architecture, which is why we run single tenant hardware.

    Free Peak Readiness Check

    We will check your Magento version and patch exposure, look for credential files reachable from the web, and review your security headers. Free, nothing to install, and you do not need to be a customer.

    Back to the full checklist.