Sí, vas bien encaminado: el fallo está en PHP. Tu WordPress puede tener el core y los plugins actualizados y seguir expuesto si el intérprete que ejecuta la web no tiene el parche. Pero cambiar de versión en el selector del hosting tampoco demuestra, por sí solo, que ya esté corregido.
Te cuento cómo lo abordé, porque en SYSDOP nos pasamos dos días interviniendo servidores con esto y, para completar la jornada, se nos sumaron los avisos de Node.js y Java. Fueron incidencias distintas, cada una con su revisión; tener WordPress no significa que también estés usando esos otros runtimes.
Lo primero fue identificar qué PHP ejecutaba realmente cada dominio. En un mismo servidor puedes tener varias ramas, FPM, LiteSpeed y versiones privadas que utiliza el propio panel. El «php -v» de la consola puede mostrarte una versión distinta de la que sirve tu web. Por eso comprobé el handler, el binario y el paquete correspondiente a cada caso, en lugar de dar por cubierto el servidor con una sola consulta.
Ahí apareció una trampa importante: algunos proveedores incorporaron el arreglo conservando la versión base de PHP. En CloudLinux, por ejemplo, tuve que comprobar la revisión del paquete y su changelog para confirmar los CVE-2026-109618 y CVE-2026-109619. Ver un número aparentemente antiguo no demostraba que faltara el parche; tampoco bastaba con que el panel dijera «actualizado».
Mientras llegaban los paquetes a los distintos repositorios apliqué medidas temporales y revisé las reglas del WAF. Pero desactivar el progreso de subida de sesiones o bloquear una forma conocida del ataque solo reducía exposición: no lo traté como sustituto del parche.
El propio aviso de PHP aclara que no hay una mitigación completa:
https://www.php.net/archive/2026.php#2026-10-21-5
Por ejemplo, estas fueron las directivas temporales.
La segunda es únicamente para PHP 8.5; no corresponde copiarla a las ramas anteriores:
INI:
session.upload_progress.enabled = Off
; Solo en PHP 8.5
fatal_error_backtraces = Off
Tienen que quedar en el php.ini que carga ese PHP, o en su configuración de servidor/pool antes de procesar las peticiones. Ponerlas en ini_set() dentro de WordPress llega tarde; tampoco sirve confiar en .user.ini con FPM para este caso. Después hay que reiniciar todos los workers afectados y comprobar los valores efectivos. Desactivar el progreso de subida también puede afectar a las aplicaciones que utilizan esa función.
Después de actualizar comprobé los procesos que seguían atendiendo peticiones. Un paquete nuevo en disco puede convivir con procesos que todavía tienen cargado el binario anterior. Tocaba renovar los procesos correspondientes y verificar otra vez. Con Node.js me encontré precisamente ese problema, además de instalaciones por usuario y contenedores con su propio runtime. Con Java también había que revisar qué JVM utilizaba cada servicio y su ruta de arranque; actualizar el Java de la consola no resolvía automáticamente todas las aplicaciones.
La parte forense la trabajé aparte del parcheo. Revisé registros de acceso y del WAF, errores y caídas de procesos, archivos modificados, tareas programadas y accesos persistentes. Hubo intentos bloqueados, pero una petición marcada como sospechosa no demuestra por sí sola que entraran. Incluso una respuesta 200 exigía mirar qué se había servido y cruzarlo con los demás registros. En lo revisado no encontré evidencia de explotación exitosa; eso describe el alcance de aquella revisión, no una garantía absoluta.
En tu WordPress añadiría la comparación de archivos del core con sus checksums oficiales, la revisión de plugins y temas según su procedencia, administradores y contraseñas de aplicación desconocidos, y PHP inesperado en uploads. Todo eso necesita contexto: un archivo reciente puede ser una actualización legítima, y encontrar una cadena sospechosa dentro de las firmas de Wordfence no convierte ese archivo en una puerta trasera. Un escaneo ayuda, pero no certifica por sí solo que esté limpio.
Si tienes SSH y WP-CLI, desde la carpeta de WordPress puedes empezar por estas consultas, con el usuario de la cuenta:
Bash:
wp core verify-checksums --include-root
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_registered
La primera compara el core y avisa de elementos adicionales en la raíz; la segunda contrasta los plugins para los que WordPress.org ofrece checksums; la tercera lista administradores para revisarlos. Un plugin comercial puede no tener checksums allí, y un aviso de archivo adicional no significa automáticamente malware. Ninguna de esas tres consultas revisa por sí sola todo el servidor.
Si estás en hosting compartido, yo empezaría pidiendo una confirmación concreta: que el PHP que ejecuta tu dominio tiene ambos CVE corregidos, qué paquete o compilación lo acredita y que se renovaron los procesos que lo usan. No necesitas saltar a otra rama mayor si tu proveedor ha parcheado la actual; si está fuera de soporte y no dispone de ese arreglo, entonces hay que planificar la migración comprobando compatibilidad.
Y si aparecen indicios de intrusión, antes de borrar o restaurar conservaría los registros y una copia del estado afectado. Restaurar sin corregir la entrada puede dejarte en el mismo punto, y cambiar contraseñas mientras sigue una puerta trasera tampoco cierra el caso. También comparé los sitios y servicios antes y después de los cambios: había que corregir la vulnerabilidad y comprobar que las webs siguieran funcionando.
