TL;DR

• MySQL 8.0 goes End of Life (EOL) In April 2026
• From 31 Jul 2026 AWS will start charging extra for “Extended Support”
• There are options, you don’t have to upgrade to MYSQL 8.4

What Happens When AWS RDS MySQL 8.0 Reaches End of Life?

• AWS automatically enrols your RDS MySQL 8.0 instance into Extended Support
• Additional charges are added to your monthly AWS bill
• Security updates continue for up to 3 more years
• No automatic optimisation or performance improvements

This is primarily a commercial decision by AWS, not a technical upgrade.

Your Options

Option 1: Do Nothing and Pay for Extended Support

This is the default outcome if no action is taken and there is nothing wrong with it. AWS will automatically upgrade your instance to Extended Support.

Pros

• No work required
• Continued security patches
• Supported until approximately July 2029

Cons

• Higher monthly costs
• No technical benefit
• Unnecessary operational spend

For cost-conscious businesses, this is rarely the best long-term choice.

Option 2: Upgrade to MySQL Community 8.4

Move to MySQL Community 8.4, which is supported until 31 July 2029.

Pros

• Avoid Extended Support charges
• Remain on community MySQL

Cons

• Requires application compatibility testing
• Potential query or driver differences
• Requires Developer time and regression testing

Option 3: Move to Aurora MySQL 8.0 (Best of both worlds)

For most organisations, the most cost-effective and lowest-risk option is to migrate to Amazon Aurora MySQL 8.0. 

Aurora is AWS’s MySQL-compatible database engine. It is fully compatible with MySQL 8.0, and for most applications behaves identically.

Aurora MySQL 8.0 is supported until 30 April 2028, without Extended Support charges.

Why this is attractive:

• 100% MySQL 8.0 compatible
• Avoids 2026 Extended Support price increases
• Often improved performance and storage resilience
• Potential for zero-downtime migration (dependant on data etc)

Why SMEs Should Plan Now

• Avoid sudden AWS bill increases in 2026
• Schedule migration during low-risk periods
• Controlled testing window
• Maintain predictable cloud operating costs
• Avoid rushed engineering decisions

Leaving this until mid-2026 could result in rushed decisions, increased costs, or unnecessary operational risk.

Summary: Best Path for AWS RDS MySQL Users

Need Help With an AWS RDS to Aurora Migration?

We are a UK-based Linux and AWS consultancy specialising in:

• AWS RDS optimisation
• Aurora MySQL migrations
• Zero-downtime database cutovers
• Cost reduction and cloud optimisation for SMEs

If you would like a review of your current AWS RDS MySQL estate and projected 2026 cost exposure, contact us.

Frequently Asked Questions

Will AWS automatically upgrade my RDS MySQL 8.0 instance?
Yes. After 31 July 2026, AWS will automatically enrol your instance into Extended Support unless you migrate or upgrade beforehand.

Is Aurora MySQL fully compatible with MySQL 8.0?
Yes. Aurora MySQL 8.0 is designed to be fully compatible with MySQL 8.0 Community Edition.

Can the migration be done with zero downtime?
In most cases, yes. Using replication and controlled cutover techniques, downtime can be reduced to seconds or avoided entirely.

How long does an RDS to Aurora migration take?
Typically a few days including testing, depending on database size and complexity.

The post Avoid Surprise AWS RDS Charges in 2026 appeared first on Dogsbody Technology.

PHP 8.1 goes end of life on the 31 December 2025. After this date, known security flaws will no longer be fixed, leaving your sites exposed to significant security vulnerabilities.

It is important to update to a newer version of PHP. We recommend upgrading to one of the latest supported versions — all of which include new features and backward-incompatible changes that should be thoroughly tested before deployment in a production environment.

You may need to ask your developers to update your codebase, verify plugin compatibility, and ensure your applications are supported on newer PHP versions.

Supported PHP Versions:

• PHP 8.2: Supported until 31 December 2026 
• PHP 8.3: Supported until 31 December 2027
• PHP 8.4: Supported until 31 December 2028  (Note: PHP 8.4 is still in Beta Support for WordPress and may not be fully compatible yet.)

Want to find out what your options are and what actions you need to take to stay secure. We can help just

