PHP2Shell, Explained Simply: Two PHP Flaws That Can Put a Website’s Server at Risk

The physical infrastructure behind online services. Photo: Carl Lender / Wikimedia Commons, CC BY 2.0. Resized and re-encoded for web display.

You update your website, keep your plugins current, and use a strong password. So how could someone still get into the server behind it?

Sometimes, the problem is underneath the website — not in the page you see or the plugin you installed.

That is what makes PHP2Shell important. The name refers to two critical vulnerabilities in PHP itself, the software used to run many websites, including sites built with WordPress, Drupal, and Joomla. Researchers demonstrated attacks without needing a login. PHP released fixes on October 21, 2026. 1 4

The useful takeaway is simple: updating the website's PHP runtime matters, even when the website's own software is up to date.

First, what is PHP doing behind the scenes?

Imagine ordering something from an online shop:

Your browser asks to see a product.
The server runs software that prepares the page.
PHP may be the engine doing that work.
Your browser receives the result — not the PHP code itself.

Think of the website as a restaurant and PHP as part of its kitchen. A new menu does not fix a broken oven. In the same way, updating a WordPress theme does not update PHP.

A few terms make the rest easier:

CVE: a public identification number for a known security flaw. It is a tracking label, not an attack program.
Memory: the computer's temporary working space, not the space used to store files permanently.
Request: one piece of work sent to the server, such as loading a page or submitting a form.
Remote code execution, or RCE: an attacker gets the server to run instructions they chose.

The "shell" in PHP2Shell hints at gaining command-running access. It does not mean every affected website automatically gives an attacker complete control of the whole machine.

CVE-2026–109618: stopping work halfway through can leave a dangerous mess

PHP gives each request a memory budget. If the request needs too much memory, PHP should stop it safely.

This flaw concerns what can happen when that stop occurs at exactly the wrong point. Internal data may be only partly prepared, but PHP's cleanup process can later treat it as finished, valid data. That can corrupt memory and lead to code execution. 2

A simple example: using an unfinished café order

Imagine a waiter writing down your order:

The waiter marks the order as ready before finishing it.
They start writing the details: "Tea for table…"
They are interrupted before adding the table number.
Another worker trusts the unfinished order and acts on the wrong details.

The simple mistake: treating unfinished information as if it were complete.

In PHP, the unfinished order stands for data that is not fully prepared. Running out of memory at the wrong moment can interrupt that preparation. PHP's cleanup can then use the incomplete data as if it were ready. 2

Why this matters: on Apache servers using a PHP integration called mod_php, researchers validated an attack that happens before the website's own application code runs, using default PHP input and memory limits. A login screen is therefore not a dependable barrier to that attack path. 2

That does not make every attack identical. Success and reliability depend on the PHP build, extensions, server setup, and memory layout. 2

CVE-2026–109619: PHP can keep a reference to something that is already gone

Servers often reuse a PHP "worker" — a process that handles requests one after another.

This second flaw involves internal state that survives after the memory it refers to has been released. If the same worker handles another request, an early operation may use that outdated state before normal initialization replaces it. 3

The technical phrase is use-after-free: using memory after the program has given it back for reuse.

A simple example: using the previous customer's order

Now imagine the next customer arrives at the same café:

A customer at table 5 finishes and leaves.
A new customer sits at table 5.
The waiter still has the previous customer's order linked to that table.
They follow the old order instead of the new customer's order.

The simple mistake: reusing an old reference after the thing it referred to has changed. In PHP, that reference points to temporary computer memory, not a café table.

In PHP, one web request can leave an old memory reference behind. A later request handled by the same worker may use it before PHP replaces it. An attacker needs a suitable way to cause both steps; it is not simply a case of refreshing a page. 3

Why this matters: PHP's official advisory describes a path from this stale state to full remote code execution. Turning off visible error messages does not fix the underlying memory problem. 3

These analogies explain the mistakes. They are not working exploits or instructions for reproducing them.

So, how are the two flaws different?

Here is the easiest way to remember them:

CVE-2026–109618: PHP stops during memory exhaustion, then cleanup can trust partly initialized data.
CVE-2026–109619: PHP retains outdated references across requests, then a later operation uses them.

They are related, and memory exhaustion can also help trigger some paths in the second flaw. But they are not interchangeable names for one upload bug. PHP tracks them separately and fixed both. 1 2 3

What could an attacker actually do?

For a small shop owner, "memory corruption" sounds distant. The possible consequences are much more familiar:

Run unauthorized instructions: researchers demonstrated remote code execution without a login.
Expose sensitive information: researchers also demonstrated reading PHP process memory, which may contain passwords, tokens, or API keys.
Disrupt or alter a website: code execution can put the site's data and normal operation at risk. 2 3 4

There is an important limit here. The confirmed code execution described in the first advisory runs as the web worker's account. What that account is allowed to access affects the damage; it is not automatically administrator or root access. 2

Both CVEs have a 9.2 out of 10 critical severity rating under CVSS v4.0. That score describes severity — not the percentage of websites hacked or the chance your own site has been attacked. 2 3

