Parche de PHP: qué revisar en tu web por dos fallas críticas

El proyecto PHP publicó el 21 de octubre de 2026 las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 para corregir dos fallas críticas que pueden permitir ejecución remota de código sin autenticación. La revisión debe confirmar qué versión completa ejecuta cada dominio y si el paquete instalado incluye las correcciones CVE-2026-109618 y CVE-2026-109619. Ampliación relacionada en Posicionamiento Web: PHP: qué deben actualizar los sitios tras dos fallas críticas.

El proyecto PHP publicó el 21 de octubre de 2026 nuevas versiones de sus ramas mantenidas para corregir dos vulnerabilidades críticas. El aviso difundido por DWVisual identifica los problemas como CVE-2026-109618 y CVE-2026-109619, y recomienda actualizar de inmediato.

La alerta es relevante para webs institucionales, catálogos, tiendas y sitios con WordPress porque PHP es el entorno del servidor que ejecuta el código de la aplicación. Que WordPress, sus plugins o el certificado HTTPS estén actualizados no demuestra que el intérprete de PHP tenga aplicado el parche.

Qué corrigieron las nuevas versiones de PHP

Las versiones de referencia publicadas para las ramas indicadas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. La información suministrada atribuye a las dos vulnerabilidades una puntuación CVSS de 9,2 sobre 10, una medida de severidad técnica que no indica cuántos sitios fueron comprometidos ni permite afirmar que una empresa concreta haya sufrido un ataque.

CVE-2026-109618 se relaciona con corrupción de memoria después de un agotamiento de recursos. Según el informe técnico mencionado en la fuente, el escenario puede permitir ejecución remota de código en Apache con mod_php, incluso antes de que se ejecute el código de la aplicación.

CVE-2026-109619 se vincula con la reutilización de un estado interno obsoleto entre solicitudes. En determinadas condiciones, una solicitud posterior podría acceder a información que no fue reinicializada correctamente. La consecuencia práctica es que el proveedor debe identificar el paquete corregido, no limitarse a informar que el servidor está actualizado.

Qué instalaciones quedan dentro de 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 comprobación.

La alerta se refiere al intérprete de PHP y no atribuye estas fallas a un plugin específico de WordPress. Una empresa puede tener varias instalaciones: el sitio principal, una tienda en otro subdominio y un entorno de pruebas. Confirmar la versión de una sola web no alcanza para cerrar la revisión de todas.

Cómo confirmar el parche de PHP en cada dominio

El dato que debe reunirse es la versión completa de PHP que atiende cada dominio, junto con la evidencia de que el paquete incluye ambas correcciones. En WordPress, la ruta indicada por la documentación de Salud del sitio es Herramientas → Salud del sitio → Información → Servidor.

Si la administración se realiza mediante cPanel, MultiPHP Manager puede mostrar la configuración de PHP por dominio cuando el proveedor habilita esa interfaz. La selección de una rama, como PHP 8.3, no demuestra por sí sola que esté instalado el último parche disponible. Por eso conviene pedir el número completo o el identificador del paquete.

La comprobación debería registrar el dominio, la fecha, la versión observada y la respuesta del proveedor. Si ambos datos no coinciden, hay que investigar antes de marcar la tarea como resuelta: puede haber procesos diferentes, configuraciones heredadas o instalaciones que todavía no fueron actualizadas.

Qué pedirle al proveedor de hosting

El pedido debería solicitar la versión completa o el identificador del paquete instalado, el boletín que acredita la corrección de CVE-2026-109618 y CVE-2026-109619, la fecha de aplicación y la confirmación de que se renovaron los procesos necesarios.

También es importante pedir que el alcance incluya los subdominios y las aplicaciones asociadas. Una respuesta genérica como “el servidor está protegido” no permite comprobar qué se actualizó. En cambio, un paquete identificado, un aviso aplicable y una lista de dominios brindan una base concreta para evaluar el cierre.

PHP 8.2 mantiene soporte de seguridad hasta el 31 de diciembre de 2026, según el calendario citado en la fuente. Actualizar el parche dentro de la rama utilizada y migrar a otra rama son decisiones distintas: la primera atiende esta alerta, mientras que la segunda exige revisar compatibilidad y mantenimiento.

PHP 8.1 y las ramas anteriores están fuera del soporte ordinario del proyecto. Para esta situación se ofrecieron correcciones mínimas de código fuente para 7.4, 8.0 y 8.1, pero eso no restablece su ciclo normal de soporte. Si el proveedor mantiene una rama antigua, debe identificar cómo incorporó la corrección y acordar una migración a una rama soportada.

Qué verificar después de actualizar

La actualización debe coordinarse con una copia de respaldo comprobada y una ventana de intervención. Un archivo cuyo nombre contiene “backup” no demuestra que exista una copia legible ni que corresponda a la instalación correcta. En una tienda con pedidos recientes, también debe definirse cómo evitar la pérdida de operaciones durante una eventual restauración.

Las pruebas posteriores dependen del negocio. 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 contemplar el acceso a productos, variantes, carrito y recorrido de compra en un entorno autorizado. Un cobro real requiere una decisión separada.

También conviene comprobar formularios, mensajes de error, operaciones del panel y procesos que guarden información. Un mensaje de éxito no demuestra necesariamente que una consulta haya llegado al buzón correspondiente. El registro debería describir qué se observó, con dominio y fecha, en lugar de limitarse a indicar que el formulario fue revisado.

Por qué el parche también importa para la continuidad digital

Instalar una actualización de PHP no garantiza mejores posiciones en Google. Sí forma parte del mantenimiento necesario para conservar una web operativa. Un incidente podría introducir contenido ajeno, modificar enlaces, generar redirecciones o dejar páginas inaccesibles, con consecuencias para usuarios y operaciones digitales.

Si la infraestructura utiliza un firewall de aplicaciones web, el proveedor puede confirmar si existen protecciones aplicables y si cubren el tráfico correspondiente. Esa capa no reemplaza la actualización del intérprete. Tampoco conviene cambiar parámetros de memoria, carga de archivos o sesiones sin evaluación técnica, porque una mitigación improvisada puede afectar la disponibilidad o el funcionamiento del sitio.

La tarea queda correctamente documentada cuando cada instalación tiene una versión identificada, un responsable, una respuesta del proveedor y una prueba funcional posterior. Para una empresa, esa evidencia permite distinguir entre una actualización realmente aplicada y una respuesta general sobre el servidor.