PHP corrige dos fallas críticas que exigen revisar servidores web

Las vulnerabilidades críticas de PHP publicadas el 21 de octubre de 2026 requieren comprobar qué versión completa ejecuta cada sitio y si incluye las correcciones para CVE-2026-109618 y CVE-2026-109619. El proyecto PHP lanzó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12; ambas fallas pueden permitir ejecución remota de código sin autenticación en determinadas condiciones.

La información disponible fue revisada el 22 de octubre de 2026. La recomendación oficial es actualizar de inmediato, pero la acción no consiste en cambiar una rama de PHP sin evaluar compatibilidad: primero hay que identificar el paquete que atiende cada dominio y confirmar que resuelve los dos identificadores.

Qué corrigió PHP en las versiones publicadas

Los avisos describen problemas relacionados con la gestión interna de memoria y el estado de las solicitudes. Ambos recibieron una puntuación CVSS de 9,2 sobre 10, una medida de severidad técnica que no indica cuántos sitios fueron comprometidos ni demuestra que una empresa concreta haya sufrido un ataque.

La vulnerabilidad CVE-2026-109618 se vincula con una corrupción asociada al agotamiento de memoria. Bajo ciertas condiciones, PHP puede interrumpir una operación cuando algunos datos todavía no fueron inicializados por completo. Durante el cierre de la solicitud, el proceso podría utilizar ese estado inválido. El informe técnico 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.

La CVE-2026-109619 se relaciona con la reutilización de un estado interno obsoleto. Parte de la información de una solicitud puede sobrevivir en un proceso después de que su memoria haya sido liberada, y una solicitud posterior podría acceder a ella antes de su reinicialización.

El alcance incluye más que una instalación de WordPress

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

La alerta se refiere al intérprete de PHP, no a un plugin específico. WordPress, sus temas y sus extensiones forman parte de la aplicación; PHP es el entorno del servidor que ejecuta ese código. Son capas diferentes, con ciclos de actualización distintos.

Por eso, que el panel de WordPress indique que el núcleo, los temas y los plugins están actualizados no demuestra que el intérprete tenga instalado el parche. La comprobación debe hacerse sobre el servidor o solicitarse al proveedor de alojamiento.

La versión completa importa más que la rama

Los lanzamientos corregidos anunciados para las ramas mantenidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Un dato como “PHP 8.3” sólo identifica una familia y no permite saber si están incorporadas las correcciones de octubre.

Los proveedores pueden distribuir paquetes con una numeración distinta cuando aplican correcciones a través de una distribución o de un esquema de mantenimiento extendido. En esos casos, hay que pedir el identificador exacto del paquete y el boletín que documenta la solución para CVE-2026-109618 y CVE-2026-109619.

PHP 8.2 mantiene soporte de seguridad hasta el 31 de diciembre de 2026, según el calendario citado en el material de origen. Las ramas PHP 8.1 y anteriores ya están fuera del soporte ordinario del proyecto. También se ofrecieron correcciones mínimas de código fuente para PHP 7.4, 8.0 y 8.1, pero eso no restablece su ciclo normal de soporte. En una instalación antigua, la actualización inmediata y la migración a una rama soportada son decisiones relacionadas, aunque distintas.

Cómo confirmar qué ejecuta cada dominio

En WordPress, la versión puede consultarse en Herramientas → Salud del sitio → Información → Servidor. Conviene registrar el número completo, la fecha de consulta y el dominio correspondiente. Esa pantalla aporta un dato de la aplicación, pero no reemplaza la confirmación del paquete instalado por el proveedor.

En cPanel, MultiPHP Manager permite revisar la configuración de PHP por dominio cuando el alojamiento habilita esa interfaz. Seleccionar una rama no significa necesariamente que el servidor haya instalado el último parche disponible. Si el panel sólo muestra “PHP 8.3”, hay que solicitar la versión completa o el identificador del paquete.

La revisión debe incluir la web principal, las tiendas alojadas en subdominios, las instalaciones de prueba y cualquier aplicación que utilice el mismo servicio. Una respuesta sobre una cuenta de alojamiento no confirma automáticamente todos sus dominios.

La comprobación más sólida combina dos evidencias: el dato observado desde la aplicación y la confirmación del proveedor sobre el paquete corregido, la fecha de aplicación y la renovación de los procesos necesarios. Si ambas respuestas no coinciden, la tarea todavía no está cerrada.

Qué pedir al proveedor de alojamiento

El pedido debería solicitar la versión completa o el identificador del paquete, el boletín aplicable y la fecha de instalación. También debe preguntar si la corrección alcanza todos los dominios, subdominios y aplicaciones, y si los procesos que atienden las solicitudes fueron renovados.

Una respuesta como “el servidor está protegido” puede ser insuficiente. En cambio, un paquete identificable, una referencia técnica aplicable y un alcance claro permiten verificar qué se corrigió. La documentación debería conservarse junto con el inventario del sitio y la persona responsable de cada intervención.

Si aparece una incompatibilidad, la solución debe coordinarse sin volver a una versión vulnerable. Los cambios temporales en parámetros de memoria, carga de archivos o sesiones pueden afectar funciones y disponibilidad. Los avisos de PHP describen mitigaciones para vías concretas, pero no las convierten en reemplazo permanente del parche.

La actualización exige una prueba funcional del sitio

Antes de intervenir, es necesario comprobar que existe un respaldo legible y que corresponde a la instalación correcta. En una tienda con pedidos recientes, la persona responsable también debe definir cómo evitar la pérdida de operaciones durante una restauración o un cambio de configuración.

Las pruebas posteriores dependen del uso del sitio. En una web institucional pueden incluir la navegación, la búsqueda y la recepción de una consulta de prueba. En una tienda, deberían abarcar productos, variantes, carrito y el recorrido de compra en un entorno autorizado. Ver la portada no confirma que todos esos procesos funcionen.

También hay que revisar si los formularios muestran un mensaje de éxito y si la entrega posterior efectivamente se produce. El registro debería describir el resultado observado, por ejemplo, “consulta recibida en el buzón acordado”, en lugar de limitarse a indicar que el formulario fue revisado.

Por qué un parche de PHP también importa para la presencia digital

Actualizar PHP no garantiza mejores posiciones en Google ni constituye una acción de optimización. Sí forma parte del mantenimiento necesario para conservar una web disponible y evitar que una intrusión introduzca contenido ajeno, redirecciones, enlaces alterados o páginas inaccesibles.

Cloudflare informó protecciones de su firewall de aplicaciones para estas vulnerabilidades. Si una infraestructura utiliza un WAF, el proveedor debe confirmar que la protección está activa y cubre el tráfico correspondiente. Tener contratado el servicio o ver su logotipo en un panel no demuestra que la configuración sea efectiva. La actualización del intérprete sigue siendo necesaria.

Después del cambio, conviene comprobar las páginas importantes, los formularios y las señales de indexación. También hay que verificar que las restricciones de un entorno de prueba no hayan terminado aplicándose en la web pública. Si existió un compromiso, determinar su alcance requiere una investigación técnica específica; el parche por sí solo no permite descartar incidentes anteriores.

La fuente original de DWVisual propone documentar cada dominio, responsable, evidencia y próxima revisión. Ese enfoque permite transformar una actualización urgente en una comprobación trazable, sin confundir una versión declarada con una garantía general de seguridad.