PHP2Shell

Your server might be running a language runtime that can be exploited by anyone who sends the right request, because PHP just released emergency updates for two critical flaws in the language itself, and the flaws sit in the engine rather than in any application, which means even a plain "Hello World" page on a vulnerable build can be attacked, and your own secure code does nothing to stop it.

The flaws are collectively called PHP2Shell. Both are rated 9.2 on the CVSS v4.0 scale.

PHP published the fixes around 14:00 UTC on October 21, a day after details leaked ahead of a planned October 22 disclosure.

What Makes PHP2Shell Different From Every Other WordPress Bug

Most vulnerability stories in this space are application-level. A plugin, a theme, a CMS component.

This one is underneath all of that.

The flaws affect nearly every PHP version back to PHP 5.4, and they've been found and reported by researchers at Wiz, Calif, and OpenAI.

An attacker doesn't need an account. They don't need a vulnerable plugin. They need a server running an affected PHP build that's serving web requests.

Why mod_php Is the Worst Case

The advisory singles out Apache's mod_php as the highest-risk configuration, and it's specific about why.

There's a demonstrated exploit where a single unauthenticated request triggers the attack before any application code runs. Not after your framework loads. Before it.

That's the difference between a bug you can patch in an afternoon and a bug that doesn't care what your application does.

PHP-FPM behaves differently, and the distinction matters for anyone triaging a large fleet.

The FPM Nuance

PHP-FPM shuts the worker down when a request fails early in setup, which limits the damage in some paths.

For one of the two flaws, PHP's own analysis supports that FPM is susceptible but says no complete FPM exploit has been shown.

The second flaw was shown to reach code execution on both mod_php and PHP-FPM, though the FPM path depends on an operation inside the running application.

So FPM isn't safe. It's just harder to reach in one of the two cases.

Who Is Affected

Every PHP installation that serves web requests is at risk, according to the PHP security advisory.

That includes:

• PHP-FPM
• Apache mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Because the flaw lives in the engine, the content of your application doesn't matter. A page that does nothing is still a target.

The Memory Read Problem

There's a second capability here that's easy to overlook because it doesn't require code execution at all.

An attacker can read memory from the PHP worker process. That memory may hold passwords, authentication tokens, API keys, and certificates belonging to other requests.

The researchers demonstrated this against applications they didn't control, which makes it independent of whatever runs on top of PHP.

Read that again, because the implications are uncomfortable. One request can potentially expose credentials from a different user's session that happened to be handled by the same worker.

What to Install

The fix is a runtime update. Updating WordPress or Laravel doesn't help, because neither of them is the PHP runtime. That comes from the server package, the host, or the container image.

After updating, restart Apache, PHP-FPM, and any long-running PHP workers. The old processes are still running the old code until you do.

The Version Number Trap

This is the detail that will cause people to get this wrong.

Linux distributions and long-term-support vendors received the patches in advance. A distribution package can therefore carry the fix under an old-looking version number.

Debian's advice is to check the package changelog for the CVE, not the version string.

If you go by version number alone, you may conclude you're vulnerable when you're not, or worse, decide you're fine when you aren't.

The Older Branches

PHP 8.1 and older no longer receive updates from the PHP project. PHP 8.2 reaches end of life on December 31, 2026.

For the older branches, the PHP security team published source backports for PHP 7.4, 8.0, and 8.1. Those help people building from source or waiting on a vendor.

They don't make an end-of-life branch supported.

If You Genuinely Can't Update Yet

The advisory is blunt about this. Only updating is a complete fix. Everything below reduces exposure to specific attack paths and does not make a server safe.

For CVE-2026-109618:

• Set memory_limit=-1 so applications can't override it
• Keep post_max_size low
• Enforce request-size limits at the web server or proxy
• Don't use RLIMIT_AS or RLIMIT_DATA as a substitute, because PHP warns they can trigger the same vulnerable path

For CVE-2026-109619:

• Set session.upload_progress.enabled=0
• Restart every worker
• On PHP 8.5, also set fatal_error_backtraces=0

The Workaround That Wasn't

Session upload progress is the setting that circulated as a workaround before the patch. The release confirms it was never a complete fix.

