PHP CVE-2026-115560

Exploitation requires a highly specific, non-default application setup: the application must set session.serialize_handler to php_binary or php_serialize in its configuration, then switch it to php at runtime via ini_set() before calling session_start(), while session.upload_progress.enabled remains on. Applications that never change the serialize handler at runtime are not affected even with upload progress enabled. These stacked, uncommon preconditions - explicitly called an 'unusual combination of configuration and application code' by the vendor - are the primary factors limiting real-world exploitation; the mitigation session.upload_progress.enabled=0 fully neutralizes the vector. The precise trigger mechanism of the RCE is not described in the available sources.

Real-world risk is low despite the vulnerability being an RCE vector, and the available signals are sparse but internally consistent. No CVSS vector, CWE, EPSS score, KEV listing, or PoC is present in the input, and the vuln.today decision label is 'awaiting_data' - so there is no exploitation-probability or active-exploitation signal to weigh. The strongest signal is the vendor's own characterization: PHP explicitly calls this an 'unlikely RCE vector' triggerable only under 'an unusual combination of configuration and application code,' and states it is being handled in the regular bugfix release cycle rather than as an emergency. That vendor judgment, combined with the absence of any exploitation signal, points to a genuinely low-priority issue rather than a high-CVSS-but-overhyped one. Note the data gaps explicitly: exploitation status is unconfirmed (no public exploit identified), no scored severity exists to compare against the description, and the exact trigger mechanism of the RCE is not described in the available sources - the advisory is informational and a full advisory is promised with the next release. Related mitigation context exists via CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), whose session.upload_progress.enabled=0 mitigation also covers this issue.

An attacker targets a PHP application that has configured session.serialize_handler to php_binary or php_serialize and then switches it to php at runtime via ini_set() before session_start(), with session upload progress still enabled. The attacker sends a crafted multipart file upload that drives session upload-progress data through the mismatched serialize handler, potentially reaching a remote code execution condition. No public exploit has been identified at time of analysis, and the vendor rates the vector as unlikely to occur in practice.