---
title: "Patched PHP2Shell? PHP warns of a new flaw, closed with one line"
description: "Two days after the PHP2Shell patches, PHP published an informational advisory for CVE-2026-115560: a new RCE path the Oct 21 releases don't fix. Few are affected, and one config line closes it."
url: https://ihsanalapsi.dev/articles/php-cve-2026-115560-session-rce
lang: en
date: 2026-10-24
updated: 2026-10-24
tags: ["Security updates", "App security"]
author: Ihsan Alapsi (إحسان العبسي)
---
# Patched PHP2Shell? PHP warns of a new flaw, closed with one line

On Oct 21 we patched PHP for two serious flaws and everyone relaxed. Two days later, on Oct 23, 2026, PHP published an [informational advisory](https://www.php.net/archive/2026.php#2026-10-23-1) about a new remote code execution (RCE) path with a new CVE number, and the Oct 21 releases don't close it. PHP itself says the likelihood is low, and the fix is one line in your config.

## What is CVE-2026-115560?

CVE-2026-115560 is a remote code execution flaw in PHP, but it isn't one of the two PHP2Shell flaws, and the Oct 21 releases don't fix it.

The two PHP2Shell flaws are CVE-2026-109618 and CVE-2026-109619, fixed by the Oct 21 releases: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. This new one is a different path with no emergency patch: PHP will ship the fix with the next regular release and publish the full details then. So even if you updated on the 21st, this path stays open until the next release.

## When are you actually affected?

PHP lists three conditions, and all three must hold at once:

1. Your config sets `session.serialize_handler` to `php_binary` or `php_serialize`.
2. Your app switches it to `php` at runtime via `ini_set()`, before calling `session_start()`.
3. Session upload progress is still enabled.

If your app never switches the serialize handler at runtime, you can leave the feature on and this path can't touch you. That's why PHP calls the required setup "unlikely in practice".

## How to check if your config is affected

Two commands settle it: the first shows the current handler value, and the second searches your code for any `ini_set()` that switches it.

```bash
# What's the current handler value?
php -i | grep session.serialize_handler

# Does any code switch it at runtime?
grep -rn "ini_set.*serialize_handler" --include='*.php' .
```

If the first shows `php` (the default) and the second finds nothing, you're outside this flaw's blast radius.

## What should you do? One line

If the conditions apply to you, or you'd rather not bother checking, set:

```
session.upload_progress.enabled=0
```

It goes in `php.ini`, an FPM pool or the server config, per [PHP's Oct 21 advisory](https://www.php.net/archive/2026.php#2026-10-21-5): anywhere that applies before request parsing starts. Don't rely on `ini_set()` or `.user.ini`; they apply too late to block the path. Then restart all PHP workers so the change takes effect.

If you already disabled this feature after the Oct 21 advisory, keep it off and you need nothing more. The same line was among the steps PHP recommended back then for CVE-2026-109619.

## Why no emergency patch?

PHP didn't ship an emergency patch because the required setup is rare in practice, so the fix comes with the regular release cycle. Its advisory mentions no exploitation.

That's a different situation from [the two PHP2Shell flaws](/articles/php2shell-php-rce): every PHP install serving web requests was exposed, and PHP shipped an emergency update for them on Oct 21.

## Are the updates still required?

Yes. This one line doesn't replace the Oct 21 updates. The two PHP2Shell flaws were rated 9.2 out of 10 on CVSS v4.0, allow unauthenticated code execution, and updating is the only complete fix. If you haven't updated yet, update before anything else.

PHP isn't alone this week: [GitLab had to patch twice](/articles/gitlab-cvss-10-unauthenticated-rce) in under two weeks, each time for a 10/10 flaw.

And [the October Node.js security releases](/articles/nodejs-october-2026-security-releases) closed 10 flaws. If you're checking your session settings today, check these tools' versions on your servers too.

When did you last review your server settings line by line?

## FAQ

**I updated PHP on Oct 21, do I still need to do anything?**

Only if your app switches session.serialize_handler at runtime and session upload progress is still on: then turn it off with session.upload_progress.enabled=0. If you turned it off on Oct 21, keep it off and nothing more is needed.

**Does this affect WordPress sites?**

Only if the site or a plugin switches session.serialize_handler at runtime, which is rare. The Oct 21 updates are needed by everyone either way.

**Is there active exploitation of this flaw?**

No reports as of Oct 24, and PHP's advisory mentions no exploitation. PHP is handling it in the regular release cycle because the required setup is unlikely in practice.

**Where exactly do I put the disable setting?**

In php.ini, an FPM pool or the server config, somewhere that applies before request parsing. Then restart all PHP workers. Don't rely on ini_set() or .user.ini; they apply too late.