20th_Ping: ElePHPant Disaster — Script

Today's subject is “PHP2Shell”.

If you are not an IT engineer, you may have no idea what that means.
“There was a bit of a commotion on the internet.” That is all you need to know for now.

And I'm Peter. A kind of virtual host, I suppose.

Did you know that, at 21:00:15.034 UTC on 21 October 2026, the producer was staring at his computer with lifeless eyes?

I thought we might take this opportunity to recount what happened.

If you would be so kind, offer a prayer for IT engineers the world over as you listen.

Ah. The necromancer I called in appears to have done a fine job.

Now, as to why the producer had become Caffeine Man at 21:00:15.034 UTC on 21 October 2026: the cause was a technical problem called “PHP2Shell”.

Incidentally, are you familiar with the term PHP?

Jesse, you must not bring stories from another timeline into this one.

To return to the subject.

PHP is a programming language.

Put simply, it is one of the technologies widely used to run websites on the internet.

…Might I continue?

There was a problem with PHP, which is widely used around the world—a so-called “bug”—that could be exploited to do whatever one pleased on the computer it was installed on.

This issue is sometimes referred to as “PHP2Shell”.

It is not a magic lamp, so no.
You would stand a better chance by working for it.

Ordinarily, when a problem of this sort is discovered,
the parties concerned first exchange information in confidence.
It is then made public once a fix or countermeasure is ready.

The purpose is to have the problem fixed beforehand, so that security is not compromised.

This time, however, matters were different.

PHP's development community had announced that the fix and details would be made public at 14:00 UTC on 21 October 2026. Security experts were keeping silent until then, in keeping with an established convention that had been widely communicated in advance.

A certain “security expert”, however, disregarded this gentlemen's agreement and disclosed the information ahead of time.

Consequently, word of the problem spread widely before information on how to defend against it was available.

Well, “security experts” around the world did condemn the act in the strongest terms. That much is a fact.

Incidentally, the problem is said to have existed since 2012, and there have been reports that the development community became aware of it around 2024.

It has also been said that exploiting it in practice requires a rather demanding set of conditions; some experts have suggested that the threat is being overstated.

Nonetheless, in a world where AI is so widespread, exploiting such a problem has become considerably easier. The likelihood of those “difficult conditions” being met is not zero, either. We certainly cannot afford to be complacent.

I cannot quite follow the analogy, but the US National Security Agency and the UK's National Cyber Security Centre were advising people to take their sites offline if they could not update them immediately. Some did shut their sites down as a precaution.

In Japan, even the Prime Minister personally called for action on their official X account.

That gives you some idea of the commotion it caused worldwide.

…And that is the background to our story. Does that give you the general picture?

Perhaps because it attracted so much attention, the response was swift; I think one could say that the situation has settled down.

Of course, not everything has been resolved, and there were various problems along the way.

An excellent piece of research, indeed. It is hardly surprising that it won an Ig Nobel Prize.

The “problem” I had in mind, however, was rather different.

After various twists and turns, PHP's development community did release a fix for “PHP2Shell”. That, in itself, was good.

Behind the scenes, however, the IT engineers managing those servers were left with their heads in their hands.

I imagine many an IT engineer was thinking, “If only this weren't real.”

The problem was this: official packages from the distributors were considerably delayed.

Now, the PHP I mentioned earlier is not normally something you run on an ordinary computer.
Though you certainly can.

It is more commonly run on a dedicated computer called a “server”,
and those servers run a special operating system called “Linux”.

Linux, bundled together with software commonly used on servers, is what we call a “distribution”.

The organisation that develops or supplies that distribution is the “distributor”.

I doubt carbonara would make a suitable topping for that.
Bacon or sausage would be more appropriate, I should think.

As for the caramel macchiato, I recommend chocolate chips.

PHP's own development community released its patched version at 14:00 UTC on the 21st, but the distributors were slow to make it available.

IT engineers standing by to apply the fix immediately were left waiting in frustration.

After all, the servers remained unprotected in the meantime.
Shutting down the server would at least have helped, but some could not do that.

There were mitigation measures to reduce the impact of the problem,
but it would scarcely be an exaggeration to call them little more than reassurance.

The advice was essentially, “Applying the latest patch is the one and only solution.”

If calories are a concern, a caramel macchiato may be an ill-advised choice.
A caffè mocha might at least be preferable.

The producer's day job is apparently something along the lines of IT engineering,
and he spent a great deal of time dealing with this problem.

He had been standing by since shortly before the official development community released the fix,
waiting for the distribution to make it available.
He told me he was growing rather irritated by the delay.

It had, after all, obliged him to stay up all night.

There were alternatives, certainly.

For instance, the latest version from the official development community was already available.
One could have installed that on the server.

But doing so would put it well outside the distribution's management,
which can cause considerable trouble later.

When the distributor eventually released its official fix, it might not install properly. There was also the risk that subtle differences in configuration would cause the system to behave oddly.

A server is expected to run reliably.
One is therefore reluctant to introduce anything out of the ordinary, even in an emergency.

The short answer is yes.

For the distribution called Ubuntu, the fix was available within an hour of the official development community releasing its own fix.

The commercial distributions commonly used in business, however, were slow across the board.

Take Amazon Linux and Red Hat Enterprise Linux, for example; both are widely used in professional settings. Their fixes only became available some ten hours after the official development community's release.

How difficult it was would depend on their circumstances.
In the Far East, it fell late at night; I imagine many were obliged to stay up all night.

Presumably, the distributors had their reasons for being unable to release the fixes immediately.
Whether one can accept that is another matter.

Particularly for those with special support contracts.

One thing is clear: this risk needs to be properly recognised.

Security responses often depend on applying updates supplied by the distributor.
Yet, in most cases, there is no guarantee that those updates will arrive promptly.

Planning on that basis is therefore essential if we are to protect both IT engineers and their systems.

Measures such as introducing a web application firewall or preparing a way to apply updates independently of the distributor need to be arranged in advance, according to the requirements of the system.

That is the most important lesson to be learnt from PHP2Shell… or so the producer groaned, now a living ghost.