Not sure which PHP version your server is using?
It might be time for a Server Audit to get a complete view of your infrastructure. We provide a traffic light report that highlights the good, the bad, and the ugly.

Want to know your options and what actions you need to take to stay secure?
We can help – just get in touch.

The post PHP 8.1 will go end of life – 31 Dec 2025 appeared first on Dogsbody Technology.

1. Do nothing
2. Build new infrastructure (and move to the latest Ubuntu LTS release)
3. Perform an in-place upgrade
4. Buy an annual subscription to Ubuntu Pro – Extended Security Maintenance (ESM) – UPDATED 12 Nov 2024
5. Just shut it down

Lets explore the pros and cons of each option.

1) Do Nothing (Not Recommended)

By far the easiest of the options but could end up costing you more in the long run. We do not recommend this option.

Doing nothing mean you have a ticking time bomb on your infrastructure. Your infrastructure will no longer receive security updates for the Ubuntu base OS, critical software packages and infrastructure components as well as no security maintenance for high and critical CVEs. This will probably also cause Compliance issues (PCI), Software incompatibility and make your whole network more vulnerable.

Using this option will also mean that more work will be required when you upgrade your server in the future costing you more.

The post 5 options for Ubuntu 20.04 EOL in April 2025 appeared first on Dogsbody Technology.

A domain auth code can be used to steal a domain from you.

Any domain owners of the following TLD’s are advised to reset the authCode for their domain.

Some registrar’s are batch voiding and regenerating auth codes for affected domains but not all.

Affected TLD’s

gTLDs

• .art
• .bar
• .basketball
• .best
• .college
• .ceo
• .design
• .fans
• .feedback
• .frl
• .fun
• .gent
• .host
• .icu
• .ink
• .love
• .observer
• .online
• .ooo
• .press
• .protection
• .realty
• .reit
• .rent
• .rest
• .security
• .site
• .space
• .storage
• .store
• .tech
• .theatre
• .tickets
• .website
• .wiki
• .xyz

Official ccTLDs

• .bh, Bahrain
• .fm, Federated States of Micronesia
• .fo, Faroe Islands
• .gd, Grenada
• .gl, Greenland
• .la, Laos; also borrowed for Los Angeles
• .pw, Palau
• .sk, Slovakia
• .vg, British Virgin Islands

Unofficial ccTLDs

• .ae.org, for United Arab Emirates
• .ar.com, Argentina
• .br.com, Brazil
• .cn.com, China
• .com.de, Germany
• .de.com, Germany
• .eu.com, European Union
• .gb.com, Great Britain
• .gb.net, Great Britain
• .gr.com, Greece
• .hu.com, Hungary
• .jpn.com, Japan
• .jp.net, Japan
• .kr.com, Korea
• .no.com, Norway
• .qc.com, Quebec
• .ru.com, Russia
• .sa.com, Saudi Arabia
• .se.com, Sweden
• .se.net, Sweden
• .uk.com, United Kingdom
• .uk.net, United Kingdom
• .us.com: United States
• .us.org: United States
• .uy.com, Uruguay
• .za.com, South Africa

Any domain owners of these TLD’s are advised to reset the authCode for that domain.

The post TLD’s affected by CentralNic Registry authCode reset appeared first on Dogsbody Technology.

It is important to update them to a newer version. We would recommend updating to either:

• 8.1 supported until 25 November 2024
• 8.2 supported until 08 December 2025
  

This new minor version brings with it a number of new features and a few incompatibilities that should be tested for before switching PHP versions in production environments.

You may need to get your developers to update code, check plug-ins and app versions for supportability:

• Deprecated Features when migrating from 8.0.x to PHP 8.1.x

WordPress is still only showing “beta support” for anything PHP 8.0 or above, as WordPress say:

WordPress is not fully compatible with PHP 8.0 or 8.1. All remaining known PHP 8.1 issues are deprecation notices.

Please note, a deprecation notice is not an error, but rather an indicator of where additional work is needed for compatibility before PHP 9 (i.e. when the notices become fatal errors). With a deprecation notice, the PHP code will continue to work and nothing is broken.

At the time of writing PHP 8.2 for wordpress was still waiting on the dev notes.

Not sure what version your server is on? Maybe it’s time for a Server Audit so you have a full picture of your infrastructure – We produce a traffic light report telling you the good, the bad and the ugly…

