Last Friday, a new and extremely serious vulnerability in WordPress was announced. To summarise, WordPress installs from 6.9 onwards (roughly December 2025) can be compromised remotely, allowing attackers to gain full access to the hosting account that it is running on.

We ensured that all Managed WordPress sites were upgraded promptly, as we do with all vulnerability announcements affecting WordPress and its plugins. As it happens, many of our managed sites were not vulnerable due to some custom hardening rules that we apply by default to managed installations.

We also have a large number of customers running unmanaged WordPress installations on our hosting accounts. Maintaining the security of these installations is the customers’ responsibility and we generally try to avoid interfering with customer sites. In this case, the severity of the vulnerability, and the speed with which we saw exploitation attempts, meant that we felt compelled to take action.

Many users don’t take security too seriously, assuming that their site isn’t important enough to be a target. The reality is that all sites are a target, as compromised hosting accounts can be used to send spam email, or host malicious files for other attacks, and cleaning up after an attack is a lot of work for everyone.

The exploit can be prevented by a simple and non-invasive addition to a site’s .htaccess file that blocks requests to certain URLs. Therefore, we took the step of scanning our hosting servers for WordPress installations that hadn’t been updated (most sites will update themselves automatically) and added the necessary rules, along with a comment explaining why it was done.

Of course, if you don’t want to spend your Friday evenings worrying about critical security updates, our Managed WordPress is still welcoming new customers.

We’re silver sponsors for this year’s Electromagentic Field. Held 16th–18th July in Eastnor Castle Deer Park, it’s a magical camping festival full of weird and wonderful things. We went in 2024 and saw a huge variety of amazing things including a very big Tesla Coil.

This year, in addition to our direct sponsorship of the festival, we’re providing various internet resources to help keep things running. We’re an upstream provider for the network and are already seeing traffic flowing. We also provide some offsite backup space.

Some of our staff are going to be at EMFCamp too and have some things to show. We think there’s something space-themed being created by @bencc@morehammer.uk, and GCHQ will be back with their interactive treasure hunt. We asked our staff for more clues about GCHQ.NET, but they all denied all knowledge about it. In fairness, that’s exactly what we’d expect the organisers to say.

One project we’re helping out is the copper telephone network. To interoperate with the world, we’ve donated a Virtual Private Server to run the SIP gateway to allow inbound and outbound calls. We hear rumours that it might be possible to get VDSL over copper phone if for some reason gigabit Ethernet in the middle of a field wasn’t good enough.

Expect posts of cool things we find on the Fediverse at @social.mythic-beasts.com/@beasts over the next few days.

We’re pleased to announce that we now support WebAuthn/FIDO2 security keys as an option for two factor authentication (2FA). Customers have quite reasonably been requesting this feature for some time, but as we’re sure you’ll understand, this type of development work needs to be tackled carefully.

Security keys are physical devices – typically a small USB key – that can securely store digital credentials. When logging into a site, rather than typing a code from an app or sent to your phone via SMS, your browser will talk directly to your key, usually requiring you to tap a button to approve the authentication. Some systems also provide a compatible software token store, such as Apple Keychain (or Windows Hello, but we’ve not tested that).

Aside from being more convenient than typing a code, security keys are far more phishing-resistant than other methods. Convincing forgeries may trick humans into typing 2FA codes into fake sites, but WebAuthn ensures that credentials from a security key are only provided to the site for which they are intended to be used.

To set up security keys on your account, please visit the “Two-factor authentication” page in the control panel.

Use of security keys is entirely optional, and we will continue to support our existing 2FA methods. If you do want to use a hardware security key, you’ll need to purchase one if you’ve not got one already. Most of our staff are using Yubikeys, but any FIDO2 device should work.

We strongly recommend that you have at least two working 2FA methods, and make sure that they’re not tied to the same device; having SMS and TOTP on the same phone won’t help if you lose your phone.

We take account security seriously, and if you lose your access to your 2FA device, we will not reset your access by email alone as this would completely undermine the additional security provided by 2FA. (You can reset your password by email, so this would make email a single factor.)

We also know that many of our customers don’t trust SMS-based 2FA, so if you have chosen not to enable SMS-based 2FA, we won’t reset your 2FA that way either. Getting access to your account after losing all your 2FA methods is slow and tedious. This is a feature, not a bug.

We strongly recommend printing some recovery codes and filing them somewhere safe as a fallback method.

We are committed to providing support delivered by real humans. We know how frustrating it can be to have to fight your way past chatbots and virtual assistants that can’t help you in order to get to a human that can.

In fact, when you contact us, your message will be dealt with not only by a human, but by one of our technical staff who, on other days of the week, will be managing our routers, running our DNS servers, developing our control panel and maintaining all our other infrastructure.

LLMs break processes designed for humans

Modern Large Language Models (LLMs) are very impressive, and we know that many people find them useful in spite of their inherent and well-documented unreliability. One of the downsides of LLMs is their ability to produce large quantities of text that can overwhelm processes that are built to deal with human input. This is being seen in many places, from bug bounty programmes being DoSed by LLM-generated submissions, to schools unable to cope with a huge increase in the volume and size of complaints from parents.

We’ve now started to see this in our support queries. Fortunately, the volume is not yet problematic, but we have had cases where we’ve spent a disproportionate amount of time dealing with LLM-assisted ticket submissions. This includes time spent trying to decipher what the question actually is thanks to LLM-induced obfuscation, and also time spent answering tickets that are just much longer than they would have been had they been written by a human.

Dealing with LLM-generated support queries

Our target is to respond to all support queries within one working day. Providing a 100% human support response on this basis simply doesn’t work if support requests are being generated automatically. Therefore, we have amended this target to exclude queries that we believe have been generated by an LLM; if you submit a support request which we believe has been made harder or more time consuming to answer by the use of an LLM, we may reject it and ask you to resubmit a human-authored request instead.

If you want to use an LLM to help solve your query yourself that’s great. But if that’s unsuccessful, please don’t send us your LLM output as a support query; send us your input – your prompt – instead.