Does this mean every PHP website has been hacked?

No. Affected does not mean compromised.

The researchers found affected paths reaching back to PHP 5.4, but the available attack paths differ by version and deployment. PHP's own warning covers installations serving web requests, including PHP-FPM and Apache with mod_php; it identifies mod_php as the highest-risk setup. 1 5

Two common assumptions are worth avoiding:

"My plugins are updated, so I'm safe." These flaws are in PHP itself.
"One public exploit failed, so I'm safe." Exploits can depend on the target's configuration and application behavior.

The sensible response is to verify and patch — not to assume either disaster or immunity.

A short timeline: how this became an urgent update

The PHP Foundation's account explains the key steps:

2024 — Early warning: work following an external PHP audit exposed signs of the out-of-memory problem. A practical route to exploitation had not yet been established, and a fix stalled amid difficult compatibility decisions.
July 30, 2026 — A new audit began: Calif started examining PHP through OpenAI's Patch the Planet program.
August 11 — The impact became clearer: Calif reported a remote-code-execution path sharing the earlier out-of-memory root cause. Fixing the problem became a top priority.
August 24 — More research arrived: Wiz reported additional attack vectors. OpenAI also contributed reports and further vectors during the coordinated work.
October 20 — Disclosure plans were disrupted: the CVE identifiers began circulating publicly. PHP published an advance warning and moved the planned release forward by one day.
October 21 — Fixes became available: PHP released 8.2.35, 8.3.36, 8.4.27, and 8.5.12, alongside the public advisories.

The lesson is not that someone discovered two bugs overnight. Researchers and maintainers had to connect the symptoms, prove the impact, and change deep parts of PHP without breaking the websites depending on it.

A beginner-friendly incident report: what a response could look like

Fictional training example — not a report of a real PHP2Shell breach. The observations below are invented to illustrate a response. They are not confirmed indicators unique to these CVEs.

Imagine a small online shop called Maple Store. Its WordPress plugins are current, but its hosting account still uses an unpatched PHP runtime.

What raised the alarm: the host notices unusual form submissions, repeated PHP worker failures, and an unexpected file in the website directory.
What that proves: something needs investigation. These observations alone do not establish that PHP2Shell was used — or even that the events have the same cause.
Immediate response: the owner contacts the hosting provider. The response team preserves logs and relevant evidence, restricts access where appropriate, and assesses whether the site needs temporary isolation.
What the investigation checks: the PHP runtime and package status, web and PHP error logs, unexpected file changes, and activity by the web worker's account. Investigators look for evidence linking the suspicious requests to unauthorized actions.
How the fix is applied: the provider installs a release containing both fixes, activates it across the relevant workers, and verifies the version or vendor backport actually serving the shop.
If unauthorized access is confirmed: the team removes persistence or rebuilds from trusted sources as appropriate, determines what data was accessible, and replaces credentials that were exposed or reasonably at risk. A patch alone does not undo a break-in.
What goes into the closing report: confirmed facts, unresolved questions, affected systems, actions taken, and follow-up checks. The team does not label the incident "PHP2Shell" without supporting evidence.

For the owner, the distinction is useful: patching closes the known weakness; incident response investigates what happened before it was closed.

What should a website owner do now?

If a hosting company manages your site

Send a clear question:

Please confirm that the PHP runtime serving my website is patched against CVE-2026–109618 and CVE-2026–109619. Which PHP version or vendor-fixed package is running, and has the update been activated for all PHP workers?

You do not need to understand the exploit to ask for that confirmation.

If you or your developer manage the server

PHP's October 21 security release contains these fixed versions: 1

PHP 8.2.35
PHP 8.3.36
PHP 8.4.27
PHP 8.5.12

For example, a site on the 8.3 branch needs the fix in 8.3.36 or a later release containing it — not an unrelated jump to a different branch just because its version number looks larger.

A few practical checks matter:

Update the PHP runtime, not just the CMS, theme, or plugins.
Follow your provider's process to restart or replace affected workers and activate the update.
Verify the PHP actually serving the website. A command-line installation can be different.
Check other sites, containers, and servers you manage, not only the main homepage.
For PHP 8.1 or older, move to a supported branch or obtain an explicitly confirmed vendor backport. Some vendors patch older packages without changing the upstream PHP version number. 1 2 3

Do not copy random configuration "fixes" from social media. PHP says temporary settings reduce particular attack paths but do not provide complete protection. Removing a PHP memory cap also changes how much memory a request can consume, so it belongs in a qualified administrator's risk assessment — not a beginner's quick-fix checklist. 1 2

If you find signs of a break-in, patching is only one part of the response. Ask your host or incident-response team to investigate and determine whether exposed credentials need replacing.

The bottom line

PHP2Shell is a reminder that a website is more than its visible pages and plugins.

One flaw makes cleanup trust unfinished data.
The other makes a later request trust stale data.
Both can have serious consequences under the right conditions.
The practical next step is to confirm that the PHP underneath your site has the fix.

You do not have to become a security researcher. You just need to make sure the right layer gets updated.

References

Written by: Logesh Penetration Tester, SecureX Digital

Contents