El 17 de julio de 2026, un investigador de seguridad cogió una instalación de WordPress totalmente limpia. Sin plugins. Sin temas de terceros. La versión estable más reciente, tal cual sale de fábrica.

Le entregó esa copia a un modelo de IA y le pidió que la auditara.

En cuestión de horas tenía una vulnerabilidad crítica de ejecución de código sin necesidad de iniciar sesión, que encadenada con un segundo fallo (hallado por otro equipo de investigadores) permitía tomar el control total del servidor. Una barbaridad, en una instalación de WordPress sin nada que la hiciera vulnerable salvo el propio núcleo.

Al día siguiente, ya había gente explotándolo.

De esto hablé el 8 de septiembre en un webinar con SiteGround y esto es lo que aprendimos.

¿Prefieres leer los puntos clave? Continúa abajo.

El WordPress limpio que cayó por unos pocos dólares

El investigador se llama Adam Kues, de la firma de seguridad Searchlight Cyber, y fue quien encontró la vulnerabilidad de ejecución de código (CVE-2026-63030). El fallo se conoce ahora como WP2Shell, y encadenado con una segunda vulnerabilidad de inyección SQL (CVE-2026-60137, hallada por otro equipo de investigadores) permitía tomar el control total de una instalación de WordPress sin plugins ni temas de por medio.

Encontrar y montar el ataque completo llevó 10 horas y 25 dólares en tokens de IA. Ya no hace falta ser especialista ni pasarse semanas de trabajo: con un poco de tiempo y una inversión ridícula, cualquiera llega al mismo sitio. Llevo más de 20 años trabajando con WordPress, y esta es la primera vez que veo algo así de bruto.

La firma de seguridad Patchstack detectó y reprodujo uno de los dos fallos a los pocos minutos de hacerse público, y publicó cifras que conviene tener en la cabeza: una vulnerabilidad grave tarda de media 5 horas en empezar a explotarse masivamente una vez que se hace pública, no días. Y el 46% de las vulnerabilidades de plugins no tienen parche del desarrollador el mismo día en que se hacen públicas.

Qué ha cambiado en seguridad WordPress (y qué no)

Lo que cambió: la velocidad

Antes, encontrar un fallo así requería a alguien con conocimiento técnico profundo y semanas de trabajo. Ahora, cualquiera con acceso a un modelo de IA y una tarde libre puede llegar al mismo sitio en horas.

Eso cambia una cosa muy concreta: el tiempo que tienes para reaccionar cuando sale un parche de seguridad. Y el matiz que más se pasa por alto es este: el aviso real es el propio parche, no el anuncio que la empresa de seguridad publica en su blog treinta días después.

En el momento en que un desarrollador publica una actualización de seguridad para su plugin, esa actualización ya es pública en WordPress.org. Cualquiera puede comparar el código antes y después y deducir qué agujero estaba tapando, sin esperar a que nadie lo anuncie. Cuanto más tardes tú en actualizar WordPress sin que se rompa nada, más tiempo pasas expuesto.

Lo que no ha cambiado: los fallos de siempre

Aquí va lo que probablemente no esperabas escuchar en un webinar sobre IA y seguridad: los fallos de código siguen siendo exactamente los mismos cuatro de siempre. Nonces (formularios que no comprueban de dónde sale la petición), capacidades (acciones de administrador al alcance de un perfil de suscriptor), escape (salida sin escapar, la puerta de entrada del cross-site scripting) y consultas (SQL montado a mano sin preparar, la inyección de toda la vida).

Como resumo en una de mis diapositivas:

“La IA ha cambiado la velocidad y la escala, no las puertas.”

Y las puertas de entrada tampoco han cambiado: plugins sin actualizar, contraseñas repetidas, administradores de más, y ausencia de copias de seguridad.

Cuando WordPress.org también se defiende: Protect the Shire y Gandalf

