PHP 8.5.12 corrige 2 fallos críticos de RCE sin login

PHP publica parches de emergencia para dos RCE sin autenticación

El equipo de PHP liberó el 21 de octubre las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades de ejecución remota de código (RCE) sin autenticación, calificadas con CVSS 9.2 por el equipo de seguridad del proyecto, según reportó Help Net Security. La instrucción oficial es directa: actualizar de inmediato.

El dato que debería encender una alarma en cualquier equipo de producto es el tamaño de la superficie expuesta. W3Techs estima que PHP impulsa cerca del 70% de los sitios web cuyo lenguaje de servidor es conocido, un porcentaje que Infosecurity Magazine precisa en 69,7%. Si tu producto corre sobre WordPress, Drupal, Joomla, Magento o cualquier stack PHP, esta nota te toca directamente.

¿Quién está en riesgo con CVE-2026-109618 y CVE-2026-109619?

Toda instalación PHP que sirva peticiones web. Eso incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

El riesgo más alto lo tienen los servidores con mod_php. Según el aviso oficial, existe un exploit demostrado en el que una sola petición no autenticada dispara el ataque antes de que se ejecute cualquier código de la aplicación. En términos prácticos: la pantalla de login y los plugins de seguridad de WordPress quedan fuera de la ecuación, porque el fallo ocurre en una capa anterior.

Las dos vulnerabilidades, explicadas sin jerga

• CVE-2026-109618 — RCE por corrupción en el manejo de memoria (OOM): cuando PHP se queda sin memoria durante el procesamiento de una petición, puede interrumpirse con los datos internos de esa petición a medio inicializar. La limpieza posterior trata esos datos inválidos como si fueran válidos.
• CVE-2026-109619 — RCE por estado global obsoleto: el estado interno de una petición sobrevive después de que la memoria que lo respaldaba fue liberada. Una petición posterior atendida por el mismo worker puede usar ese estado viejo antes de que la inicialización normal lo reinicie.

Ambos casos comparten un patrón incómodo: el fallo no está en tu código, está en el runtime. No hay un input malicioso que puedas filtrar con validación de formularios.

Un fallo de décadas que la IA volvió explotable

El ángulo más relevante para el ecosistema startup viene de los investigadores de Wiz, citados por Help Net Security: los fallos subyacentes existían desde hace décadas, pero demostrar su explotabilidad exigía una cadena de pasos tan compleja que estaba en el límite de lo que un investigador humano podía lograr. Los modelos de IA de frontera redujeron esa barrera y convirtieron un defecto histórico en un exploit funcional.

Es la otra cara de la IA aplicada a seguridad: acelera el descubrimiento de vulnerabilidades para bien y para mal. El investigador independiente Kevin Beaumont fue tajante al respecto: "la situación de PHP va a generar una masa de incidentes, es una de las vulnerabilidades más grandes en años".

La filtración y la carrera contra el reloj

El parche estaba programado para el 21 de octubre a las 14:00 GMT, pero un usuario identificado como petecooper publicó los identificadores CVE en Hacker News el 20 de octubre, un día antes, según Infosecurity Magazine. El post fue eliminado después, pero el daño ya estaba hecho: con los CVE públicos, los atacantes pueden comparar el código viejo con el parcheado y reconstruir el exploit.

La presión fue real. Dane Knecht, CTO de Cloudflare, reportó ataques emergentes la madrugada del miércoles, casi seis horas antes de que los parches estuvieran disponibles, y la compañía desplegó reglas de firewall de emergencia para todos sus clientes, incluidas las cuentas gratuitas. La firma forense Sansec esperaba ataques masivos en los 15 minutos posteriores a la publicación. Como referencia de velocidad, Akamai registró intentos contra servidores señuelo dentro de las 24 horas siguientes a la divulgación de otra vulnerabilidad de PHP en junio de 2024.

La reacción institucional fue igual de contundente: el centro estatal de TI de Finlandia, Valtori, empezó a desconectar servicios web públicos; la agencia nacional de ciberseguridad de Países Bajos sacó su sitio de internet; el Ministerio del Interior de Francia desconectó temporalmente sitios de prefecturas; la NSA recomendó apagar los sitios; y CERT-EU aconsejó aislar las aplicaciones expuestas a internet mientras no hubiera parche.

¿Cómo actualizar PHP en tu servidor?

• Sube a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Las descargas de código fuente y los binarios de Windows están en la página oficial de descargas.
• Las distribuciones de Linux y los proveedores de soporte a largo plazo (LTS) recibieron los parches con antelación: revisa los paquetes de tu proveedor.
• PHP 8.1 y anteriores ya no reciben actualizaciones oficiales. El equipo de seguridad publicó backports mínimos de código fuente para PHP 7.4, 8.0 y 8.1, pensados para quienes compilan desde código fuente o no tienen un proveedor LTS.
• Si dependes de rpms.remirepo.net, el repositorio mantenido por voluntarios, cambia a los paquetes de tu distribución o compila desde fuente: ese repositorio no tendría actualizaciones ese día.
• Ojo con un detalle que Wordfence señaló: las actualizaciones automáticas de WordPress no instalan el parche de PHP. Es una capa distinta del servidor.

