Qué falla exactamente
- CVE-2026-109618: si PHP se queda sin memoria a mitad de una operación, deja datos a medio inicializar y la limpieza posterior los trata como válidos.
- CVE-2026-109619: un proceso de PHP puede reutilizar estado de una petición anterior cuya memoria ya fue liberada.
Ninguna de las dos requiere credenciales: por eso el puntaje alto. La primera necesita condiciones de memoria; la segunda depende de cómo el servidor reutiliza procesos, algo habitual en PHP-FPM.
Por qué importa en un WordPress
WordPress corre sobre PHP, y la mayoría de los sitios WordPress en hosting compartido usan PHP-FPM con procesos que se reutilizan entre visitas. Un WordPress actualizado, con plugins al día y contraseñas robustas, sigue expuesto si el PHP del servidor está en una versión afectada: el navegador no ve esa capa y el panel de WordPress tampoco.
Es importante no mezclar causas. Un sitio WordPress con problemas puede deberse a un plugin vulnerable, a credenciales filtradas, a un tema abandonado o al PHP del servidor. Son incidentes distintos con correcciones distintas.
Cómo comprobar qué PHP atiende tu sitio
- Mira la versión que atiende la web, no solo la de consola:
php -vy, si usas FPM,php-fpm -v. - En un panel como cPanel o Plesk, revisa el selector de versión de PHP del dominio: ahí está la versión real que ejecuta WordPress.
- En Debian o Ubuntu:
apt list --installed 2>/dev/null | grep -i php. En RHEL y derivados:rpm -qa | grep -i php. - Si tu distribución aplica parches sin cambiar el número de versión, revisa el aviso de seguridad de la distribución para esa falla antes de concluir que estás expuesto.
- Revisa si tienes varios PHP instalados: CLI, FPM y binarios incluidos en aplicaciones o paneles.
Si quieres una comprobación rápida desde el propio WordPress, mira la versión de PHP que informa Escritorio → Salud del sitio → Información, y contrástala con el selector del hosting. Si el panel dice una cosa y el sitio informa otra, manda la del sitio.
Cómo corregirlo
PHP indica que no hay mitigación completa y que actualizar es la única opción segura. Si instalas con el gestor de paquetes del sistema, aplica la actualización del proveedor; si compilas a mano, pasa a una de las versiones corregidas.
En un WordPress el orden razonable es:
- Respaldo del sitio y de la base de datos, y verificación de que el respaldo se puede restaurar.
- Actualizar PHP en el panel del hosting (o por el gestor de paquetes).
- Revisar que el sitio carga, que el formulario de contacto envía y que no aparecen avisos de plugins incompatibles.
- Revisar registros desde el 14 de octubre por si hubo exposición antes del parche.
Si no puedes actualizar ahora
- PHP 8.1 o anterior: no hay versión corregida del proyecto en esas ramas. Pregunta a tu distribución si ofrece parche propio o planifica la migración a 8.2 o superior.
- Medidas temporales reportadas: fijar
memory_limit=-1a nivel de administrador y combinarlo con límites de peticiones en el frontal y límites de memoria en el contenedor para la primera falla. Son paliativos, no sustituyen el parche. - Varias agencias recomendaron desconectar los sistemas PHP expuestos hasta actualizarlos. En un sitio productivo eso es una decisión de negocio, no técnica: conviene evaluarla con el responsable del servicio.
Señales de compromiso que conviene vigilar
- Procesos hijos inesperados bajo los procesos de PHP o del servidor web.
- Archivos nuevos en directorios de subida o en rutas que no corresponden a un plugin conocido.
- Reinicios anómalos de procesos y picos de peticiones inusuales desde el 17 de octubre.
- Cuentas administrativas nuevas en WordPress, tareas programadas (cron) que no reconoces y cambios de DNS que nadie autorizó.
Qué hacemos en EXIS
Revisamos el entorno acordado —versión de PHP y componentes, cuentas administrativas, configuración del servidor, respaldos y señales observables— y priorizamos hallazgos por impacto y urgencia. Si el trabajo requiere acceso, se acuerda por escrito un método seguro y temporal.