No Patch Available: Finding and Fixing the PHP RCE (CVE-2026-115560) Across Every Server You Manage

CVE-2026-115560 is the kind of vulnerability that breaks patch management's core promise. There is no patch — and there may not be one for weeks. The vendor's guidance is to disable session.upload_progress.enabled in every php.ini you own. That is a configuration change, and configuration changes are invisible to every patch compliance report you run.

So right now, somewhere in your environment, there is probably a Windows Server running PHP under IIS FastCGI that your compliance dashboard marked "100% patched" this morning. That dashboard is not lying about KBs. It is lying about risk.

Why This CVE Is a Patch Team's Worst Case

Here is what PHP actually disclosed: CVE-2026-115560 is a remote code execution flaw that remains unpatched. Exploitation requires a specific combination — an attacker needs particular session-handler changes in play while session upload progress is enabled — but "requires specific configuration" is not the reassurance it sounds like. Attackers scan for exactly these misconfigurations at scale, and a temporary mitigation is not a fix.

That creates a question no WSUS report, no MECM compliance baseline, and no third-party patch catalog was designed to answer: which of my servers run PHP, which have upload progress enabled, and how do I verify all of them until the real fix ships?

If answering that today involves RDP hopping, a shared spreadsheet, and asking in Slack whether anyone remembers where that WordPress box lives, keep reading.

The Problem in Depth

Your patch tool tracks updates, not exposure

WSUS, MECM, and the patch modules in RMM platforms like NinjaOne, ConnectWise, and N-able all work the same way at their core: they map KB articles and installer versions to machines. When a vendor publishes "no fix available, change this setting," that pipeline produces nothing. No missing update appears. No compliance percentage drops. Your dashboard says 100% because, as far as the tool can see, nothing is missing.

Meanwhile, the risk is entirely real. The gap is not in your data — it is in the architecture. Patch state, configuration state, and software inventory live in different systems, sometimes in different teams. The patch tool does not read php.ini. The monitoring tool does not care about file contents. The helpdesk has no idea either of them exist.

You cannot mitigate what you cannot find

Ask yourself honestly: how many PHP instances are running in the environments you manage, and where is each php.ini?

In a typical internal IT shop, the honest answer includes the production web server you know about, a dev XAMPP install on someone's workstation, a legacy intranet app on a 2012 R2 box nobody will decommission, and a WordPress or Zabbix instance a former admin set up. For an MSP, multiply that by every client — and good luck getting an accurate answer for the "small monthly maintenance" client whose web server nobody has logged into since onboarding.

The manual workflow eats your week — and still misses things

The standard response to this advisory in a fragmented stack looks like this: export a server list from one tool, check each server's config by hand, record the results in a spreadsheet, push the fix through a mix of manual edits and Group Policy, then repeat the entire audit next week to catch drift and newly provisioned servers. At ten minutes per server across 60 servers, that is a full workday — repeated. And the single XAMPP box on a marketing laptop that was never in the inventory is the one that ends up on a threat feed.

What it costs the business

• Time to exposure reduction is measured in days or weeks instead of hours, because verification is manual.
• The audit trail is a chat log. When the auditor, cyber insurer, or security team asks you to show how you handled CVE-2026-115560 across the fleet, a spreadsheet full of checkboxes does not survive contact with an evidence request.
• Drift silently reopens the hole. A developer re-enables upload progress for a debugging session and forgets to turn it off. Nothing alerts. Nothing records it.
• When the real patch ships, you do it all again — and if you roll it out without staging and monitoring context, you trade a security risk for an availability incident and a morning of angry tickets.

How AlertMonitor Solves This

AlertMonitor collapses this into one workflow because inventory, script execution, patching, monitoring, and helpdesk all run on the same data.

1. Find every PHP instance from software and service inventory. The RMM agent on every managed device reports installed software, running services, and processes. Query for php-cgi.exe, PHP in the installed software list, or IIS worker processes serving PHP handlers, and you get a device group containing every machine that needs attention — including the ones your spreadsheet forgot.

2. Run the audit script everywhere at once. Push a PowerShell check to that device group through AlertMonitor's script engine. Every machine returns COMPLIANT or NOT COMPLIANT with the offending value. What took a workday of RDP sessions becomes a single deployment you review in minutes.

3. Turn the mitigation into a monitored check. Instead of a one-time audit, schedule the same script as a recurring check. If upload progress gets re-enabled, if a new PHP install appears, or if an upgrade replaces the php.ini, the check fails, fires an alert with full device context, and opens a helpdesk ticket automatically. Drift stops being invisible.

4. Track it through to a real patch. When PHP ships the actual fix, AlertMonitor's patch module picks it up. You deploy it staged by device group or department, with rollback if the web application misbehaves — and the same script check verifies the post-patch state, so you retire the mitigation deliberately instead of guessing.