Want a hand with your PHP upgrade? Get in touch!

The post PHP 8.0 will go end of life – 26 Nov 2023 appeared first on Dogsbody Technology.

Below are three simple ways to secure your WordPress site.

1. Use the latest WordPress Version

Whenever WordPress sends out a new update, it means they may have fixed some bugs, added some features, but most importantly they have added some security features and fixes.

When you see the message above: Update it.

Nowadays, with one-click update, it’s very easy to upgrade your WordPress Version.

Make sure your theme and plugins are compatible with this latest version of WordPress. If an update has been rolled out and it’s not a security update, I suggest you wait for your plugins and themes to become compatible before upgrading.

2. Keep Your WordPress Plugins Updated

As I mentioned above, WordPress releases an update to fix bugs and vulnerabilities, and this is the same for plugins. This is a really quick update to make:

My 3 really simple steps:

1. Log into your WordPress Site via wp-admin
2. Click on ‘Plugins’ on the Left hand side
3. Click the Update Now button for the vulnerable plugin

Many times, an out of date plugin or 3rd party script can create a security hole in your WordPress website causing it to become vulnerable.

In general you should always use plugins which are continually updated and have good support.

If you are using a plugin which has not been updated for a while, find an alternative to it. If you have an installed plugin, remove it.

3. Keep Your WordPress Themes Updated

Yes! Even The Themes! Both plugins and themes are built on code. Mostly PHP to be specific. And, that code will eventually be outdated. When a theme (or plugin) is outdated, it’ll still work. Sure. However, it will be more prone to being exploited since it’s an easy way in for attackers.

Make a consistent schedule to regularly check and download the latest updates of themes (and plugins).

These can be found directly on the WordPress dashboard on the “Updates” pages.

For more helpful tips try:

But why is this so important?

Hackers created over 65 million new malware in the first quarter of 2019 alone!

Plugins are being updated all the time. For example, on a single day (24 Aug 2021) the following plugin vulnerabilities were all fixed and were ready to be updated:

• Contact Form Entries < Version 1.2.1 – Reflected Cross-Site Scripting
• TextME SMS < Version 1.8.9 – Authenticated Stored XSS
• Live Scores for SportsPress < Version 1.9.1 – Authenticated Local File Inclusion
• Live Scores for SportsPress < Version 1.9.1 – Reflected Cross-Site Scripting
• SMTP Mail < Version 1.2 – Reflected Cross-Site Scripting (XSS)
• SMTP Mail < Version 1.2.2 – Authenticated SQL Injections
• Contact List < Version 2.9.42 – Reflected Cross-Site Scripting
• Coupon Affiliates for WooCommerce < Version 4.11.0.2 – Reflected Cross-Site Scripting
• Podlove Podcast Publisher < Version 3.5.6 – Unauthenticated SQL Injection
• Recipe Card Blocks < Version 2.8.1 – Reflected Cross-Site Scripting
• Recipe Card Blocks < Version 2.8.3 – Contributor+ Stored Cross-Site Scripting

As of June 2020 over 73% of the most popular WordPress installations were vulnerable. They were vulnerable to exploitable vulnerabilities that can be detected with free automated tools, within seconds.
It only takes a couple of minutes for a malicious attacker to run an automated tool that can discover these vulnerabilities and exploit them. This highlights the importance choosing the right WordPress web host that auto updates both plugins and WordPress.

The most common vulnerabilities

Arbitrary File Upload & File Viewing: Lack of file type and content filtering allows for upload of arbitrary files that can contain executable code which, once run, can do pretty much anything on a site. Instead of allowing only certain file source to be viewed (for example plugin templates) the lack of checks in the code allows the attacker to view the source of any file, including those with sensitive information such as wp-config.php

Privilege Escalation: Once the attacker has an account on the site, even if it’s only of the subscriber type, he can escalate his privileges to a higher level, including administrative ones.

SQL Injection: By not escaping and filtering data that goes into SQL queries, malicious code can be injected into queries and data deleted, updated or inserted into the database. This is one of the most common vulnerabilities.

Remote Code Execution (RCE): Instead of uploading and running malicious code, the attacker can run it from a remote location. The code can do anything, from hijacking the site to completely deleting it.

How Dogsbody can help

So, you maybe wondering ‘How will I know I’m vulnerable in the first place’.

