El 21 de octubre de 2026 se publicaron correcciones para dos vulnerabilidades críticas del intérprete PHP, identificadas como CVE-2026-109618 y CVE-2026-109619, también conocidas conjuntamente como PHP2Shell.
Los fallos afectan al tratamiento de determinadas solicitudes HTTP y pueden provocar corrupción de memoria. En condiciones de explotación adecuadas, un atacante remoto sin autenticar podría llegar a ejecutar código en un servidor vulnerable.
La alerta afecta especialmente a administradores de servidores, proveedores de alojamiento y responsables de aplicaciones desarrolladas en PHP, como WordPress, WooCommerce, Moodle, Drupal y Joomla.
¿Qué ocurrió con PHP en octubre de 2026?
El equipo de seguridad de PHP coordinó una publicación de emergencia para corregir dos vulnerabilidades de alta gravedad.
Ambas recibieron una puntuación de 9,2 sobre 10 en CVSS 4.0, correspondiente a una clasificación crítica.
El problema se encuentra en componentes internos de PHP relacionados con la gestión de memoria y el procesamiento de solicitudes. No depende necesariamente de que una página web tenga un plugin vulnerable.
Esto significa que una aplicación actualizada también podría verse afectada si utiliza un intérprete PHP vulnerable y se cumplen las condiciones necesarias para explotar el fallo.
CVE-2026-109618: errores en la gestión de memoria
La vulnerabilidad CVE-2026-109618 está relacionada con la gestión de memoria durante el procesamiento de solicitudes.
Cuando una asignación de memoria falla, PHP puede conservar un estado interno incompleto que posteriormente se utiliza durante las operaciones de limpieza.
Este comportamiento puede provocar corrupción de memoria y, bajo determinadas circunstancias, permitir la ejecución remota de código.
La explotación práctica depende de factores como el entorno de ejecución, la configuración del servidor y la capacidad del atacante para manipular el estado de memoria.
CVE-2026-109619: problemas durante la limpieza de solicitudes
La segunda vulnerabilidad, CVE-2026-109619, también afecta a la seguridad de la memoria.
En este caso, un error fatal puede interrumpir determinadas operaciones de limpieza y dejar referencias internas a memoria que ya ha sido liberada.
Si esas referencias vuelven a utilizarse, pueden producirse accesos indebidos a memoria y situaciones potencialmente explotables.
Ambos fallos justifican la aplicación prioritaria de las correcciones publicadas por PHP y los distribuidores de paquetes.
¿Qué versiones oficiales de PHP recibieron correcciones?
Las versiones corregidas publicadas para las ramas PHP con soporte fueron las siguientes:
| Rama PHP | Versión oficial corregida |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Sin embargo, en servidores que utilizan distribuciones profesionales, la comprobación no debe limitarse al número de versión mostrado por PHP.
CloudLinux y los parches de seguridad mediante backport
CloudLinux distribuye versiones de PHP adaptadas a entornos de alojamiento, incluyendo ALT-PHP y paquetes integrados con cPanel mediante EasyApache.
Una característica importante de estas distribuciones es la posibilidad de incorporar correcciones mediante backports de seguridad.
Un backport consiste en adaptar una corrección de seguridad a una versión existente del software sin necesidad de cambiar toda la rama de PHP.
Por ejemplo, un paquete identificado como PHP 8.3.35 puede incorporar una corrección de seguridad que también aparece en la versión oficial PHP 8.3.36.
La clave está en comprobar la revisión completa del paquete y su registro de cambios, no únicamente el número de versión de PHP.
Un caso real: verificación de seguridad del 22 de octubre de 2026
El 22 de octubre de 2026 realizamos una revisión técnica en un servidor de alojamiento que utiliza CloudLinux y cPanel.
El objetivo era comprobar si los paquetes PHP instalados incorporaban las correcciones para CVE-2026-109618 y CVE-2026-109619.
Mediante consultas a la base de datos RPM y a los registros de cambios de los paquetes, obtuvimos los siguientes resultados:
| Entorno | Paquete verificado | Resultado |
|---|---|---|
| CloudLinux ALT-PHP 8.2 | 8.2.34-7 | Correcciones documentadas |
| CloudLinux ALT-PHP 8.3 | 8.3.35-6 | Correcciones documentadas |
| cPanel EA-PHP 8.3 | 8.3.35-2.cloudlinux.2 | Correcciones documentadas |
Los registros de cambios de los tres paquetes identificaban expresamente ambas vulnerabilidades y documentaban la incorporación de las correcciones el 21 de octubre de 2026.
Por tanto, los paquetes examinados incluían los parches correspondientes, aunque su número de versión PHP no coincidía con el de las publicaciones oficiales más recientes.
Importante: esta evidencia corresponde exclusivamente a la comprobación realizada el 22 de octubre de 2026. No representa el estado actual de todos los servidores CloudLinux ni garantiza que cualquier instalación con esos números de versión esté corregida.
Cómo comprobar los parches PHP desde SSH
En servidores basados en RPM, como determinados entornos CloudLinux, los administradores con acceso autorizado pueden consultar las versiones instaladas mediante comandos de solo lectura.
1. Consultar los paquetes PHP instalados
rpm -q alt-php82 alt-php83 ea-php83-php-commonEste comando muestra las revisiones de los paquetes instalados, sin realizar modificaciones.
2. Consultar los registros de cambios
rpm -q --changelog alt-php82 | head -35
rpm -q --changelog alt-php83 | head -35
rpm -q --changelog ea-php83-php-common | head -35Los registros permiten identificar correcciones documentadas por el proveedor.
3. Buscar referencias a las vulnerabilidades
rpm -q --changelog alt-php83 | grep -E 'CVE-2026-109618|CVE-2026-109619'Si aparecen ambas referencias, debe revisarse el contexto del registro para comprobar que corresponden a una corrección incluida en el paquete instalado.
La presencia de una referencia CVE en un changelog no sustituye por sí sola una evaluación completa del entorno.
4. Consultar las actualizaciones disponibles
dnf check-update 'alt-php*' 'ea-php*'Este comando permite consultar actualizaciones disponibles en los repositorios configurados. No instala paquetes.
Antes de actualizar un servidor de producción, es recomendable revisar las dependencias, disponer de copias de seguridad y planificar una ventana de mantenimiento cuando sea necesario.
¿Un firewall puede proteger frente a PHP2Shell?
Los sistemas de protección de aplicaciones web pueden ayudar a bloquear determinados patrones de explotación.
CloudLinux informó de reglas específicas de Imunify360 orientadas a bloquear una forma conocida de explotación de estas vulnerabilidades.
Sin embargo, una regla WAF es una medida de mitigación y no sustituye la corrección del intérprete PHP.
La prioridad debe ser instalar los paquetes de seguridad adecuados y verificar que los servicios están utilizando las versiones corregidas.
¿Es obligatorio cambiar inmediatamente a otra versión de PHP?
No siempre es necesario cambiar de rama PHP para corregir una vulnerabilidad concreta.
Si el proveedor mantiene una rama mediante parches de seguridad y ha incorporado la corrección correspondiente, puede ser posible mantener esa versión sin realizar una migración inmediata.
Sin embargo, esto no significa que debamos mantener indefinidamente versiones antiguas.
La planificación debe considerar el ciclo de soporte, la compatibilidad de las aplicaciones, las extensiones instaladas y la disponibilidad de actualizaciones futuras.
Además, actualizar los paquetes PHP del servidor y cambiar la versión PHP seleccionada para una aplicación son operaciones diferentes.
Preguntas frecuentes sobre las vulnerabilidades PHP de octubre de 2026
¿Qué es PHP2Shell?
Es la denominación utilizada para referirse conjuntamente a las vulnerabilidades CVE-2026-109618 y CVE-2026-109619, relacionadas con corrupción de memoria durante el procesamiento de solicitudes PHP.
¿Las vulnerabilidades permiten ejecutar código remotamente?
Sí, existe riesgo de ejecución remota de código en entornos vulnerables. La viabilidad práctica depende de la configuración y de las condiciones necesarias para explotar los fallos.
¿WordPress y WooCommerce están afectados?
Pueden verse expuestos si se ejecutan sobre una versión vulnerable de PHP. No se trata necesariamente de un fallo propio de WordPress o WooCommerce, sino del intérprete utilizado por estas aplicaciones.
¿PHP 8.3.35 es siempre vulnerable?
No necesariamente. Una distribución puede incorporar correcciones mediante backports. Es necesario comprobar la revisión completa del paquete y los avisos de seguridad del proveedor.
¿Cómo puedo saber si CloudLinux instaló los parches?
Un administrador puede consultar los paquetes instalados, sus changelogs y los avisos de CloudLinux. También debe verificar qué entorno PHP utiliza efectivamente cada aplicación.
¿Actualizar WordPress corrige estas vulnerabilidades?
No. Actualizar WordPress es importante para su propia seguridad, pero estas vulnerabilidades corresponden al intérprete PHP. Deben corregirse en el entorno de ejecución.
¿Es suficiente instalar reglas de firewall?
No. Un firewall de aplicaciones puede reducir determinados riesgos, pero no sustituye la instalación de los parches de seguridad.
¿Qué hacer si mi proveedor todavía no ofrece una versión corregida?
Consulta sus avisos oficiales, solicita información sobre los parches disponibles y las medidas temporales de mitigación, y evalúa las opciones de actualización o migración con un administrador técnico.
Conclusión
Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 recuerdan la importancia de mantener actualizados los componentes que ejecutan las aplicaciones web.
También demuestran que comprobar la seguridad de PHP requiere algo más que consultar su número de versión.
Los paquetes de distribuciones profesionales pueden incorporar correcciones mediante backports, y su estado debe verificarse utilizando documentación del fabricante y evidencias técnicas.
La mejor respuesta ante una vulnerabilidad crítica es identificar el riesgo, comprobar los parches disponibles y aplicar las correcciones correspondientes sin comprometer innecesariamente la estabilidad de las aplicaciones.