El inventario pendiente es enorme. La firma Mallory contó alrededor de 884.000 hosts expuestos a internet que anunciaban PHP 8.1 o anterior el 20 de octubre, el 59% de unos 1,5 millones de hosts que revelaban su versión. Y el reloj sigue corriendo: PHP 8.2 llega a fin de vida el 31 de diciembre de 2026, después de lo cual no recibirá más parches de seguridad.

Si no puedes actualizar hoy: mitigaciones temporales

El propio equipo de PHP advierte que estas medidas reducen la exposición a rutas de ataque específicas, pero no hacen segura una instalación. Solo el parche es una solución completa.

Para CVE-2026-109618:

• Configura memory_limit=-1, preferiblemente de forma que las aplicaciones no puedan sobrescribirlo (por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache), y verifica que ningún pool, directorio o ajuste de la aplicación vuelva a poner un límite finito.
• Baja postmaxsize. Si tu aplicación no necesita subida de archivos, usa 8M; si los necesita, 32M, manteniendo upload_max_filesize por debajo de post_max_size.
• Aplica límites en el servidor web o el proxy para tamaño de petición decodificada, número de campos, número de partes multipart, número de cabeceras y profundidad de anidamiento. Esos límites deben cubrir también peticiones sin Content-Length utilizable.
• Usa un límite de contenedor o cgroup como frontera de disponibilidad, con una política que mate solo el worker afectado. No sustituyas esto por RLIMIT_AS o RLIMIT_DATA: pueden provocar justamente el fallo de asignación vulnerable.

Para CVE-2026-109619:

• Pon session.upload_progress.enabled=0 y reinicia todos los workers. Hazlo desde php.ini, un pool de FPM o configuración del servidor que se aplique antes del parseo de la petición; no confíes en ini_set() ni en .user.ini de FPM.
• En PHP 8.5, pon fatalerrorbacktraces=0 y reinicia todos los workers.
• Elimina ajustes inválidos o deprecados aplicados por petición que emitan diagnósticos antes de la inicialización. Ocultar los diagnósticos con error_reporting, display_errors o @ no ayuda.
• Corrige los errores fatales y timeouts de ejecución alcanzables por un atacante, incluidos los fallos en callbacks, procesamiento de subidas o importaciones, y limpieza.

¿Qué significa esto para tu startup?

Este es el tipo de incidente que separa a los equipos que tienen inventario de infraestructura de los que no. Tres acciones concretas para hoy:

1. Averigua quién controla el PHP de tu servidor. Si estás en hosting compartido o en un PaaS, la respuesta puede ser "nadie de mi equipo". Wordfence advirtió que las actualizaciones automáticas de WordPress no cubren este parche: pregunta explícitamente a tu proveedor si ya aplicó la versión corregida y en qué fecha.
2. Haz un inventario de aplicaciones olvidadas. El experto en forense Hal Pomeranz lo resumió bien: hay demasiadas instalaciones embebidas que nunca se parchearán y demasiadas apps sin mantenimiento. Si tienes un panel interno, un micrositio de campaña o un CRM viejo en PHP 7.x, ese es tu riesgo real, no tu producto principal.
3. Si no puedes parchear en las próximas horas, aísla. CERT-EU y la NCSC británica recomiendan considerar desconectar del internet público las aplicaciones que no se puedan arreglar de inmediato. Para un SaaS en producción es una decisión de negocio dura, pero es mejor una ventana de mantenimiento planificada que un servidor tomado.

Conclusión

La frase de Gina Peter Banyard, desarrolladora del core de PHP, cierra el debate: parchear o actualizar es la única mitigación. Todo lo demás compra tiempo, no seguridad.

Para un founder, la lección de fondo es estructural. La IA está bajando el costo de encontrar vulnerabilidades en software que lleva décadas en producción, y eso significa que la deuda técnica de infraestructura deja de ser un problema abstracto para convertirse en un riesgo operativo con fecha. Revisar hoy qué versión de PHP corre tu producto, quién la administra y cuándo fue la última actualización es una tarea de treinta minutos que puede ahorrarte un incidente de semanas.

Fuentes

• PHP: News (fuente original)
• PHP2Shell: Critical PHP vulnerabilities patched, update now!
• Critical PHP Vulnerabilities Leaked Ahead of Scheduled Security Patches
• PHP Releases Critical Security Patches for 2 Zero-Day Vulnerabilities Affecting 70% of Websites