Россия
RU
Казахстан
RU KZ
Беларусь
RU
Грузия
RU EN
Турция
RU EN
Критическая RCE в PHP (CVE-2026-109619) и легаси: как защитить PHP 5.6 и написать C-патч для ядра

Critical RCE in PHP (CVE-2026-109619) and Legacy Systems: How to Protect PHP 5.6 and Write a C-Patch for the Core

On October 21, 2026, two critical vulnerabilities with maximum severity rating CVSS 9.2 were disclosed in the PHP ecosystem: CVE-2026-109618 and CVE-2026-109619. Both are associated with Zend Engine core memory management corruption and lead to Remote Code Execution (RCE).

1. What is the real-world problem?

Official cybersecurity advice is simple: "Urgent: upgrade to current PHP 8.2+ or PHP 8.3+ releases with official patches".

However, for countless enterprise B2B portals, e-commerce platforms, and legacy production systems, migrating off PHP 5.6 overnight is impossible. Official support for the PHP 5.6 branch ended in late 2018 (EOL), and official patches are no longer released. Below is practical audit experience, root cause localization, and the creation of our own backport patch.

2. Anatomy of the Vulnerability in C Code

The attack vector of CVE-2026-109619 stems from a memory free bug in the session.upload_progress mechanism (file ext/session/session.c):

  1. When submitting a multipart/form-data form containing the PHP_SESSION_UPLOAD_PROGRESS field, the core allocates a tracking structure in RAM and stores its address in the global variable PS(rfc1867_progress).
  2. If memory exhaustion occurs during file transfer (OOM, exceeding memory_limit) or connection drops, the engine performs an emergency bailout zend_bailout(), bypassing standard request termination.
  3. Memory for the current request is freed, but the system pointer in the long-lived worker (Apache / PHP-FPM) continues to point to the freed address, forming a dangling pointer.
  4. The subsequent request reaching the same worker accesses foreign memory — triggering a Use-After-Free, enabling an attacker to execute arbitrary shellcode on the server.

3. Protection Strategy: Three Security Layers

Layer 1: Complete Migration to PHP 8 (Recommended)

The only exhaustive solution for both vulnerabilities (including core OOM crashes CVE-2026-109618) is systematically upgrading the project to supported PHP 8.2 or 8.3 branches.

Layer 2: C Backport Patch for PHP 5.6

For production environments where an upgrade is not feasible, we developed and verified a C patch for the PHP 5.6 source tree. The patch forcefully resets the pointer PS(rfc1867_progress) = NULL; at the beginning of each new request (RINIT) and safely deallocates structures during failures (RSHUTDOWN). The worker cannot inherit freed memory addresses.

Layer 3: Workaround Without Recompilation (.htaccess / Nginx)

If you do not have root privileges on the server, disable the vulnerable mechanism via web server configuration:

# Disable vulnerable mechanism
<IfModule mod_php5.c>
    php_flag session.upload_progress.enabled off
</IfModule>

# WAF: block attack markers
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{THE_REQUEST} (PHP_SESSION_UPLOAD_PROGRESS|upload_progress) [NC,OR]
    RewriteCond %{QUERY_STRING} (PHP_SESSION_UPLOAD_PROGRESS|upload_progress) [NC]
    RewriteRule .* - [F,L]
</IfModule>
Important: Disabling session.upload_progress blocks the CVE-2026-109619 vector, but does NOT resolve the core OOM bug (CVE-2026-109618). Standard file uploads via $_FILES continue to function normally.

4. Open Source and Community Binaries

All materials — C patch, prebuilt .deb packages, Dockerfile for reproducible builds, and technical documentation — are published under open license in the GitHub repository:

GitHub Repository: checkfoxe/php56-session-uaf-patch →

Author: Viktor Zarbashev (@checkfoxe)

Содержание