What PHP2Shell Actually Does — A Bartender Analogy

If you are like me, you spent the past couple of days revisiting old websites and projects.

Updating old dependencies. Checking forgotten servers. Making some uncomfortable decisions about what can still be patched, what needs a bigger upgrade, and which old websites or apps may simply have to be retired because of PHP compatibility.

Maybe you already know exactly what the exposed vulnerability does because you are a senior developer and memory corruption bugs are your idea of light reading.

But if you are like me, you might need an analogy before it really clicks.

If you are the latter one, here is my explanation.

Imagine PHP is a bartender.

A customer walks up to the bar and orders a drink.

The bartender takes the order, grabs a glass, uses a couple of bottles, maybe writes something down, prepares the drink and serves it.

Once the order is finished, the bartender clears the counter and gets ready for the next customer.

That is how it should work.

Customer A comes in, gets served, everything related to that order is cleaned up, and Customer B starts with a clean workspace.

Now imagine that under some very specific circumstances, the bartender does not clean everything up properly.

Maybe there is still a note sitting on the counter saying:

“Use the bottle in position number 4.”

The original bottle is already gone.

But the note is still there.

Normally this would just be sloppy bartending.

The problem starts when the next customer is not a normal customer, but somebody who knows exactly how this mistake can happen.

They deliberately place their own bottle into position number 4.

The bartender comes back, sees the old note and thinks:

“Right. This is the bottle I was using.”

Except it is not.

It now belongs to the attacker.

That is roughly the idea behind this kind of PHP vulnerability.

PHP can end up keeping a reference to something in memory that should already have been cleaned up.

An attacker can try to manipulate what ends up in that memory location next.

If everything lines up, PHP may then treat attacker-controlled data as if it were something legitimate and trusted.

And that is where things can get ugly.

Normally, a website visitor is like a customer at the bar.

They can order from the menu.

They can ask for things the bartender is allowed to give them.

What they cannot normally do is walk behind the bar, open the cash register, read private notes, or tell the bartender what to do with the entire building.

A successful exploit can potentially change that relationship.

Instead of:

“I would like a beer.”

it becomes something closer to:

“Open that cupboard.”

“Empty the cash register for me.”

OR

“Read this file.”

“Run this command.”

And that is basically where the “shell” part of PHP2Shell comes from.

The attacker is no longer just interacting with the application as a normal visitor. In the worst case, they can gain the ability to execute commands on the server itself.

What makes this particularly uncomfortable is that your application does not necessarily have to be badly written.

You might have a perfectly normal Mautic, WordPress, Drupal or custom PHP application sitting there.

The bug is lower down.

It is in PHP itself.

Which is also why the fix is not “check your forms” or “sanitize your inputs better.”

The real fix is much less exciting:

patch PHP.

And if you are running a lot of servers, patch PHP everywhere.

Preferably before somebody else decides to test whether your bartender still remembers to clear the counter.