En abril de 2026, WordPress sufrió uno de sus peores ataques a la cadena de suministro: alguien compró un lote de 30 plugins gratuitos en Flippa, la plataforma de compraventa de software, y en la siguiente actualización les coló un troyano. Durante ocho meses, ese código funcionó sin que nadie se diera cuenta. Cuando se activó, en 6 horas y 44 minutos ya tenía control administrativo sobre miles de webs. WordPress.org acabó cerrando 31 plugins, que en conjunto sumaban más de 400.000 instalaciones activas.

La respuesta de WordPress.org llegó dos meses después, coincidiendo con WordCamp Europe en Cracovia: Matt Mullenweg anunció Protect the Shire, una iniciativa que impone una ventana de revisión obligatoria antes de que cualquier actualización de plugin o tema llegue a los sitios con actualizaciones automáticas activadas. Esa ventana empezó en 24 horas el 5 de junio y, el 16 de julio, ya se había reducido a solo 6, sin ningún anuncio público: se comunicó en un canal de Slack interno del equipo de plugins.

Durante esas horas, una herramienta de revisión asistida por IA —bautizada como Gandalf, en honor a El Señor de los Anillos— analiza los cambios de código en busca de patrones maliciosos antes de que lleguen a nadie.

Eso no convierte a las actualizaciones automáticas en un riesgo mayor: significa que ahora hay alguien (o algo) revisando el código antes de que te llegue.

Las cuatro capas de seguridad que ya tienes, aunque no lo sepas

Lo resumo en cuatro capas mínimas, y ninguna te protege por sí sola: red, servidor, WordPress y vigilancia. Esta última es distinta a las otras tres: no protege, solo te dice qué ha cambiado y desde cuándo.

Capa 1: la red y la CDN

Parar los ataques lo más lejos posible de tu web, a nivel de red. En SiteGround, la CDN se activa con un clic desde Site Tools, sin tocar servidores de nombres ni DNS. La alternativa es Cloudflare, gratuita, pero requiere cambiar el servidor de nombres. Y en España tiene un problema curioso: cada vez que hay un partido de fútbol importante, el pico de tráfico le tira la web a mucha gente que la usa.

Capa 2: el servidor y el hosting

Aislamiento de cuentas (para que lo que le pase a la web de al lado en un servidor compartido no te afecte), cortafuegos a nivel de servidor con reglas que a veces se adelantan al propio parche del plugin, escaneo diario completo de todos tus archivos, copias de seguridad diarias guardadas en un centro de datos distinto al de tu web, y un escáner antibot gestionado con IA que aprende del tráfico de toda la red de clientes: si alguien más ya sufrió un ataque, tu web se beneficia de esa detección antes de que te toque a ti. Todo esto funciona aunque no hayas entrado nunca en el panel.

Desde Site Tools puedes activar seis ajustes más, gratis: verificación en dos pasos, gestor de claves SSH, control de versión de PHP, entornos de pruebas (staging), copias de seguridad manuales y actualizaciones automáticas seguras. El primero es el que más se olvida, y es la llave maestra de todo lo demás: desde ese panel se cambian contraseñas, se toca la base de datos y se restauran copias.

Capa 3: WordPress y el plugin de seguridad

Aquí entra Security Optimizer, el plugin de seguridad instalado por defecto en SiteGround (y que funciona igual esté tu web en SiteGround o no). Viene configurado con un equilibrio pensado para no romper nada, así que hay ajustes que activaría sin pensarlo: verificación en dos pasos para administradores, límite de intentos de acceso, bloqueo de nombres de usuario comunes, editor de temas y plugins desactivado, protección contra XSS, registro de actividad, y XML-RPC bloqueado si no lo usas.

Para quien quiera ir un paso más allá, desarrollé Vigilante, un plugin más completo con comprobación en listas de spam, registro de actividad completo, auditoría de seguridad permanente, supervisión de integridad de archivos, reglas de contraseñas, cabeceras de seguridad y modo bajo ataque.

Capa 4: la vigilancia, con ayuda de IA

Los clientes de SiteGround tienen acceso a un agente de IA especializado en WordPress, sin necesidad de configurar ninguna clave API, que puede auditar la web entera: analizar carencias de seguridad, recomendar refuerzos, y valorar si los plugins y temas instalados son los adecuados. Como el resto de esta capa, no protege por sí solo: te dice qué ha cambiado y desde cuándo, para que decidas tú qué hacer.

