PHP: RCE crítico filtrado antes del parche

Dos RCE críticos en PHP se filtraron antes del parche de emergencia

El equipo de seguridad de PHP adelantó su calendario: dos vulnerabilidades de ejecución remota de código (RCE) se filtraron antes de la divulgación programada y el proyecto publicará actualizaciones de emergencia el miércoles 21 de octubre a las 14:00 UTC, según BleepingComputer. Cada fallo lleva una calificación de 9.2 sobre 10 en CVSS v4.0 asignada por el equipo de PHP, y los investigadores de watchTowr —que confirmaron que los fallos son reales y reprodujeron uno de ellos— sostienen que afectan a PHP 5, 6, 7 y 8.

Para un founder, la traducción es directa: si tu producto corre sobre PHP —WordPress, Laravel, Magento, Symfony o cualquier stack LAMP— tienes una ventana de exposición abierta ahora mismo, y el exploit ya circula antes que el parche.

Qué se sabe y qué no de CVE-2026-109618 y CVE-2026-109619

Los identificadores son CVE-2026-109618 y CVE-2026-109619, según watchTowr, que los compartió con BleepingComputer. El equipo de PHP no divulgó detalles técnicos: ni las versiones exactas afectadas, ni el mecanismo de explotación, ni qué releases traerán el fix. Dijo que publicará todo eso cuando los parches estén disponibles.

Hay una discrepancia que conviene tener presente. Un post ya eliminado en Hacker News —visto por BleepingComputer— afirmaba que ambas vulnerabilidades tenían CVSS 10.0 y que se divulgarían el 22 de octubre. La calificación oficial de PHP es 9.2 y el release está agendado para el 21. watchTowr, por su parte, confirmó que no ha observado explotación en el wild hasta ahora.

Ese último dato es el que más importa para planificar: la filtración es real, el exploit es real, pero todavía no hay evidencia pública de ataques en producción. La ventana existe y se está cerrando.

Cómo funciona la cadena de explotación

Un análisis técnico publicado por el investigador @J4ck3LSyN en jackalsyn.com describe un use-after-free de heap en el manejador session.upload_progress de PHP, en la función php_session_rfc1867_callback de ext/session/session.c. El resumen: el handler cachea dos punteros crudos zval * a buckets de HashTables vivas —post_bytes_processed y current_file_bytes_processed— que apuntan a arrays que el ciclo de vida del request libera. Un segundo update() vuelve a leer el archivo de sesión y zend_hash_update destruye el árbol decodificado anterior mediante zval_ptr_dtor. El bucket liberado se reasigna y el puntero obsoleto termina en una estructura zend_fcall_info / zend_internal_function con forma controlada por el atacante, que desemboca en zend_call_function, es decir, en system().

Lo relevante para quien administra infraestructura: no hace falta una configuración exótica. Con session.upload_progress.enabled=1 y los valores por defecto —nombre, prefijo, freq=1%, min_freq=1— alcanza, según el análisis, con un POST multipart rápido que arme las dos cachés.

El autor afirma haber verificado cada referencia de línea contra php-src 8.4.4 y 8.2.34, incluidos los offsets de estructura (zend_fcall_info de 64 bytes con param_count en +48, zend_internal_function.handler en +88). También publica los símbolos de depuración oficiales de LiteSpeed lsphp82 8.2.34 para tres sub-builds de distro (bookworm 0xc930, noble 0xcef0, jammy 0xd060), porque el delta entre zval_ptr_dtor y zend_call_function cambia en cada build. El bundle con el request de disparo y las cadenas PoC está disponible para descarga, con hash SHA-256 publicado.

Es un análisis pre-advisory, no el comunicado oficial. Pero es exactamente el tipo de material que un atacante necesita, y está publicado gratis.

Por qué el timing es el verdadero riesgo

El patrón ya se vio hace semanas. WordPress publicó su versión 7.1.2 para cerrar CVE-2026-87902, un path traversal no autenticado también calificado 9.2 en CVSS v4.0. Según Help Net Security, citando a la firma de seguridad Patchstack, la explotación pasó de reconocimiento a escritura de archivos PHP en disco en cuestión de días, y el tráfico contra esa vulnerabilidad se multiplicó por más de diez respecto de la primera noche.

La lección se repite: el intervalo entre la divulgación y la explotación activa se mide en horas o días, no en semanas. Cuando la filtración llega antes que el parche, ese intervalo arranca con el reloj en negativo.

Mitigación inmediata: qué hacer hoy

El propio análisis técnico propone cuatro pasos que se pueden ejecutar sin esperar el advisory oficial.

• Inventario de PHP. Corre php -v en cada host y anota la versión. Cualquier cosa en PHP 7.x o anterior no recibirá fix: la decisión ahí es planificar la migración, no parchear.
• Aplicar el stopgap. En php.ini, .user.ini o .htaccess, poner session.upload_progress.enabled = Off y recargar PHP-FPM o el servidor web. Según el análisis, esto cierra una de las dos rutas probables.
• Acotar los uploads multipart en el borde. La segunda ruta vive en el parser multipart, que corre para cualquier POST multipart/form-data sin importar la configuración anterior. Si tienes WAF o reverse proxy, endurece la inspección o limita la tasa de POSTs multipart hacia endpoints que no necesitan subir archivos.
• Parchear en cuanto salga. El post lista como estables actuales 8.5.11 / 8.4.26 / 8.3.35 / 8.2.34. Si tu hosting es gestionado, confirma hoy la línea de tiempo de tu proveedor.

Qué significa esto para tu startup

Tres cosas concretas, en orden de urgencia.

Primero, haz el inventario esta noche. La mayoría de los equipos pequeños no sabe con precisión qué versión de PHP corre en cada entorno —staging, producción, el worker de colas, el panel de administración—. Ese desconocimiento es el que convierte una vulnerabilidad en un incidente.

Segundo, aplica el stopgap y mide el impacto. Desactivar session.upload_progress puede romper barras de progreso de subida en tu producto. Verifica qué endpoints dependen de esa funcionalidad antes de desplegar, y ten un plan de rollback listo. Un cambio reversible de una línea es infinitamente más barato que un post-mortem.

Tercero, revisa tu contrato de hosting. Si estás en hosting compartido o en un proveedor gestionado en LATAM o España, la pregunta no es cuándo parchean, sino si te van a avisar. Pide confirmación por escrito de la línea de tiempo y de si aplican el stopgap mientras tanto.

Y una cuarta, de higiene: instrumenta los logs. Busca picos de POSTs multipart hacia endpoints que no reciben archivos. Es la señal más barata de detección temprana que tienes disponible hoy.

Conclusión

La filtración de CVE-2026-109618 y CVE-2026-109619 deja a los equipos que corren PHP en una posición incómoda pero manejable: el exploit es público, el parche todavía no. La diferencia entre las startups que salen ilesas y las que terminan en respuesta a incidentes no será la suerte, sino haber usado las próximas horas para inventariar, mitigar y confirmar la línea de tiempo de su proveedor.

El autor del análisis se comprometió a publicar un seguimiento cuando salga el advisory oficial, para confirmar si su lectura de la causa raíz fue correcta. Vale la pena tenerlo en el radar.

Fuentes

• jackalsyn.com (fuente original)
• BleepingComputer
• Help Net Security