The easiest way is to log into your WordPress site and take a look.

Feature image by mmayyer licensed Unsplash.

The post Three Easy Ways To Secure Your WordPress Site appeared first on Dogsbody Technology.

Here we look at your 5 options for Ubuntu 18.04 EOL.

1. Do nothing (Not recommended)
2. Build new infrastructure and move to the latest Ubuntu LTS release (Recommended)
3. Perform an in-place upgrade
4. Buy an annual subscription to Ubuntu Pro – Extended Security Maintenance (ESM)
5. Just shut it down

Lets explore the pros and cons of each option.

1) Do Nothing (Not Recommended)

By far the easiest of the options but could end up costing you more in the long run.  Dogsbody do not recommend this option.

Doing nothing mean you have a ticking time bomb on your infrastructure. Your 18.04 Infrastructure will no longer receive security updates for the Ubuntu base OS, critical software packages and infrastructure components as well as no security maintenance for high and critical CVEs. This will probably also cause Compliance issues (PCI), Software incompatibility and make your whole network more vulnerable.

Using this option will also mean that more work will be required when you upgrade your server in the future costing you more.

The post 5 options for Ubuntu 18.04 EOL appeared first on Dogsbody Technology.

PHP 7.4 goes end of life (EOL) on the 28 November 2022 meaning known security flaws will no longer be fixed and sites are exposed to significant security vulnerabilities.

It is important to update them to a newer version. We would recommend updating to either:

• 8.0 supported until 26 November 2023
• 8.1 supported until 25 November 2024

New major PHP versions bring with it a number of new features and some incompatibilities. These should be tested before switching PHP versions in production environments.  You may need to get your developers to update some code, check plug-ins and app versions for the new PHP supportability:

• Deprecated Features when migrating from 7.4.x to 8.0.x

WordPress 5.6 to 5.9 state that they have added “beta support” for PHP 8.0 and 8.1 however no one know when it will be out of beta status. Beta support means that the compatibility of WordPress with PHP is still being tested. We would usually advise not to use it on a production server until it is fully supported by WordPress.

Not sure what version your server is on? Maybe it’s time for a Server Audit so you have a full picture of your infrastructure – We produce a traffic light report telling you the good, the bad and the ugly…

Otherwise want a hand with your PHP upgrade? Get in touch!

The post PHP 7.4 will go end of life on 28 November 2022 appeared first on Dogsbody Technology.

After this date there will be no security updates released for Debian 9 and servers will not be patched for any new vulnerabilities discovered.

Leaving old Debian 9 “Stretch” systems past 30 June 2022 leaves you at risk to:

• Security vulnerabilities of the system in question
• Software incompatibility
• Compliance issues (PCI)
• Poor performance and reliability
  and
• Making your network more vulnerable as a whole

Debian 11 “Bullseye” Supports:

• Apache 2.4.48
• MariaDB 10.5
• MySQL 8.0
• PHP 7.4
• Python 3, 3.9.1

Not sure where to start? Contact us to find out how we can help you.

The post Debian 9 “Stretch” goes End of Life (EOL) June 2022 appeared first on Dogsbody Technology.

This was a “zero day exploit”, meaning that the bad guys found this vulnerability and started exploiting it before that vulnerability could be fixed. The NIST has catalogued this as CVE-2021-44228 with a 10/10 severity (the most severe).

Who’s affected

Put simply – Java applications that use the log4j package. It is almost impossible to conclusively list all affected software and services, given such widespread use and the multiple versions and implementations that affects the ability to exploit the vulnerability.

An attempt to list responses from as many vendors and service suppliers can be found here, though this list shouldn’t be taken as authoritative.

What you can do

Most importantly you should take immediate action to do the following:

• Identify usage of affected log4j versions within your infrastructure.
• Apply available patches from your software vendors, or consider disabling elements of your infrastructure/services until patches are available.
• Monitor your systems/logs for signs of previous and ongoing exploit attempts.
• Take immediate steps to restore any affected systems to a known good state.

Our Customers

We are actively following the steps above and triaging those affected. Those most severely affected will have already been contacted and we will continue to proactively monitor all infrastructure to ensure all systems are patched as soon as possible.

The post CVE-2021-44228 – Log4j2 vulnerability appeared first on Dogsbody Technology.