CVE-2026-109618 en PHP: fallo crítico de memoria, riesgo real y actualización urgente

Publicado el 2026-10-27 por frfrand

CVE-2026-109618 explicada: descubrimiento, PHP afectados, riesgo de RCE por memoria OOM y medidas oficiales del 21 de octubre de 2026.

¿Qué es CVE-2026-109618 y por qué se habla de ella?

El 21 de octubre de 2026, el equipo de PHP anunció dos fallos críticos en su motor. Uno es CVE-2026-109618, relacionado con cómo PHP gestiona errores de memoria durante el procesamiento de solicitudes. Su consecuencia potencial es seria: en determinadas situaciones, una solicitud enviada desde Internet podría provocar corrupción de memoria y ejecución remota de código sin iniciar sesión.

Este fallo no nace de un plugin de WordPress. Está en la plataforma PHP sobre la que trabajan WordPress, Drupal, Joomla y muchas aplicaciones propias. Por eso revisar solo los plugins no alcanza.

¿Quién encontró la vulnerabilidad?

La investigación fue divulgada por Wiz Research en coordinación con el equipo de seguridad de PHP. La publicación técnica de Wiz y los comunicados de proveedores describen el trabajo de descubrimiento, reporte y preparación del parche. Es un ejemplo de cómo investigaciones profundas sobre el motor del lenguaje pueden detectar problemas que no aparecen en una auditoría del código de una web.

¿Qué ocurre técnicamente?

Cuando una aplicación recibe una solicitud, PHP reserva memoria para interpretar datos internos. Si ocurre un error de falta de memoria (out of memory, OOM) durante ese proceso, cierta estructura podía quedar a medio inicializar. Después, durante la limpieza, el programa podía interpretar esos datos incompletos como si fueran válidos. Esa diferencia abre una posibilidad de corrupción de memoria.

¿Cómo podría aprovecharse?

La idea general es provocar condiciones que conduzcan al fallo de memoria durante el procesamiento de una petición y que alteren el comportamiento del trabajador PHP. En un escenario explotable, el atacante consigue que el proceso ejecute código con los permisos que tiene asignados. No equivale a que una solicitud cualquiera tome el control del sistema operativo: la viabilidad depende de la integración, la configuración, las protecciones de memoria y el camino de ejecución.

¿Qué servidores están afectados y cuál corre más riesgo?

PHP advirtió sobre instalaciones que atienden solicitudes web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Señaló especial preocupación por mod_php, con un escenario demostrado de explotación sin autenticación antes de que comience el código de la aplicación. Otras integraciones pueden tener requisitos diferentes y deben evaluarse individualmente.

¿Cuáles son las versiones corregidas?

El fabricante publicó los siguientes primeros parches en sus ramas: - PHP 8.5.12 - PHP 8.4.27 - PHP 8.3.36 - PHP 8.2.35

Las versiones anteriores de esas ramas requieren revisión. PHP 8.1 y anteriores están fuera del soporte principal del proyecto. Algunas distribuciones y proveedores LTS han incorporado parches propios o retroportados; consultá su boletín exacto si utilizás paquetes de sistema. El equipo PHP también ofreció retroportaciones mínimas de código para ciertas ramas antiguas, lo que no las convierte en ramas generales con soporte.

¿Cómo compruebo si mi WordPress o mi API PHP están expuestos?

Identificá todos los entornos: producción, staging, tareas programadas, contenedores y servidores olvidados. php -v ayuda, pero ojo: la versión de CLI puede diferir de PHP-FPM o Apache, así que contrastá la configuración real del servidor web. Mirá la versión del paquete y la revisión del proveedor, cómo llega el tráfico a PHP y qué workers siguen ejecutándose tras una actualización.

¿Cómo se soluciona y qué hago mientras actualizo?

La solución completa es instalar el parche y reiniciar o redeplegar todos los procesos relevantes. PHP publicó medidas temporales para reducir vías específicas, como ajustar límites de entrada y ciertos parámetros de memoria bajo supervisión técnica. Son cambios que pueden afectar disponibilidad y no vuelven segura una instalación sin actualizar; no conviene copiarlos sin analizar recursos y configuración. Hacé backup, staging, actualización, reinicio y comprobación de respuesta de las aplicaciones.

Preguntas rápidas

¿Actualizar WordPress arregla el CVE? No. La corrección es del runtime PHP, aunque después debas validar WordPress.

¿Con un WAF alcanza? No: es una barrera adicional, no la reparación del motor.

¿Cómo sé si ya explotaron mi sitio? Revisá señales de procesos inesperados, cambios de archivos y accesos, pero no afirmes compromiso solo por usar una versión afectada. Ante indicios, conservá evidencia y seguí un proceso de respuesta a incidentes.

Fuentes verificables: Aviso PHP del 21/10/2026 · Boletín AWS · Respuesta de Google Cloud · Registro CVE.

¿Dónde se actualiza la información y cómo pedir orientación?

En ArduMaker — CVE y soporte mantenemos información para revisar incidencias y canalizar consultas, especialmente en WordPress y las tecnologías que lo ejecutan. Para evaluar un caso concreto aportá tecnología, versión, sistema operativo, modo de despliegue y mensajes de error relevantes sin publicar credenciales. Un CVE anunciado no significa que todos los sistemas estén comprometidos.

Revisión editorial: 27 de octubre de 2026. Las recomendaciones pueden cambiar con nuevas publicaciones del fabricante.

Ejemplo práctico: actualizar PHP en un WordPress con PHP-FPM

Situación: el administrador actualiza WordPress, pero la web sigue usando PHP 8.4.26. Eso no soluciona CVE-2026-109618, porque el fallo está en el motor PHP. La primera corrección de la rama 8.4 fue 8.4.27.

En un VPS Ubuntu con PHP-FPM, empezá por identificar servicios y versión instalada:

php -v
systemctl list-units --type=service 'php*-fpm.service'

Comprobá también qué socket FPM utiliza Nginx/Apache y la versión del worker que sirve la web; la CLI puede ser distinta. Instalá el paquete corregido del repositorio de confianza, reiniciá todos los workers afectados y validá las funciones críticas.

Antes: sitio aparentemente actualizado, runtime PHP vulnerable. Después: runtime parcheado, imagen Docker o paquete reconstruido si aplica, workers nuevos y smoke tests de login, formularios y pagos.

¿Qué riesgo concreto se reduce? El fallo de memoria durante una petición HTTP que podía abrir una vía de ejecución de código con los permisos del proceso. No se requiere «probar el exploit» contra producción para confirmar que instalaste la versión corregida.