Seguridad WordPress: el aviso de PHP del 21 de octubre y qué revisar en la web de tu negocio

El 21 de octubre de 2026, el equipo de PHP publicó un aviso con un título que no deja dudas: «Critical remote code execution vulnerabilities, update now». Si la web de tu negocio está hecha con WordPress, funciona con PHP, y la seguridad de WordPress depende de que alguien haga esa actualización. Aquí está qué ha pasado, por qué te afecta aunque no sepas qué es PHP y la lista de lo que hay que revisar esta semana.

Qué ha pasado con PHP

PHP es el lenguaje con el que funciona WordPress por dentro. Según W3Techs, lo usa el 69,3% de las webs cuyo lenguaje de servidor se puede identificar (consulta del 22 de octubre de 2026).

El aviso oficial, en php.net, describe dos fallos críticos (CVE-2026-109618 y CVE-2026-109619) que pueden permitir a un atacante ejecutar código en el servidor sin iniciar sesión. Afecta, dice el aviso, a «todas las instalaciones de PHP que sirven peticiones web». La solución es actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35, y el propio equipo de PHP lo resume en una frase: actualizar es la única opción segura.

Hay un detalle que importa más que los números: PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto. Para esta ocasión, el equipo publicó parches mínimos para 7.4, 8.0 y 8.1, pensados para quien compila PHP por su cuenta. Un servidor que nadie toca no se arregla solo.

¿Mi web está afectada?

Si tu web es WordPress, la pregunta no es si usa PHP, sino qué versión y quién la actualiza. Y aquí hay un dato incómodo.

WordPress.org publica qué versión de PHP usan las webs que se conectan a su servicio de actualizaciones. Sumando las versiones que ya no reciben soporte (8.1 y anteriores), salen un 35,8% de las webs WordPress (estadística consultada el 22 de octubre de 2026). Más de una de cada tres. Y la 8.2, que usa otro 23,7%, deja de recibir parches de seguridad el 31 de diciembre de 2026, según el calendario oficial de PHP.

WordPress no es una rareza: W3Techs lo sitúa en el 39,6% de todas las webs. Por eso, cuando falla algo en su base, el problema es de todos a la vez.

No es solo PHP: el verano de wp2shell

En julio de 2026 se publicó una cadena de dos fallos en el propio núcleo de WordPress, bautizada como wp2shell. Según el resumen de INCIBE-CERT (28 de julio de 2026), permitía a un atacante remoto ejecutar código sin autenticarse y sin necesidad de ningún plugin. WordPress publicó las versiones 6.8.6, 6.9.5 y 7.0.2 y activó actualizaciones automáticas forzadas en las instalaciones compatibles.

Aun así, INCIBE recoge que hubo explotación activa contra sitios sin actualizar: instalación de webshells (una puerta trasera para controlar el servidor), creación de usuarios administradores y plugins maliciosos para quedarse dentro. Por eso INCIBE recomendaba no solo actualizar, sino comprobar si ya había habido una intrusión.

Los plugins, el punto débil de siempre

El núcleo de WordPress es lo que más vigilado está. El riesgo de verdad está alrededor. Patchstack, una empresa que se dedica a la seguridad de WordPress, contó 11.334 vulnerabilidades nuevas en 2025, un 42% más que el año anterior. De ellas, el 91% estaba en plugins, el 9% en temas y solo 6 en el núcleo.

Dos cifras del mismo informe explican por qué esto le importa a un negocio pequeño:

• El 46% de las vulnerabilidades no tenía arreglo del desarrollador cuando se hizo pública.
• En las más atacadas, la mediana ponderada hasta el primer ataque masivo fue de 5 horas.

Es decir: aunque actualices, a veces no hay nada que actualizar; y cuando lo hay, el margen se mide en horas, no en semanas. Un formulario de contacto, un slider o un plugin de reservas que nadie revisa desde 2023 es una puerta.

Una aclaración justa: esto no significa que WordPress sea malo. Es una herramienta enorme y muy capaz. El problema es que una web WordPress es un servidor que alguien tiene que mantener, y en muchos negocios ese alguien no existe.

La lista: qué revisar esta semana

Si tienes una web WordPress, hazlo tú o pídeselo a quien te la hizo:

1. Mira tu versión de PHP. En el escritorio de WordPress: Herramientas → Salud del sitio → Información → Servidor. Si pone 8.1 o menos, estás sin soporte.
2. Pregunta a tu hosting si ya han aplicado la actualización del 21 de octubre. Con esta pregunta exacta: «¿Mi servidor tiene ya PHP 8.2.35, 8.3.36, 8.4.27 u 8.5.12, o un parche equivalente de vuestra distribución?».
3. Actualiza WordPress, plugins y temas, en ese orden, después de hacer una copia de seguridad.
4. Borra los plugins y temas que no uses. Desactivado no basta: el código sigue en el servidor.
5. Activa las actualizaciones automáticas de los plugins de confianza (WordPress lo permite desde la versión 5.5, plugin a plugin).
6. Revisa los usuarios administradores. Si hay uno que no reconoces, no lo borres sin más: pide ayuda, porque puede ser señal de intrusión.
7. Comprueba que hay copias de seguridad automáticas y que alguna vez se ha restaurado una.
8. Activa la verificación en dos pasos en tu cuenta de administrador.

Hacerlo tú: el cálculo completo

Rápido y de una vez. Mirar la versión de PHP y escribir al hosting: quince minutos. Hazlo hoy aunque no hagas nada más; es gratis y es la pregunta que más importa esta semana.

Lento, un fin de semana largo. Actualizar todo, borrar lo que sobra, revisar usuarios y probar que la web sigue funcionando después. Si un plugin choca con la versión nueva de PHP, el fin de semana se alarga. Aquí aparece el informático que «te lo mira» o la agencia que cobra el mantenimiento aparte.

Lo que no termina nunca. Con 11.334 vulnerabilidades nuevas en un año, esto no es una tarea: es una costumbre. Cada semana hay actualizaciones, y cada una puede romper algo. Por eso tantas webs de negocio acaban con un plugin de 2022 y una versión de PHP sin soporte: nadie tenía ese rato.

Lo que hacemos nosotros

wiweb no es WordPress ni funciona con PHP. Es una sola página hecha de widgets —horario en vivo, reseñas de Google, servicios y precios, mapa, WhatsApp, reservas con la app que ya uses— que alojamos y mantenemos nosotros. No hay plugins que instalar ni versión de PHP que vigilar, porque no hay nada de eso que tú tengas que tocar.

El fin de semana se queda en nada: el servidor, el certificado de seguridad (que se emite y se renueva solo), la red de distribución y la protección contra ataques de denegación de servicio son cosa nuestra, también en el plan gratis. Cada cambio guarda una copia y se puede deshacer.

Lo que no termina nunca, también: las actualizaciones de la plataforma las hacemos nosotros, para todas las webs a la vez. Tú cambias la tuya escribiendo, como un WhatsApp.

• Free, 0 €: tu página con todos los widgets, publicada en tunegocio.wiweb.me, con textos legales y cookies incluidos. Sin tarjeta y para siempre.
• Grow, 9 €/mes (7,50 €/mes pagando el año, sin IVA): tu propio dominio, sin nuestra marca, blog, tres idiomas, tu ficha de Google desde wiweb y un repaso cada semana de tu web y tu ficha con mejoras que apruebas tú.

Puedes crear tu web gratis y ver qué incluye cada plan en precios. Lo honesto: ningún sistema es invulnerable, el nuestro tampoco. La diferencia es quién tiene que estar pendiente. Y si necesitas una web grande de muchas páginas o una tienda online, WordPress puede ser lo tuyo; entonces, que alguien la mantenga de verdad.

Preguntas frecuentes

¿Cómo sé qué versión de PHP usa mi web?

Si es WordPress, en Herramientas → Salud del sitio → Información → Servidor. Si no tienes acceso, pregúntalo al hosting o a quien te hizo la web. Cualquier versión 8.1 o anterior ya no recibe actualizaciones del proyecto PHP.

¿WordPress se actualiza solo?

Las versiones menores del núcleo, normalmente sí. Los plugins y los temas, solo si activas sus actualizaciones automáticas uno a uno. Y la versión de PHP no depende de WordPress, sino del servidor de tu hosting.

¿Qué hago si creo que me han hackeado la web?

No borres nada todavía. Cambia las contraseñas, avisa a tu hosting y pide una revisión. INCIBE tiene una línea gratuita de ayuda en ciberseguridad, el 017, para empresas y ciudadanos.

¿Una web pequeña también es objetivo?

Sí. Los ataques masivos no eligen negocios: buscan instalaciones vulnerables en automático. Una web pequeña sin actualizar es tan visible para un robot como una grande.