It's on by default, and it can reach session handling before PHP finishes setting up a request. That's why it takes part in one confirmed attack path for CVE-2026-109619, and why turning it off does nothing at all for CVE-2026-109618.

Turning it off blocks the confirmed session paths. It doesn't block other variants.

Gina Peter Banyard, a PHP core developer, was direct about this before the release, replying to someone who suggested the setting might be enough. Her words: "The only thing I can say is that the only mitigation is patching/upgrading PHP. I sadly know too much."

The Post-Patch Check Nobody Expects

After updating, review your memory settings.

The fix adds a new hard memory limit. Reaching it ends the process and stops shutdown handlers from running.

So check memory_limit and post_max_size against what your application actually needs. A limit that was fine under the old behavior can now kill processes mid-cleanup.

How to Tell If You Were Attacked Before You Patched

If you've already updated and suspect an earlier break-in, the researchers suggest watching for a few signals.

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses. That sequence matches the attack path.
• Oddly large PHPSESSID response cookies. Worth alerting on if your monitoring can see response headers.
• Unexplained restarts of PHP workers. Processes dying without a deploy or a crash to explain it.

None of these is conclusive on its own. Together, they're worth a look at your logs.

Why This One Reaches Further Than a Plugin Bug

Huntress framed the scope problem well. PHP quietly powers WordPress, Drupal, Joomla, and Magento sites, shared hosting platforms, control panels, and a lot of software that doesn't advertise that it runs PHP under the hood.

When a critical bug lands in PHP itself, rather than in one application built on top of it, the number of places you have to check grows very fast.

That's the practical consequence. An agency managing forty WordPress sites has forty application stacks, but maybe two PHP versions across them. One of those two needs a package update, a restart, and a verification.

The application inventory doesn't help you here. The infrastructure inventory does.

The Leak That Moved the Timeline

PHP had planned to disclose on October 22. Details leaked a day early, and the release moved up to October 21.

That's a familiar pattern, and it cuts both ways. Early disclosure gives defenders less time to prepare but also less time for attackers to sit on the information quietly.

The flaws affect PHP 5.4 onward, which is a genuinely long tail. Plenty of servers out there run versions nobody's thought about in years.

What to Do in Order

A short list, sequenced by urgency.

• Identify your actual PHP runtime version. Not what your host's control panel claims. What the server reports.
• Update to a fixed release on your branch, or get the distribution package that carries the CVE in its changelog.
• Restart Apache, PHP-FPM, and every long-running PHP worker. The update doesn't apply to running processes.
• Verify the restart took. A partial rollout across a pool is a common failure mode.
• Review memory_limit and post_max_size after patching. The new hard limit changes behavior.
• Check logs for the attack signatures if the server was exposed before you patched.
• Plan an upgrade path off 8.1 and older. Backports buy time. They don't buy support.

FAQ

What is PHP2Shell?

PHP2Shell is the collective name for two critical vulnerabilities in the PHP runtime, tracked as CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on the CVSS v4.0 scale and allow an unauthenticated attacker to run code on a web server.

Which PHP versions fix the flaw?

PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. The flaws affect nearly every PHP version back to 5.4.

Do I need to update WordPress or my framework?

No. The flaw is in the PHP runtime, not in any application. You need to update the PHP package on the server, the host, or the container image, then restart Apache, PHP-FPM, and any long-running PHP workers.

Which configuration is most at risk?

Apache with mod_php. A demonstrated exploit triggers the attack with a single unauthenticated request before any application code runs. PHP-FPM is also susceptible, though some paths are harder to reach.

Is turning off session.upload_progress a real fix?

No. It blocks the confirmed session paths for CVE-2026-109619 but not other variants, and it does nothing for CVE-2026-109618. PHP core developers have stated that patching is the only complete mitigation.

How can I tell whether my distribution package includes the fix?

Check the package changelog for the CVE identifiers rather than the version string. Distributions and LTS vendors received patches in advance and may ship the fix under an older-looking version number.

Can an attacker read data without running code?

Yes. The advisory notes an attacker can read memory from the PHP worker process, which may contain passwords, tokens, API keys, and certificates belonging to other requests handled by that worker.

Source: The Hacker News