PHP’s New RCE Risk Hinges on a Rare Session Configuration

PHP CVE-2026-115560: exposure depends on session configuration

PHP’s latest remote-code-execution warning isn’t a reason to assume every PHP site is vulnerable. The reported path depends on an unusual sequence of session configuration changes, and the project describes the risk as unlikely. That distinction matters: administrators should check the relevant settings and application behavior, not mistake a broad PHP warning for proof of exposure.

The issue is tracked as CVE-2026-115560. PHP has recommended a temporary mitigation while the fix is handled through a regular release rather than an emergency patch. The advisory information reported by BleepingComputer and The Hacker News points to a specific interaction between session upload progress and the session serialization handler.

Which PHP configuration creates the risk?

The reported conditions are conjunctive: the application must use a particular sequence, not merely have one session option set. It configures session.serialize_handler as php_binary or php_serialize, changes that setting at runtime to php using ini_set(), and makes the change before calling session_start(). Session upload progress must also remain enabled.

That combination is the key to triage. A server where the handler is never changed at runtime does not match the described path simply because upload progress is enabled. Likewise, finding a handler setting in a configuration file is not by itself enough to establish that the application performs the sequence PHP describes. The application’s runtime behavior matters.

PHP’s characterization of the setup as unlikely is useful context, not a substitute for checking. Larger deployments can have multiple applications, pools, and configuration layers; a setting in a global file may not tell the whole story. Review the configuration each application actually receives and search application code for calls to ini_set() that alter session.serialize_handler before session startup.

The public reporting does not supply a complete affected-version matrix or a severity score for this issue. Don’t fill those gaps with assumptions. Track the PHP project’s subsequent release information and assess your deployed runtime and application configuration directly.

Apply the temporary mitigation

PHP recommends disabling session upload progress by setting:

session.upload_progress.enabled=0

Keep that setting in force until the relevant routine bugfix release is available and you have assessed the upgrade. The same setting had already been recommended in connection with the earlier PHP2Shell advisory. According to reporting by The Hacker News, administrators who applied it then and have left it enabled as a mitigation do not need to take a second, different action for CVE-2026-115560.

The setting controls session upload progress, a feature used to track the progress of file uploads. Disabling it is a targeted workaround for the described path; consider whether your applications rely on that behavior, and validate the operational effect in your environment. Do not silently remove the mitigation merely because an application appears unaffected without checking the complete condition set.

A practical response is straightforward:

1. Confirm the effective value of session.upload_progress.enabled for each relevant PHP runtime and application.
2. If it is enabled, apply the recommended disabled setting while the issue remains unpatched.
3. Inspect application code and configuration for the specified runtime change from php_binary or php_serialize to php before session_start().
4. Check that the mitigation persists across the configuration layers and runtime pools that serve the application.
5. Monitor PHP release and advisory information, then plan a tested update when the fix becomes available.

These are administrator checks, not a claim that every installation is exposed. The goal is to close the temporary risk while avoiding an unnecessary conclusion based on one isolated setting.

This is separate from PHP2Shell

CVE-2026-115560 is not one of the PHP2Shell vulnerabilities patched on October 21. The earlier issues are CVE-2026-109618 and CVE-2026-109619; PHP shipped fixes in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, according to contemporaneous reporting. Those emergency updates do not, by themselves, resolve the newly reported session-configuration issue.

The distinction cuts both ways. Applying the upload-progress mitigation for the earlier advisory can also mitigate the configuration path now described, but updating for PHP2Shell and disabling upload progress are not interchangeable actions. Administrators should track both the runtime patch status for the earlier flaws and the temporary setting for this newer issue.

Reports of exploitation activity discussed in coverage concern the earlier PHP2Shell flaws, not CVE-2026-115560. The Hacker News reports no exploitation of the new issue and notes that PHP has not said whether it shares a root cause with CVE-2026-109619. Keep incident tracking precise: activity against one vulnerability is not evidence that another is being exploited.

What administrators should verify next

Start with the application, not just the server’s default configuration. Establish which PHP runtime and configuration apply to each site or service, and determine whether application code changes the serialization handler at runtime before session startup. Then confirm whether upload progress is enabled and apply the temporary disablement where appropriate.

If the exact sequence is absent, the reported exposure condition is not met as described. Still, follow the project’s updates: the current guidance is a temporary mitigation, and fuller details are expected with a regular release. If the sequence is present, do not wait for a public exploit report before acting; apply the one-line mitigation and plan a controlled upgrade when PHP publishes the fix.

The useful takeaway is narrow but important. This is a configuration-dependent RCE warning, not a blanket statement that all PHP applications are vulnerable. Verify the sequence, disable session upload progress as recommended, and keep CVE-2026-115560 distinct from the already-patched PHP2Shell flaws.