In the second half of October a serious vulnerability was found in PHP, a programming language, and sites around the world rushed to update. PHP has run a great many websites for a long time, so the reach was very wide. First we confirmed that our services don't use PHP. Then we checked this site for any sign that someone had got in from outside or taken anything out. There was none.
Shortly afterwards, an equally serious vulnerability was reported in Next.js. That one was not someone else's problem: this site and our other apps are built with Next.js. The reports described one flaw that, under the right conditions, lets an outsider run commands, and another that can bring a server down.
When we checked, this site did not use several of the features where the problem arises, so we could say the chance of real harm was low. But a low chance is not the same as no hole, and no workaround had been published. We decided to move to the fixed version.
On 2 November, at the office, we went through every project we have. We compared the list of parts that run in production one by one and raised anything on an old version to the latest. This site was on version 16.3.8, so we moved it to 16.4.3, where the problems are fixed.
Raising a version is not the end of it. An update can quietly break something that used to work. After each one we ran the type checks, a build in the same shape as production and a check of every page before publishing, and once it was live we ran the same check again against production.
This site has a check that runs after every release and confirms that production really is running the new version. It exists so that a release that silently stays on the old version never goes unnoticed, and this time too it confirmed the switch.
We also added defences. Describing them in detail would hand attackers a guide, so only in outline. Operations sent from other websites were already refused at the door; we checked again that this holds at every entrance.
Cyber attacks are rising everywhere. The method that stands out is not breaking in through the front, but slipping malicious code into parts that everyone uses, and getting into the computers and systems that take those parts in. However carefully you write your own code, it counts for little if a part you pulled in is tainted.
So we have strengthened how we watch as well. We already use a service that alerts us when a vulnerability is found in a part we depend on, but we no longer simply wait for alerts: we set a routine for checking every project ourselves. We also pinned the versions of our parts, so their contents cannot change without us knowing.
There is nothing you need to do as a user. The update is done on the server side, and this is not a request to change your password. If a message claiming to be from us asks for your password or payment details, it is not from us. We never ask for passwords by email or chat.
One mistake to record. This site had been telling the outside world what it is built with, all along. It was the default setting from when we built it, and we did not notice until this check. Saying so does not mean the site gets broken into, but it tells an attacker which part, and which hole, to try first. We have now turned it off. From now on, settings left at their defaults are part of what we check.
Defence has no finish line. This work only buys peace of mind until the next vulnerability turns up. So we will keep doing three things: never leave a known problem alone, check after every update, and keep nothing we don't use. If you run a website yourself, one suggestion: write down what parts it runs on and which version of each. If you don't know, ask whoever built it.