Another week, another round of WordPress vulnerability reports. Elementor, TranslatePress, other plugins, serious security fixes. If you only look at the headlines, it is easy to reach a simple conclusion: good grief, WordPress must be a disaster if something constantly needs patching.

Except that it is exactly the wrong conclusion to draw.

Software needs maintenance. All software. WordPress is no exception. It is simply a system where the website owner can see that maintenance happening unusually clearly. An update appears, WordPress shows it in the dashboard, and in many ordinary cases the whole operation comes down to making a backup, clicking “Update” and checking that the website still works properly.

WebsiteGarage / Services

Explore our services.

Switching from WordPress to another CMS, framework or an application built from scratch does not magically make that responsibility disappear.

It is a bit like saying that because an engine needs oil changes, we will buy a different car or a different engine and then we will not need to change the oil anymore. We will. There may simply be no warning light reminding us that the time has come.

TranslatePress: a serious vulnerability, but look at the whole story

On August 25, Wordfence publicly described a critical vulnerability in TranslatePress, a popular plugin for building multilingual websites. Under certain conditions, an unauthenticated attacker could obtain a link that allowed the administrator password to be reset and then take over the account.

It sounds bad because it was bad.

What is more interesting, though, is the timeline. The researcher reported the problem on August 11. Wordfence verified it and passed it to the vendor on August 12. One day later, the vendor released the fixed version 3.3.2. The public disclosure did not appear until August 25, when the fix was already available.

And the story does not end there. The official WordPress repository currently shows TranslatePress 3.3.4. That version fixes another vulnerability, this time one that under certain conditions could allow malicious code to be injected into a website. The plugin has more than 400,000 active installations, which is quite a few.

Should a website owner now study CVE identifiers, analyse PHP code and think through the technical details of the attack?

No.

If you use TranslatePress, check for updates and install the latest available version. If somebody else looks after your website, make sure the update has been applied.

That is it.

What is more, there was no new security catastrophe in WordPress itself this week. The official release list shows WordPress 7.1 from August 19, while the latest release marked as a security release, WordPress 7.0.4, dates from August 12. For that one, WordPress itself instructed users to go to Dashboard > Updates and click Update Now.

So it is worth distinguishing between “WordPress has another vulnerability” and “a vulnerability was found in one of the thousands of extensions available for WordPress”. They are not the same thing.

Fine, let’s ditch WordPress. Do the updates disappear?

No.

On August 25, OpenSSL released new versions of several supported branches together with a security advisory. OpenSSL is one of the fundamental components of internet infrastructure and is responsible, among other things, for cryptographic operations. It is not a WordPress plugin and has nothing to do with which CMS you choose.

On the same day, Debian issued its own security update for the OpenSSL package and advised users to update. That same week, Debian’s list also included security fixes for the Linux kernel and other system components.

On August 27, PHP released versions 8.5.10 and 8.4.25. Version 8.5.10 was a bugfix release, and the PHP team recommended that users on the 8.5 branch update.

And now we get to the point.

You can build a website without WordPress. You can use your own application, a modern framework, a static site generator, a headless CMS or whatever else you like. You still have an operating system, a server, libraries, a runtime, packages and dependencies. They also receive updates, bug fixes and security patches.

The difference is that the website owner usually does not see it.

There is no red circle with the number 6 in the WordPress dashboard.

Someone has to know that a patch has been released. Someone has to determine whether it affects the project. Someone has to deploy it. Sometimes they first need to check compatibility with other components. Then they need to test the application and push the change to production.

If nobody does that, the application does not somehow become stable and secure.

It simply is not being maintained.

Cloudflare just showed what “let’s do it differently” actually looks like

The best example this week happened to come from Cloudflare.

On August 24, the company described the migration of its blog to EmDash, a CMS built with Astro and Cloudflare infrastructure. The migration itself happened earlier, on August 12, but Cloudflare has now published a detailed account of the whole process.

And it is well worth reading for anyone who thinks giving up a mature CMS automatically makes life simpler.