El mito de que pagar por un plugin te hace más seguro

Hay una creencia extendida: los plugins de pago son más seguros porque su código no está expuesto públicamente como el de los gratuitos en WordPress.org. La realidad es la contraria: los plugins de pago tienen el triple de vulnerabilidades con explotación confirmada que los gratuitos, y el 76% de las que se encuentran en componentes de pago son explotables en ataques reales.

¿Por qué? Porque el código de un plugin gratuito del repositorio lo puede leer cualquiera, y de hecho lo hacen: usuarios que le pasan sus propios escáneres, plugins de seguridad, IA buscando fallos. El código de un plugin de pago, en cambio, no lo leía nadie de fuera, hasta ahora: un atacante compra la licencia por 69,99€ y se la pasa directamente a su IA. Cuantos menos ojos revisando un plugin, más tarda en aparecer el fallo, y más tiempo lleva sin corregir cuando por fin se encuentra.

Ojo con lo que le permites hacer a la IA

WordPress ya trae de serie una pantalla de conectores para enlazar agentes de IA (Anthropic, Google, OpenAI y otros) a tu web, y eso trae responsabilidades nuevas que conviene tener en la cabeza:

• Las claves quedan en la base de datos. Si te entran, ya no solo se llevan la web: se llevan también tu clave de API, y te dejan a ti pagando la factura.

• Los agentes heredan los permisos que les des. Un agente al que solo le pides que modere comentarios ya está leyendo texto escrito por cualquiera que pase por tu formulario de contacto.

• Cualquier contenido puede llevar instrucciones escondidas. Comentarios, formularios, feeds importados, descripciones de proveedores: todo eso es texto que tu IA puede leer y, sin querer, obedecer.

Cuento una anécdota que se volvió viral y resume el problema perfectamente: alguien descubrió que podía pedirle al chatbot de atención al cliente de McDonald’s que le enseñara a programar en Python mientras hacía un pedido. El bot, sencillamente, respondía.

¿Por qué funciona esto? Porque nadie le dijo explícitamente que no lo hiciera. La IA hace lo que le dices que haga, y también hace lo que no le digas que no haga. Ojo con eso.

Es la misma lógica que aplica a cualquier agente de IA que conectes a tu WordPress: definir qué puede hacer no es suficiente. Hay que ser igual de explícito sobre qué no puede hacer.

Cinco tareas para ¡ya!

Lo dejo como tarea, y ninguna te llevará más de diez minutos (aquí tienes otras tareas para reforzar la seguridad si quieres seguir después):

1. Activa la verificación en dos pasos en el panel de tu hosting.
2. Quita los administradores que sobran. Si ves a alguien que no reconoces, bórralo.
3. Comprueba que WordPress se actualiza solo. Ahí no hay riesgo de cadena de suministro: es el propio equipo de WordPress.org el que gestiona esas actualizaciones.
4. Crea y restaura una copia de staging. Una copia de seguridad no es real ni está completa hasta que no la has comprobado: crea una web nueva, hazle cualquier cambio y, al día siguiente, restaura la copia para ver si te deja la web como estaba el día anterior.
5. Elimina los plugins que no uses. Cada uno es una puerta más que vigilar.

Y si nada de esto llega a tiempo y crees que ya te han entrado, tengo una guía aparte sobre qué hacer si tu web ha sido hackeada.

El problema nunca es la herramienta:

“Utilizamos un cuchillo para matar a alguien y utilizamos un cuchillo para cortarnos un bocadillo. El problema nunca es la herramienta, es el uso que hagamos de ella. Y también tenemos la herramienta para protegernos.”

Preguntas del webinar

¿Quieres que tu WordPress tenga estas cuatro capas desde el primer día?

Security Optimizer viene instalado por defecto en todos los planes de hosting de SiteGround, junto con CDN de un clic, cortafuegos de servidor, aislamiento de cuentas y copias de seguridad diarias.

Y si prefieres repasar lo básico desde cero, aquí tienes mis 5 sencillos pasos para mejorar la seguridad WordPress.