home › Forums › Device, App & Web Security › Other Web, App Security › PHP warns of unpatched RCE flaw two days after PHP2Shell

Viewing 1 post (of 1 total)
  • Posts
  • PHP has issued an informational advisory on October 23 for a third vulnerability, CVE-2026-115560, affecting web applications with unusual session configurations. The project does not consider it an emergency risk and will include the fix in the next routine release.

    This follows the October 21 emergency patch for two critical flaws known as PHP2Shell. Those vulnerabilities, CVE-2026-109618 and CVE-2026-109619, each carry a CVSS v4.0 score of 9.2. They allow an attacker without an account to run code on a server. The fixes are available in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

    The new warning stands separate. The October 21 patch does not resolve CVE-2026-115560. However, the same one-line mitigation recommended on October 21 also covers this third issue. Anyone who disabled session upload progress after the earlier advisory needs to do nothing more for now.

    What makes CVE-2026-115560 different

    PHP describes the setup as uncommon. A web application faces risk only when all of the following occur. First, it sets the session.serialize_handler option to php_binary or php_serialize in its configuration. Second, it changes that option to php at runtime by calling ini_set(). Third, it makes that change before calling session_start(). Fourth, the session.upload_progress feature must remain enabled.

    PHP says this combination is unlikely in practice. Applications that never change the serialize handler while running are not exposed through this path, even with session upload progress turned on.

    The temporary fix is to set session.upload_progress.enabled=0 until the next bugfix release publishes the permanent patch. Session upload progress is enabled by default. It tracks file upload progress so a page can show a progress bar during multipart/form-data uploads. Disabling it does not affect normal file uploads.

    Attack scale since disclosure

    Cloudflare reported exploitation attempts rose from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22. Amazon Threat Intelligence identified an attempt on October 17, four days before public disclosure, originating from an IP linked to a commercial anonymisation network. Multiple proof-of-concept exploits appeared online on October 21, with various payloads and anonymisation infrastructure suggesting multiple actors.

    Sophos initially claimed successful exploitation in customer environments but later corrected this assessment. Sophos telemetry shows scanning and a small number of failed attempts. No confirmed compromise has been reported. Payloads observed include a Mirai botnet variant named Potassium, which did not deliver due to countermeasures. Researchers say building a reliable exploit is proving harder than expected.

    Agensi Keselamatan Siber Negara (NACSA) issued an advisory on October 22 urging Malaysian organisations to immediately patch internet-facing PHP systems. The agency highlighted the same two flaws patched on October 21. The new CVE adds another reason to complete updates and apply the session upload progress setting.

    Table 1: CVE status and patched versions

    | CVE ID | Disclosure | Severity | Patched versions | Status |
    |——–|————|———-|——————|——–|
    | CVE-2026-109618 | 21 Oct 2026 | 9.2 (Critical) | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Patched |
    | CVE-2026-109619 | 21 Oct 2026 | 9.2 (Critical) | PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Patched |
    | CVE-2026-115560 | 23 Oct 2026 | Not yet scored | Next routine release | Unpatched, mitigatable |

    What administrators should do

    Update PHP to one of the patched versions if running any version before those listed. Check hosting provider or operating system vendor for updated packages. Apply the session.upload_progress.enabled=0 setting in php.ini, a file in /etc/php.d/, or a PHP-FPM pool configuration. Do not rely on ini_set() or per-request settings to enforce this. Restart every worker after applying the change.

    Systems running PHP 8.1 or earlier do not receive patches from the PHP project. These versions have reached end of life. Upgrade to a supported branch or obtain verified security patches from vendors.

    Website owners should contact their hosting provider to confirm the PHP version in use and whether updates are pending. Managed hosting often controls the PHP version, not the site owner. For self-managed servers, review the patch notes on php.net and schedule maintenance windows accordingly. The session upload progress setting imposes no cost and causes no functional loss for sites not using upload progress bars.

    0
Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.