Los parches ya existen, pero WordPress aclara que actualizar WordPress no basta, hay que actualizar PHP en el servidor
El miércoles 21 de octubre, el proyecto PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas, identificadas como CVE-2026-109618 y CVE-2026-109619. Según el aviso de PHP, ambas pueden permitir la ejecución remota de código sin autenticación: un atacante podría tomar el control de un servidor sin necesidad de credenciales. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
La BBC informó de que los fallos llevaban años sin detectarse y que salieron a la luz gracias a herramientas de inteligencia artificial utilizadas por investigadores de las empresas Wiz y Calif. El medio también reportó que Wikimedia desactivó sistemas de forma preventiva y que agencias como la NSA y el Centro Nacional de Ciberseguridad del Reino Unido aconsejaron desconectar los sistemas que no puedan parchearse de inmediato.

WordPress.org publicó ese mismo día un aviso firmado por John Blackbourn, del equipo de seguridad. Allí afirma que las vulnerabilidades no son específicas de WordPress y que no se requiere ni está prevista ninguna actualización del sistema. Es decir, actualizar WordPress, el tema o los plugins no corrige el problema: la solución está en la versión de PHP que corre en el servidor. Recomienda consultar con el proveedor de hosting y comprobar la versión en el propio panel.
La situación es más delicada con versiones antiguas. PHP indica que la rama 8.1 y las anteriores ya no reciben actualizaciones oficiales, aunque publicó correcciones mínimas del código fuente para 7.4, 8.0 y 8.1. WordPress aconseja a quienes administran su propio servidor con una versión anterior a la 8.2 que consideren ponerlo fuera de línea mientras actualizan, un consejo que cita del centro de ciberseguridad británico. Además, PHP 8.2 dejará de recibir parches el 31 de diciembre de 2026.

Quien usa hosting gestionado depende de que su proveedor aplique el parche; quien administra su propio servidor debe instalarlo y reiniciar PHP por su cuenta. Tras actualizar, conviene buscar archivos PHP desconocidos o cuentas de administrador que no reconozcas, porque el parche no elimina una intrusión previa.
En resumen, el mensaje de PHP y de WordPress coincide: la acción urgente está en el servidor, no en el panel de WordPress.