Vulnerabilidades de PHP: cómo revisar hoy tu web con WordPress

Las vulnerabilidades de PHP publicadas el 21 de octubre de 2026 obligan a revisar qué versión completa del intérprete ejecuta cada sitio web. El proyecto PHP lanzó las versiones 8.2.35, 8.3.36, 8.4.27 y 8.5.12 para corregir CVE-2026-109618 y CVE-2026-109619, dos fallas calificadas con 9,2 sobre 10 en la escala CVSS. La recomendación oficial es actualizar de inmediato.

Para una empresa de Rosario o de cualquier otra ciudad, la comprobación no termina al ver que la página abre, tiene HTTPS o muestra WordPress actualizado. PHP funciona en otra capa: es el entorno del servidor que ejecuta WordPress, sus temas y sus plugins. Por eso hay que confirmar qué paquete atiende cada dominio y si incorpora ambas correcciones.

La información utilizada en esta nota corresponde al material publicado por DWVisual sobre las vulnerabilidades de PHP de octubre de 2026, con referencia al 22 de octubre de 2026. La consulta no inspecciona servidores ni certifica la seguridad de un sitio.

Qué corrigen las versiones nuevas de PHP

Los avisos del proyecto PHP describen dos problemas vinculados 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.

CVE-2026-109618

La primera vulnerabilidad se relaciona con una corrupción de memoria después del agotamiento de recursos. En determinadas condiciones, PHP puede interrumpir una operación cuando algunos datos todavía no están completamente inicializados. Durante el cierre de la solicitud, el proceso podría utilizar ese estado inválido.

El informe técnico citado en la fuente 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, un control implementado dentro de WordPress podría llegar demasiado tarde.

CVE-2026-109619

La segunda falla consiste en la reutilización de un estado interno obsoleto. Parte de la información de una solicitud puede permanecer en un proceso después de liberar la memoria correspondiente. Una solicitud posterior podría acceder a ese estado antes de su reinicialización.

La consecuencia práctica es concreta: no alcanza con pedir una “actualización de seguridad” en términos generales. El proveedor debe identificar el paquete instalado y confirmar que resuelve los dos identificadores.

Qué sitios y servidores deben entrar en la revisión

El alcance anunciado incluye instalaciones 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 el problema a un plugin específico. En una instalación con WordPress, la revisión debe abarcar cada aplicación que utilice PHP: el sitio principal, una tienda en un subdominio, un entorno de pruebas o una instalación antigua.

Las ramas oficiales corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. En paquetes provistos por una distribución o por un servicio de hosting con mantenimiento extendido, la numeración puede diferir. En ese caso, hay que solicitar el boletín del proveedor y la identificación del paquete que incorpora las correcciones.

Cómo confirmar la versión de PHP en WordPress

En WordPress, la ruta indicada es Herramientas → Salud del sitio → Información → Servidor. Allí se puede consultar la versión de PHP disponible para esa instalación. Registrá el número completo, la fecha de consulta y el dominio correspondiente.

Un panel que sólo informa “PHP 8.3” no permite saber si se trata de una versión corregida. Solicitá al hosting el número completo o el identificador del paquete. Si administrás el servicio mediante cPanel, MultiPHP Manager puede mostrar la configuración asignada a cada dominio cuando el proveedor habilita esa interfaz.

Seleccionar una rama de PHP en un panel tampoco significa necesariamente que todos los parches pendientes se hayan instalado. La confirmación debe incluir el paquete efectivo, la corrección de CVE-2026-109618 y CVE-2026-109619, y la renovación de los procesos que atienden las solicitudes.

Qué evidencia pedir al proveedor de hosting

Una comprobación útil reúne dos datos: la versión observada desde la aplicación y la confirmación del proveedor sobre el paquete corregido. Si ambas referencias no coinciden, la tarea no debería marcarse como terminada.

El pedido puede incluir la versión completa o el identificador del paquete, el boletín aplicable, la fecha de aplicación y el alcance de la intervención. También conviene preguntar si la actualización incluye subdominios, instalaciones separadas y otros servicios que dependan de la misma cuenta de hosting.

Una respuesta como “el servidor está protegido” puede ser insuficiente. Un dato identificable permite saber qué se modificó y facilita futuras revisiones si cambia el proveedor, el equipo de mantenimiento o la infraestructura.

Qué revisar antes y después del parche

Antes de intervenir, el responsable técnico debe confirmar que existe un respaldo legible de los archivos y de la base de datos, y que corresponde 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.

Después de actualizar, las pruebas deben representar el uso real del sitio. En una web institucional se puede comprobar la navegación, la búsqueda y la recepción de una consulta de prueba. En una tienda, conviene revisar productos, variantes, carrito y recorrido de compra en un entorno autorizado. Un cobro real requiere una decisión independiente.

También hay que comprobar formularios, mensajes de éxito y entrega posterior. Que un formulario muestre una confirmación no demuestra que la consulta haya llegado al buzón acordado. Registrá lo observado con precisión y fecha.

Por qué migrar de rama no es lo mismo que aplicar el parche

Actualizar dentro de la rama utilizada atiende esta alerta. Migrar a otra rama de PHP es una decisión distinta, porque exige revisar compatibilidad, extensiones y horizonte de mantenimiento.

Según la información suministrada, el soporte de seguridad de PHP 8.2 termina el 31 de diciembre de 2026. PHP 8.1 y las ramas anteriores ya están fuera del soporte ordinario del proyecto. 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 un proveedor mantiene una rama antigua, pedile que identifique el paquete corregido y el aviso correspondiente, y acordá una migración a una rama soportada. Volver a una versión vulnerable por una incompatibilidad reabre la exposición; cualquier alternativa temporal debe quedar evaluada y documentada por el equipo técnico.

Qué relación tiene el parche con el posicionamiento web

Aplicar una actualización de PHP no garantiza mejores posiciones en Google. Sí forma parte del mantenimiento necesario para conservar una web operativa. Un incidente puede introducir contenido ajeno, modificar enlaces, generar redirecciones o dejar páginas inaccesibles, con consecuencias para la experiencia de usuario y la indexación.

Después de la intervención, revisá que las páginas importantes respondan, que los formularios funcionen y que no hayan cambiado por accidente las señales de indexación. Si se utilizó un entorno de pruebas, verificá que sus restricciones no hayan quedado aplicadas en la web pública.

La prioridad es identificar cada instalación, confirmar el paquete corregido y conservar evidencia de la intervención. Para una empresa, esa trazabilidad permite coordinar al proveedor de hosting con quien mantiene WordPress sin confundir una respuesta sobre un dominio con la seguridad de todo el ecosistema digital.