Vulnerabilidad crítica en PHP (CVE-2026-109618 y CVE-2026-109619): cómo funciona el fallo corregido hoy en PHP 8.4.27 / 8.2.35, el parche para mysqlnd y cómo proteger tu servidor

Las vulnerabilidades CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) y CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) afectan directamente al corazón de ejecución de PHP (Core / Zend Engine) bajo el vector técnico denominado State Corruption via Bailout.

¿Cómo ocurre la explotación en servidores web con PHP-FPM, Apache o Nginx?

Cuando un script PHP sufre una condición crítica irrecuperable —por ejemplo, cuando una petición maliciosa fuerza a agotar el límite de memoria (Allowed memory size exhausted), supera el max_execution_time o provoca un error fatal durante una operación interna del recolector de basura (GC), serialización o evaluación de tablas hash—, el motor Zend ejecuta internamente un salto no local (longjmp) mediante la función C zend_bailout() para abortar la petición actual.

En las versiones anteriores a PHP 8.4.27 y 8.2.35, si ese zend_bailout() se disparaba en puntos específicos donde el motor mantenía estructuras internas a medio modificar, el proceso hijo de PHP-FPM no restauraba limpiamente sus punteros globales antes de atender la siguiente petición HTTP:

• Contaminación y corrupción entre peticiones en el mismo worker PHP-FPM: El siguiente visitante legítimo que era atendido por ese mismo proceso worker recibía un estado interno del motor Zend inconsistente, pudiendo desencadenar lecturas de memoria liberada (Use-After-Free), fallos de aserción o filtración de fragmentos de memoria de la petición previa.
• Caída masiva de procesos (DoS / SIGSEGV): Un atacante remoto podía enviar una ráfaga de peticiones diseñadas para forzar bailouts en cadena, derribando los workers de PHP-FPM con errores 502 Bad Gateway o 503 Service Unavailable.

Además de los dos CVEs principales del núcleo, el parche de hoy soluciona vulnerabilidades de alta severidad detectadas por OSS-Fuzz e investigadores de seguridad en extensiones críticas que usa el 99% de los sitios web:

Blindaje obligatorio en php.ini: desactivar session.upload_progress.enabled

Muchos administradores actualizan el binario de PHP pero dejan activada la configuración por defecto session.upload_progress.enabled = On. Cuando esta opción está encendida, un atacante puede enviar una petición POST multipart/form-data con el campo PHP_SESSION_UPLOAD_PROGRESS y obligar a PHP a escribir un archivo de sesión en /tmp/sess_* con contenido controlado por el atacante incluso en páginas que ni siquiera llaman a session_start().

; Bloquea la creación no autenticada de sesiones y Heap Spraying vía multipart POST:
session.upload_progress.enabled = Off
session.use_strict_mode = 1
session.cookie_httponly = 1

Si administrás tus propios servidores Linux y hoy compilaste PHP 8.4.27 desde el código fuente oficial (php-8.4.27.tar.xz), es muy probable que al levantar PHP-FPM contra motores MySQL con protocolo clásico te hayas encontrado con que las conexiones fallan arrojando:

Warning: mysqli_real_connect(): Premature end of data (mysqlnd_wireprotocol.c:1018)
Warning: mysqli_real_connect(): EOF packet 1 bytes shorter than expected

¿Por qué ocurre este bug en el código fuente oficial de PHP 8.4.27 y cómo lo parcheamos en MESI?

En PHP 8.4.27, el equipo upstream agregó la macro BAIL_IF_NOT_ENOUGH_DATA(1) en la función php_mysqlnd_eof_read() dentro de ext/mysqlnd/mysqlnd_wireprotocol.c (línea 1018) inmediatamente después de avanzar el puntero p++ al leer packet->field_count. Eso exige que siempre quede al menos 1 byte extra en el buffer antes de evaluar if (packet->header.size > 1), rompiendo los paquetes EOF legítimos de 1 solo byte.

Compartimos con la comunidad técnica el parche exacto en C que nuestro equipo de ingeniería aplicó hoy en los paquetes de producción de MESI:

--- a/ext/mysqlnd/mysqlnd_wireprotocol.c
+++ b/ext/mysqlnd/mysqlnd_wireprotocol.c
@@ -1015,8 +1015,8 @@ php_mysqlnd_eof_read(zend_uchar * buf, size_t buf_len, ...
     packet->field_count = uint1korr(p);
     p++;
-    BAIL_IF_NOT_ENOUGH_DATA(1);
 
     if (ERROR_MARKER == packet->field_count) {
+        BAIL_IF_NOT_ENOUGH_DATA(1);
         DBG_ERR("Error packet appeared as EOF packet");

Actualizar tu sitio a PHP 8.4.27 en MESI no solo te protege contra CVE-2026-109618 y CVE-2026-109619: también reduce hasta un 55% el tiempo de respuesta (TTFB) en WordPress y duplica las peticiones por segundo en WooCommerce gracias a Zend OPcache v8.4.27 y nuestros discos SSD NVMe.

Si tu web todavía está en PHP 7.4 y al probar PHP 8.4 en tu panel panel.com.ar algún plugin o script propio muestra un error, así se corrigen en segundos los 3 casos más habituales:

<?php
// 1. Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array
// ❌ Antes en PHP 7.4:
if (count($items) > 0) { ... }
// ✅ En PHP 8.4:
if (is_array($items) && count($items) > 0) { ... }

// 2. Deprecated: Creation of dynamic property MiClase::$prop is deprecated
// ✅ Agregá el atributo nativo encima de la clase o declará "public $prop;":
#[\AllowDynamicProperties]
class MiClaseLegacy { ... }

// 3. Deprecated: Function utf8_encode() / utf8_decode() is deprecated
// ✅ Reemplazalo por mb_convert_encoding():
$iso = mb_convert_encoding($utf8, 'ISO-8859-1', 'UTF-8');

Y si tenés un sistema histórico con funciones antiguas mysql_connect(), en MESI contás tanto con el Selector Multi-PHP (7.4 / 8.2.35 / 8.4.27) en 1 clic como con nuestro Puente de Compatibilidad Legacy a PHP 8.4 para que tu aplicación corra sobre el motor parcheado sin romperse.

Copiá este prompt diseñado por nuestro equipo de seguridad, pegalo en tu IA junto con tus archivos PHP y obtené el código blindado y compatible con PHP 8.4.27: