CVE-2026-115560: Fix PHP Sessions Without Missing the Patch

PHP has described CVE-2026-115560, an unlikely remote code execution path involving session upload progress, with a configuration mitigation: session.upload_progress.enabled=0. The supplied advisory coverage says the fix will arrive in the next regular bugfix release, with no date announced. I would disable that feature where it is unnecessary, but I would not confuse this setting with completing the separate PHP2Shell updates.

My starting point is the Trickyworld report supplied for this post: https://www.trickyworld.in/computer-tricks/cyber-security/cve-2026-115560-php-session-bug-one-line-fix/. It describes a narrow combination of application behaviour and configuration, not a reason to assume every PHP application is exploitable.

For me, the useful distinction is between changing a configuration file and proving that the application-serving workers use it. I would treat those as separate deployment tasks.

How I would check exposure to CVE-2026-115560

The report says all three conditions must exist in the same application. I would check them together rather than treating any single setting as proof of exposure:

• The configured session.serialize_handler is php_binary or php_serialize, rather than the default php.
• Application code changes the handler back to php at runtime before starting the session.
• Session upload progress remains enabled, which is its default.

I would start with the runtime switch because it is the most specific condition. The source recommends searching for the setting name, not just an exact ini_set() expression. That also gives me a chance to find settings passed through variables or session-start options.

grep -rn --include='*.php' 'serialize_handler' /var/www/your-app

I would keep dependencies inside that search. The report points to an older PHP bug report involving framework code that changed the handler; looking only at code my team wrote would be too narrow.

I would also distinguish a search result from a confirmed execution path. A match needs inspection: what value is being set, when does it happen, and does that code run before session_start()? Equally, I would not treat a clean search of an incomplete checkout as a clean application audit.

According to the supplied coverage, PHP says applications that never change the serializer at runtime can keep upload progress enabled. If I can establish that condition is absent, I would stop treating this particular path as the urgent issue and put the separate PHP2Shell patch work first.

Why the serializer switch matters

I find the issue easier to reason about as a mismatch between writing and reading session data. The report explains that upload progress writes session information before application scripts execute. That information includes client-supplied values, such as the progress field value, file name, and form field name.

The initial write uses the configured serializer. If application code then switches to another serializer before reading the session, the same stored bytes are interpreted using a different format. The source explains that the php format uses a pipe character to separate a session key from its serialized value.

That mismatch can let attacker-shaped data influence what gets unserialized. The report describes this as PHP object injection, with code execution additionally dependent on loaded classes whose magic methods can be chained into harmful behaviour. I would not flatten that chain into “uploads automatically execute code.” The application-specific conditions matter.

I would also keep the explanation provisional. PHP has not published the full technical details, and the source says it has not established whether this CVE is the older reported behaviour or a new route to a similar outcome.

Disabling PHP session upload progress in production

I would make this a short, verifiable change rather than an application-code workaround. The source says session.upload_progress.enabled cannot be changed with ini_set(); that call returns false and does not apply the mitigation.

Check the runtime that serves requests

I would first inspect configuration through the website's PHP runtime. The report warns that CLI configuration can differ from PHP-FPM or Apache configuration, specifically noting separate configuration files on Debian and Ubuntu. A reassuring php -i result is therefore not the evidence I would use to close the task.

I would use a temporary diagnostic script through a controlled access path, record the values, and delete it immediately afterwards. The source warns that leaving it available discloses the PHP version.

<?php
header('Content-Type: text/plain');
echo 'PHP ', PHP_VERSION, ' (', PHP_SAPI, ")\n";
echo 'session.serialize_handler = ', ini_get('session.serialize_handler'), "\n";
echo 'session.upload_progress.enabled = ', ini_get('session.upload_progress.enabled'), "\n";

A configured handler of php means the first stated condition is absent. A progress setting of 1 means the feature is enabled. I would read those results alongside the code inspection, not as a replacement for it.

Apply the setting administratively

For PHP-FPM, my preference would be the pool-level setting recommended in the source:

php_admin_flag[session.upload_progress.enabled] = off

For Apache with mod_php, I would use the virtual-host form:

php_admin_flag session.upload_progress.enabled off

For the official PHP Docker image, the source recommends a configuration file under /usr/local/etc/php/conf.d/, followed by rebuilding and redeploying the image. In that file, or the appropriate serving runtime's main configuration, the setting is:

session.upload_progress.enabled = 0

I would avoid relying on an FPM .user.ini for this mitigation. The report quotes PHP's warning against it and describes a case where the file was silently skipped because the web server did not pass the document root. My preference is an administrative setting whose deployment I can explicitly verify.

Restart, verify, and test the upload interface

I would restart PHP-FPM or Apache as appropriate, or redeploy the rebuilt container, then check through the serving runtime again. The expected result is session.upload_progress.enabled = 0. The source makes the important point that editing configuration without restarting leaves running workers using the old value.

I would then test both the upload and its progress display. On a newsroom CMS, this is exactly the distinction I would check: did the file arrive, and did the editor receive accurate feedback? I would not accept a successful upload alone as proof that the editorial interaction still behaves correctly.

Finally, I would plan to remove runtime serializer switching rather than leave the application dependent on this mitigation. My preferred end state is one configured session format, with no code changing how existing session data is interpreted.

Does this setting also fix PHP2Shell?

No. I would keep these remediation tasks separate even though the upload-progress setting appears in both advisories. The source says disabling it covers this new CVE, but PHP's release announcements describe updating as the only safe choice for the two PHP2Shell flaws.

The supplied report lists PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35 as PHP2Shell-fixed releases, with distribution-patched packages as another route. It also states that PHP 8.1 and older no longer receive updates from the PHP project.

I would therefore track two separate acceptance criteria: the serving workers run the appropriate PHP2Shell-patched build, and session upload progress is disabled where I am applying this mitigation. Neither checkbox implies the other.

I would not describe those listed releases as fixing this new session issue. The source explicitly places its fix in a forthcoming regular bugfix release. That distinction belongs in the deployment ticket, not just in a security discussion someone might miss.

What disabling PHP session upload progress does not solve

The immediate trade-off is the upload interface. According to the source, disabling this feature does not disable file uploads. It removes the server-side progress information used by interfaces that poll for upload status. Progress bars based on the browser's XMLHttpRequest upload events are unaffected.

If an application depends on PHP's session-based progress reporting, I would give that dependency an explicit owner before changing it. I would still favour the mitigation for an exposed application, but I would test the affected interface and decide how to communicate the missing progress feedback.

If an application never switches serializers at runtime, I would deprioritize this specific CVE investigation once that is verified. I would not ask that team to redesign its upload interface solely because this advisory exists. Its PHP2Shell patch status remains a separate question.

I would also resist assigning an unofficial severity score or affected-version range. The supplied report says PHP has not yet published those details, the exact fix releases, or whether this issue shares a root cause with CVE-2026-109619. It reports no known exploitation of this CVE as of October 23, 2026; I would treat that as a dated observation, not a safety guarantee.

My next step would be concrete: inspect serializer changes, apply the administrative setting where appropriate, and verify the running workers. Unless an upload interface genuinely needs this feature, I would leave it disabled after the eventual patch too. I would rather document a real dependency than keep an unused feature enabled by habit.