Vulnerabilidades críticas de PHP: qué deben revisar las empresas

Las vulnerabilidades críticas de PHP publicadas el 21 de octubre de 2026 obligan a revisar el intérprete que ejecuta los sitios web en el servidor. El proyecto PHP lanzó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 para corregir las fallas CVE-2026-109618 y CVE-2026-109619, cuya severidad fue evaluada con 9,2 sobre 10 en la escala CVSS.

Las vulnerabilidades críticas de PHP publicadas el 21 de octubre de 2026 requieren una revisión inmediata en sitios institucionales, catálogos, tiendas y aplicaciones que utilicen este lenguaje en el servidor. Según el material de origen, las fallas pueden permitir ejecución remota de código sin autenticación, por lo que la actualización debe coordinarse con el proveedor de alojamiento o el equipo responsable de la infraestructura. Ampliación relacionada en Posicionamiento Web: PHP: qué deben actualizar los sitios tras dos fallas críticas.

El proyecto PHP publicó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 para corregir los identificadores CVE-2026-109618 y CVE-2026-109619. La información fue difundida el 21 de octubre y la revisión editorial de referencia corresponde al 22 de octubre de 2026. Las afirmaciones técnicas se basan en el aviso y la guía publicados por DWVisual.

Qué versiones de PHP incluyen las correcciones

Las versiones de referencia informadas para las ramas mantenidas son PHP 8.2.35, PHP 8.3.36, PHP 8.4.27 y PHP 8.5.12. Para confirmar la actualización no alcanza con saber que el servidor utiliza PHP 8.3 o PHP 8.4: es necesario conocer el número completo del parche o el identificador del paquete instalado.

En servidores administrados por una distribución o por un proveedor con soporte extendido, la corrección puede incorporarse sin adoptar exactamente la numeración oficial del proyecto PHP. En esos casos, la empresa debe solicitar el boletín aplicable y la identificación del paquete que atiende cada dominio.

Por qué las fallas requieren revisar el servidor

La CVE-2026-109618 está relacionada con una corrupción asociada al agotamiento de memoria. El aviso técnico describe un escenario en el que PHP puede interrumpir una operación cuando determinados datos todavía no fueron inicializados por completo. Durante el cierre de la solicitud, el proceso podría utilizar ese estado inválido.

La información suministrada también señala que el informe documenta ejecución remota de código en Apache con mod_php, incluso antes de que se ejecute el código de la aplicación. En ese escenario, una medida aplicada dentro de WordPress podría llegar demasiado tarde.

La CVE-2026-109619 se vincula con la reutilización de un estado interno obsoleto. Parte de la información de una solicitud podría permanecer en un proceso después de liberar la memoria, y una solicitud posterior podría acceder a ese estado antes de su reinicialización. Para las empresas, esto refuerza la necesidad de confirmar que el paquete instalado corrige ambos identificadores.

Qué instalaciones deben entrar en la revisión

El alcance anunciado incluye servicios que atienden solicitudes web mediante PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El aviso destaca el riesgo demostrado en mod_php, pero utilizar otra modalidad no permite descartar la revisión.

La alerta se refiere al intérprete de PHP y no atribuye el problema a un plugin específico de WordPress. Por eso, tener WordPress, sus temas y sus extensiones actualizados no demuestra que el servidor tenga aplicado el parche correspondiente. Son capas diferentes, con responsables y ciclos de actualización distintos.

También deben contemplarse los subdominios, las tiendas separadas de la web institucional, las aplicaciones internas expuestas y los entornos de prueba que sigan atendiendo solicitudes. Confirmar la portada principal no permite dar por revisado todo un servicio de hosting.

Cómo confirmar la versión que atiende cada dominio

En WordPress, la versión puede consultarse desde Herramientas → Salud del sitio → Información → Servidor, siempre que el panel muestre ese dato. Conviene registrar la versión completa, la fecha de consulta y el dominio al que corresponde.

En los servidores con cPanel, MultiPHP Manager puede mostrar la configuración de PHP por dominio cuando el proveedor habilita esa función. Sin embargo, seleccionar una rama como PHP 8.3 no confirma por sí solo que el último parche esté instalado. Si el panel no muestra el número completo, hay que pedirlo al proveedor.

La comprobación debería conservar dos evidencias: el dato observado desde la aplicación y la confirmación del proveedor sobre el paquete corregido. Una respuesta genérica como “el servidor está protegido” no identifica qué versión se instaló, qué boletín se aplicó ni qué dominios quedaron incluidos.

Qué deben coordinar la empresa y el proveedor

La actualización requiere definir un responsable técnico, una ventana de intervención y el alcance exacto de los dominios y aplicaciones. El proveedor puede confirmar paquetes, procesos y configuración del servidor; el equipo que mantiene la web debe revisar compatibilidad y funcionamiento.

Antes de modificar producción, es prudente comprobar que exista un respaldo legible de los archivos y de la base de datos correspondiente. En una tienda, además, debe acordarse cómo evitar la pérdida de pedidos u operaciones recientes durante una restauración o cambio de configuración.

Después de aplicar el parche, las pruebas deben responder al uso real del sitio. En una web institucional pueden revisarse la navegación, la búsqueda y la recepción de formularios. En una tienda, el control debería incluir productos, variantes, carrito y el recorrido de compra en un entorno autorizado. Un mensaje de éxito en pantalla no demuestra por sí mismo que una consulta llegó al buzón correspondiente.

Qué hacer si aparece una incompatibilidad

Si la actualización genera conflictos, la alternativa debe conservar la corrección de seguridad. Volver a una versión vulnerable puede reabrir la exposición. Los cambios temporales en parámetros de memoria, carga de archivos o sesiones también requieren evaluación técnica, porque pueden afectar la disponibilidad o el funcionamiento del sitio.

La información de origen menciona protecciones de firewall de aplicaciones comunicadas por Cloudflare, pero un servicio contratado o un indicador visible en un panel no demuestra que la configuración esté activa para el tráfico correspondiente. Un WAF puede formar parte de la mitigación, aunque no reemplaza la actualización del intérprete.

PHP 8.2 tiene soporte de seguridad previsto hasta el 31 de diciembre de 2026, mientras que PHP 8.1 y las ramas anteriores ya están fuera del soporte ordinario del proyecto. El material también indica que se ofrecieron correcciones mínimas de código fuente para las ramas 7.4, 8.0 y 8.1, sin que eso restablezca su ciclo normal de soporte. La actualización inmediata y la migración a una rama soportada son decisiones diferentes.

Qué relación tiene el parche con la continuidad del sitio

Aplicar una corrección de PHP no garantiza mejores posiciones en Google ni constituye una acción de posicionamiento. Sí reduce una exposición técnica que podría afectar la disponibilidad y la integridad de la web. Un incidente puede introducir contenido ajeno, modificar enlaces, generar redirecciones o impedir el acceso a páginas importantes.

Luego de la intervención, la empresa debería verificar las páginas principales, los formularios y las señales de indexación. Si se utilizó un entorno de prueba, también debe comprobarse que sus restricciones no hayan quedado aplicadas por error en la web pública. La prioridad práctica es documentar qué paquete se corrigió, qué instalaciones fueron revisadas y qué tareas permanecen pendientes.