New PHP Bug, No Patch Yet: The One Setting That Covers It

Two days ago the PHP project shipped emergency fixes for the bugs nicknamed PHP2Shell. We wrote about them, we patched, and we had a small celebratory coffee. Then on October 23 a new headline arrived: PHP warns of another unpatched remote code execution bug. Cue the second coffee.

Here is the short version before you spill it. The new bug is real, and it does not have a patch yet. But it can only be reached through a rare mix of settings and code, and one setting closes it. If you followed the October 21 advice, you may already be done.

The headline versus the fine print #

"Unpatched remote code execution" is a scary phrase. Remote code execution, or RCE, means an attacker could run their own code on your server. Unpatched means the official fix is not out yet. Put together, it sounds like the front door is wide open.

The fine print tells a calmer story. The PHP project calls this an informational advisory, not an emergency release. In its own words, it is "an unlikely RCE vector." That is security speak for a door that does exist, but sits at the back of the house, behind a locked gate, at the top of a ladder most people never put up.

What PHP actually said #

On October 23, 2026, the PHP project published an informational advisory about session upload progress. The bug has an ID, CVE-2026-115560. PHP is handling it in its regular release cycle, so the fix ships with the next routine bugfix release, along with a full write-up. PHP has not given a date for that release yet.

Until then, PHP suggests one change: set session.upload_progress.enabled to 0. It is the same setting PHP already listed on October 21 as a way to reduce the risk from CVE-2026-109619, one of the two PHP2Shell bugs. If you made that change then, PHP says to keep it in place, and you need to do nothing more.

It takes all four to open the door #

This is the part the headlines skip. The bug can only be reached when all four of these are true at the same time.

• One: the server or app settings set session.serialize_handler to php_binary or php_serialize. The default is plain php, so a standard install does not do this.

• Two: the application's own code switches that handler back to php while it runs, using ini_set().

• Three: that switch happens before the code calls session_start().

• Four: session upload progress is still turned on. It is on by default.

Miss any one of these and the door stays shut. Think of it as a combination lock with four dials. Most sites never even touch the first dial.

PHP says applications that never change the serialize handler while running can keep the feature turned on. We turned it off anyway, and we explain why below.

Wait, what is a serialize handler? #

When you log in to a website, PHP keeps a small file of facts about your visit, called a session. Your cart, your login, maybe your favorite color theme. The serialize handler is the format PHP uses to write those facts down and read them back. There are a few formats to choose from. Trouble starts when the settings pick one and the code quietly swaps to another partway through. It is like starting a grocery list in English and finishing it in shorthand. Somebody is coming home with the wrong cheese.

And what is session upload progress? #

It is an older PHP feature. While a file uploads, PHP writes how much has arrived into the session, so another page can read it and draw a progress bar. These days most websites draw progress bars with JavaScript in the browser instead. That is why so few sites miss the feature when it is gone.

How this connects to PHP2Shell #

PHP2Shell is the nickname for two critical bugs, CVE-2026-109618 and CVE-2026-109619. PHP fixed them on October 21 in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and rated both 9.2 out of 10. We covered those fixes in our guide to the October PHP fixes.

The new bug is separate. Updating to those versions does not fix it. But it lives in the same corner of PHP, and the setting that blocks the known session paths for CVE-2026-109619 blocks this one too. One switch, two jobs. We do love a multitasker.

Keep your priorities straight, though. Attackers are still probing hard for the PHP2Shell bugs. The Hacker News reports that attempts climbed into the millions after the October 21 disclosure, while no attacks on the new bug have been reported. If you have not installed the October 21 updates yet, do that first. This new bug is the smaller fire.

What we have done at Jag Journey #

• The big fixes are in. Every PHP version that serves websites on our servers already runs with the October 21 fixes.

• The switch is off. On October 23 we turned off session upload progress for every PHP version that runs our websites, then reloaded PHP so the change took effect.

• We checked the dials. Our server settings use PHP's default serialize handler, so the first condition is never met. We also searched the code we host. Nothing on our servers relies on session upload progress, so no site lost a feature.

• We will keep watching. When PHP ships its next bugfix release, we will install it and read the full advisory. Then we will decide whether the feature ever comes back. Spoiler: we will probably not miss it.

Your five-minute checklist #

1. Install the October 21 updates first. If any of your sites still run older PHP builds, that is the bigger risk by far.

2. Turn off session upload progress. Set session.upload_progress.enabled = 0 in your server's php.ini, your PHP-FPM pool or your web server configuration. On a cPanel server, the MultiPHP INI Editor in WHM lets you add the line for each PHP version. On shared hosting, ask your host to do it.

3. Restart PHP. Restart or reload PHP-FPM, or your web server, so every worker picks up the change. Saving the file alone is not enough.

4. Check that it stuck. A quick look at your PHP settings should show session.upload_progress.enabled as Off. If you use a phpinfo page to check, make it private and delete it right after.

5. Search your code. If you build your own apps, search for serialize_handler. No results means you never reach the second dial.

6. Install the next PHP release. Keep an eye out for the next routine bugfix release and install it when it lands.

Will turning it off break anything? #

Almost certainly not. File uploads keep working exactly as before. The only thing that stops is PHP's built-in progress tracking in the session. If a page on your site shows an upload progress bar that reads from the session, that bar would stop moving, but the upload itself still finishes. Most modern sites, including the WordPress media library, draw their progress bars in the browser and never notice.

PHP's own October 21 advisory even suggests leaving the feature off after you patch, if you do not need it. It describes the feature as hardly used and hardly tested. That is about as close as a software project gets to a polite shrug.

A note for developers and app builders #

• If your code calls ini_set() to change session.serialize_handler, pick one handler and set it in your configuration instead. Changing it while the app runs is what makes this bug reachable.

• Set the upload progress switch where PHP reads it before a request begins: php.ini, the FPM pool or the server configuration. PHP warns that ini_set() and .user.ini files are not reliable for this one.

• Rebuild your container images after you change the setting, and again after the next PHP release lands.

• Need an upload progress bar? Draw it in the browser. JavaScript upload events do the job without touching the session at all.

A tiny glossary for the rest of us #

• CVE: a public ID number for a security bug, so everyone talks about the same one.

• Informational advisory: a heads up from the project without a new release. Read it, act on it, skip the panic.

• Remote code execution (RCE): an attacker runs their own code on your server. The worst kind of house guest.

• Session: the small set of facts a website remembers about your visit.

• Mitigation: a step that lowers the risk until the real fix arrives. A bucket under the leak, if you like.

If we host your site #

Keep the coffee warm. You do not need to do anything. The October 21 fixes are in, the switch is already off, and we will install PHP's next release when it ships. If you have questions, reach out through our contact page. We are always glad to help.

The bottom line #

Yes, there is a new PHP bug, and yes, it has no patch yet. No, this is not PHP2Shell all over again. It needs a rare setup, nobody has reported an attack, and one setting shuts it out. Install the October 21 updates, flip the switch, restart PHP and get on with your day.

Two plumbing visits in one week is a lot. At least this time the plumber only had to turn a valve.

Sharon
Jag Journey, LLC