5. Reboots and restarts arrive with context. Restarting IIS application pools or applying the eventual patch should not produce mystery outages. Because patch state and monitoring share one timeline, a 2am restart after an update is an alert that says "expected — patch deployment on server X," not a phone call from a user at 8am.

Old way: five tools, one spreadsheet, three hours per environment, unknown blind spots. AlertMonitor: one script deployment, one dashboard, one audit trail, and drift detection that never sleeps.

Practical Steps You Can Take Today

Step 1: Build your PHP inventory

Run this locally on a known web server, or push it as an AlertMonitor RMM script across all servers to flag which machines have PHP present:

# Detect PHP and locate php.ini on a Windows machine
$phpExe = Get-Command php.exe -ErrorAction SilentlyContinue
if ($phpExe) {
    Write-Output "PHP found at: $($phpExe.Source)"
    & $phpExe.Source --ini
} else {
    # Check common install locations
    $iniFiles = Get-ChildItem -Path "C:\php*\php.ini","C:\Program Files\PHP*\php.ini","C:\xampp\php\php.ini" -ErrorAction SilentlyContinue
    if ($iniFiles) { $iniFiles.FullName } else { Write-Output "No PHP detected" }
}

If the server runs IIS, also check for a PHP FastCGI handler — that is how most Windows PHP deployments are wired:

# List IIS handlers pointing at PHP
Import-Module WebAdministration
Get-WebHandler | Where-Object { $_.ScriptProcessor -like "*php*" } |
    Select-Object Name, ScriptProcessor

Step 2: Check whether upload progress is enabled

# Audit session.upload_progress.enabled in php.ini
$iniPath = "C:\php\php.ini"
$match = Select-String -Path $iniPath -Pattern '^\s*session\.upload_progress\.enabled\s*=\s*(\d)'
if (-not $match) {
    "NOT COMPLIANT: setting not found in $iniPath (PHP default is enabled)"
}
elseif ($match.Matches[0].Groups[1].Value -eq "0") {
    "COMPLIANT"
}
else {
    "NOT COMPLIANT: upload progress enabled ($($match.Matches[0].Groups[1].Value))"
}

Do not talk yourself out of the mitigation because exploitation "requires specific session-handler changes." The vendor published this guidance for a reason, and you do not want to bet an incident report on your ability to audit every session-handler configuration by hand.

Step 3: Apply the mitigation

On Windows, edit the ini and restart the application pool so PHP picks up the change:

$iniPath = "C:\php\php.ini"
# Overwrite the setting whether it is active or commented out
(Get-Content $iniPath) -replace '^\s*;?\s*session\.upload_progress\.enabled\s*=.*','session.upload_progress.enabled = 0' |
    Set-Content $iniPath -Encoding ASCII

# Restart the application pool so PHP reloads the config
Import-Module WebAdministration
Restart-WebAppPool -Name "YourPhpAppPool"

One warning: PHP can load multiple ini files — the CLI and the web SAPI often use different ones. Always confirm with php --ini which file your web server actually reads. Editing the wrong one is the classic way teams "remediate" a server that stays vulnerable.

On Linux web servers, the same mitigation looks like this:

sed -E -i 's/^\s*;?\s*session.upload_progress.enabled\s*=.*/session.upload_progress.enabled = 0/' /etc/php/8.2/fpm/php.ini
systemctl restart php8.2-fpm
php -i | grep -i session.upload_progress.enabled

Step 4: Make the check permanent, not a one-off

In AlertMonitor:

1. Save the Step 2 audit script as a script-based check.
2. Target your PHP device group and schedule it to run daily.
3. Configure failures to raise an alert and auto-create a helpdesk ticket with the device name, ini path, and offending value.
4. Feed the group automatically from software inventory so a fresh PHP install cannot slip through.

Now the answer to "are we still exposed to CVE-2026-115560?" is a dashboard, not a memory.

Step 5: Be ready for the real patch

When the actual PHP fix ships:

• Deploy it staged — pilot group first, then production web servers — using AlertMonitor's scheduled patch deployment with rollback.
• Keep the script check running through and after the rollout to verify the end state.
• Rely on integrated monitoring so any post-patch restart arrives as a contextual alert, not an unexplained outage.
• Only then decide whether to re-enable upload progress. Most teams will not — the feature is rarely used legitimately, and leaving it off is cheaper than the next advisory.

The Takeaway

Patch management was built for a world where every vulnerability eventually ships as a KB. CVE-2026-115560 is a reminder that the most dangerous window — disclosed, exploitable, unpatched — is handled with configuration, inventory, and verification, not update approvals. The teams that get through it cleanly are the ones where finding servers, pushing scripts, tracking state, and alerting on drift all happen in one system.

Related Resources

AlertMonitor Patch Management & Software Updates AlertMonitor Platform Overview Book a Demo Patch Management & Software Updates Resources