During testing, Cloudflare found problems involving content localisation, SEO, Content Security Policy and the editorial interface. The biggest oversight turned out to be scheduled publishing. It simply did not work until the issue was fixed in EmDash 0.19.0.

Then came the question of whether the new platform could handle the traffic. Cloudflare prepared separate test scenarios, including a sudden spike to 7,000 requests per second.

And when the system was ready for production, nobody simply said, “deploy it and see what happens”. A mechanism was built to route traffic between the old and new versions and return to the old platform in the event of server errors. On launch day, 1 percent of traffic was sent to the new version first, then 5 percent, then 15 percent, and only after further checks did it reach 100 percent.

The result is very good. The new blog is fast, the platform gives Cloudflare more control and it fits the company’s needs.

But that is exactly the point.

This is not a story about “WordPress is simple, therefore custom is bad”. A custom solution can be excellent. EmDash can also be excellent.

The point is: every solution needs to be maintained, tested and developed.

Cloudflare can afford that model because it has the people, infrastructure and expertise to do all of it.

The average bakery, law firm, hotel or online store does not need a team building a system for gradually routing traffic between two versions of a website. They need a website that works.

And suddenly that boring “Update” button starts looking rather attractive.

AI access increasingly needs configuration, not a magical robots.txt file

In this week’s radar, it is also worth revisiting an announcement Cloudflare made on August 21. Bot Preference Sync was announced for all plans for the following week.

Cloudflare divides AI bot traffic into three uses: Search, Agent and Training. A website owner can therefore make different decisions for bots that help people find their content, different ones for agents carrying out tasks and different ones for crawlers collecting data to train models.

Bot Preference Sync is intended to synchronise those settings with robots.txt, so the instructions published for crawlers match the rules Cloudflare actually enforces. The feature was announced for all plans from Free to Enterprise.

This is an important change mainly because the era of the blanket answer “AI bot? Block them all” is coming to an end.

Cloudflare itself gives two opposing examples. An online store may want its products to be highly visible to AI systems as well. A publisher that earns money from page views may want to remain visible in search but not agree to its articles being used to train models.

So there is no single correct configuration for every company. First you need to answer what you expect from your website’s presence in the AI world, and only then configure the bots.

Passwords are gradually becoming just one option among several

On August 25, the W3C published Web Authentication Level 3 as an official Recommendation. WebAuthn is the standard behind modern login methods that use cryptographic keys, including passkeys.

For the owner of an ordinary website, that does not mean there is anything to do this morning. It is, however, another sign that login methods that do not put all security in a password are becoming a normal part of the modern web.

If a website has customer accounts, an extensive dashboard or particularly valuable administrator accounts, then the next time you modernise the login system, it is worth asking not only about strong passwords and 2FA, but also about support for passkeys.

Which of this week’s developments matters most to you?

If you have WordPress, you do not need a PhD in security. You need an up-to-date website, working backups and someone who reacts when an update is not simply a one-click job. Open the updates screen or ask the person looking after your site whether everything is current. If you use TranslatePress, check in particular that you have the latest version.

If you have a custom website, ask the same question, just a little more broadly: who updates its dependencies, PHP or another runtime, the server and the operating system? Who receives vulnerability information? What does the patch deployment process look like?

And if the answer is “I do not know, but the website works”, then we have just found the problem.

WebsiteGarage comment

In WordPress, information about vulnerabilities is highly visible. That is partly because WordPress is a huge ecosystem, is scrutinised intensively and has an entire market of people, companies and tools looking for problems in it.

Good.

A vulnerability that has been found, reported to the vendor and patched is far less interesting than a vulnerability nobody knows about.

So the worst possible interpretation of these reports is: “WordPress constantly has updates, so I will build something custom and then I can stop worrying about it.”

You will not.

If you put a different engine into a car, the oil will still need changing. It will still need servicing. Something will still wear out or break eventually.

The difference is that WordPress very often turns on the warning light itself and shows you an “Update” button.

In a custom solution, someone first has to design that warning light, and they have to remember that it will be needed.

The real problem is not WordPress, custom development, PHP or any other technology stack.

The problem is software that nobody looks after once it has gone live.

Sources