We’re currently seeing about 2 security exploits in a web programming language and kind of framework known as PHP.  “The whole web could be forced to go dark!” some say, “70% of the internet could be affected!” This is alarmist nonsense, but you wouldn’t know it from looking at tech reporting.

Well, since no one else feels like being the sober man at the table, I will.

The security exploits

AI-assisted cybersecurity researchers, while going through code that probably dated back to the 1990s, managed to find two instances in existing PHP code where a very specific condition would lead to an ability by attackers to execute code on a server. That is known as a RCE vulnerability. Two of those were found in existing PHP code. For historical context, PHP was created in 1994 as “personal home page tools” by Rasmus Lerdorf.

To put it in very simple terms, an attacker could put a web site (or, more likely, web host) in a condition where the PHP server framework would just quit unexpectedly. And a failure at that point means that there is a very small opportunity of time where an attacker could execute code arbitrarily on the underlying operating system. Now that code could do anything, including decrypting passwords held in memory and then using those credentials to gain access to external systems. Obviously not a situation you want to be in.

Now, PHP has changed greatly since 1994, which is, let’s remember, 32 years ago, and software testing has as well. However with the use of AI tools, researchers were able to point out exactly what the conditions of the exploit could be found.

Initially the new vulnerabilities were meant to be kept secret until October 22nd. However, someone leaked the story, on October 21st, which set off the tone of panic.

The problem had already been found and, patched, with new, safe versions being ready for use, by the time the information was made available to the public.

So that’s 90% of the problem solved already. The remaining 10% is deployment.

This is things can become complicated. Not for most sites which are regularly maintained, but for legacy sites, which are often left to languish without maintenance but keep working as web sites, “as long as it works”. PHP, as a development language, has created a lot of those sites, largely because it’s an easy and accessible languages for creating dynamic web sites.

Those sites can still represent a problem because the patch that resolves the RCE issues was issued only for the current versions of PHP, which are all decimal versions of PHP 8. As such any site running previous versions of PHP (7 and below) would still be vulnerable. And with AI-assisted coding tools it could be easy to create a way to trigger the conditions for the RCE and insert malicious code into those sites. Those servers need to be updated to PHP8, if they’re even maintained at all, or their owners risk being liable for damage or system intrusions that originate from their servers.

That being said, those sites are not of particular concern.

Why the “crisis” is overblown

While the RCE vulnerability is serious, it’s a problem that’s resolved at the system administration level. For a lot of sites that are served through a shared web host, the site owner does not have to do anything. In fact the owner will probably already have received a notification that the system has been patched to a safe version of PHP.

For people (like myself) who use their own host to serve PHP pages — I do it through a cloud provider, but it’s the same process for people serving from their own bare-metal servers — it’s a simple matter of updating PHP at the host level. In that case it involves a little more work on the site owner’s part, but the fixed PHP versions have been available since the afternoon of October 21st. That’s when I patched my host.

No other change is required, the web app does not have to be modified in any way. The change implemented by the patch works purely at the level of PHP’s internal workings and has no other effect.

That’s why I can’t understand companies that have taken their entire site offline for extended periods as a result of the vulnerability. Once the patch is applied, you restart the system and things work as they previously did. That’s all.

Alarmist tech journalism is the real problem here. Unless you run your own web server, there is no cause to be alarmed. If you do run your own web site, maintain your system. That’s all there is to it.