Qué cambian los conectores de IA de WordPress 7.0 para la seguridad
WordPress 7.0 añadió una pantalla Connectors donde los proveedores de IA se configuran para todo el sitio, y ese único cambio coloca las claves de API en el centro de tu modelo de amenazas. Antes de la 7.0, una integración de IA solía ser el problema privado de un solo complemento. Ahora la plataforma ofrece un lugar compartido para guardar las credenciales de los proveedores, varios alojamientos han empezado a configurarlo de forma automática, y una clave almacenada vale dinero real en el momento en que se filtra. Si gestionas o mantienes sitios WordPress, la tarea práctica para las próximas semanas es pequeña pero concreta: averigua qué está configurado en esa pantalla, restríngelo y vigílalo.
Esto no es un texto catastrofista. WordPress 7.0 es una versión sensata, y centralizar la configuración de IA es un diseño razonable. El riesgo no está en la funcionalidad, sino en la brecha entre la rapidez con que se lanzó la funcionalidad y la lentitud con que se adapta la mayoría de las rutinas de mantenimiento. Los sitios que se van a quemar serán aquellos en los que nadie decidió poner una clave en la pantalla Connectors, un alojamiento lo hizo por ellos, y nadie se dio cuenta hasta que llegó la factura del proveedor.
El modelo de amenazas se ha desplazado de verdad
La gente de seguridad habla del “retorno para el atacante” porque eso predice hacia dónde va el esfuerzo. Durante casi toda la historia de WordPress, un sitio comprometido daba retorno de forma indirecta: inyectar enlaces de spam, ocultar páginas de farmacia, servir malware, explotar el tráfico. Todo eso exige que el atacante haga más trabajo después de la intrusión para convertir el acceso en dinero.
Una clave de proveedor de IA almacenada cortocircuita eso. El CEO de Patchstack, Oliver Sild, advirtió que WordPress 7.0 podría desencadenar una “carrera absoluta” por robar claves de API de IA, y lo dijo sin rodeos: “el retorno de hackear WordPress acaba de cambiar”. Esa frase es el artículo entero en ocho palabras. Una clave en la pantalla Connectors es un instrumento de facturación. Un atacante que la exfiltra no necesita monetizar tu tráfico, reempaquetar malware ni esperar a que los motores de búsqueda indexen páginas inyectadas. Apunta la clave al proveedor, ejecuta inferencia a gran escala, y tú lo descubres en la factura. El desfase entre el compromiso y la consecuencia se reduce a horas.
Una lectura de operador con experiencia: este es el mismo cambio por el que la industria ya pasó con las credenciales de la nube. Cuando las claves de AWS empezaron a filtrarse en repositorios públicos de GitHub hace una década, los scrapers automatizados aprendieron a encontrarlas y a levantar flotas de minería de criptomonedas en minutos. El patrón es idéntico aquí, solo que la superficie es ahora una pantalla de administración de WordPress en lugar de un fichero .env en un repositorio. Trata la pantalla Connectors con la misma paranoia con la que tratarías un secreto subido al código, porque, en términos funcionales, eso es exactamente: una credencial de larga duración y alto valor en una aplicación expuesta a internet que es, estadísticamente, el CMS más atacado del planeta.
Hay un efecto de segundo orden que conviene nombrar. El robo de credenciales es silencioso. Una página de inicio desfigurada es evidente y se arregla en una hora. Una clave que se abusa a un ritmo lento y deliberado, justo por debajo del límite de tasa que hayas fijado, puede funcionar durante semanas. El incentivo del atacante es quedarse por debajo de tu atención, no hacer ruido. Eso cambia lo que tiene que significar “monitorización”.
Cuando tu alojamiento instala el complemento de IA por ti
La versión más aguda de este problema en 2026 no son los atacantes, son los alojamientos bienintencionados. SiteGround distribuyó su complemento AI Agent por toda su red de alojamiento y lo preconfiguró como conector de IA predeterminado en la pantalla Connectors de WordPress 7.0. Según se informa, el complemento superó el millón de instalaciones activas, el tipo de cifra de distribución al que solo se llega instalando software en los sitios de la gente por ellos, en lugar de esperar a que lo elijan.
La reacción en los foros de soporte de WordPress.org fue inmediata y contundente. El dueño de una agencia escribió: “Hoy mismo he descubierto que instalasteis automáticamente este posible escenario de pesadilla en todos los sitios de nuestros clientes. Esto no es aceptable”. El desarrollador Rhys Wynne calificó el enfoque de “icky” (repugnante). Hubo un informe de que el complemento causaba errores de CORS en un sitio WooCommerce, exactamente el tipo de cambio de comportamiento no anunciado que rompe el flujo de pago de una tienda en el peor momento posible.
La postura de SiteGround no es descabellada a primera vista. Dima Peteva, de SiteGround, defendió el despliegue como una decisión deliberada y más intervencionista: bajar la barrera de entrada para que clientes no técnicos puedan usar IA sin configurar los conectores ellos mismos. Ahí hay un argumento de producto real. La mayoría de quienes compran alojamiento compartido no leen los registros de cambios, y “simplemente funciona” es una funcionalidad.
La lectura experimentada es que la intención no cambia las cuentas de la seguridad. Desde el punto de vista del propietario del sitio, un conector instalado automáticamente y preconfigurado es un trozo de código no auditado con alcance elevado que no elegiste y por el que no puedes responder. “Más intervencionista” es otra forma de decir “tomamos una decisión con relevancia de seguridad en tu nombre”. Para un blog personal, bien. Para la tienda WooCommerce de un cliente bajo contrato de mantenimiento, es un fallo de control de cambios: algo con capacidad de llamar a servicios externos e incurrir en costes apareció en el sitio sin un ticket, una revisión o tu visto bueno. El informe de CORS en WooCommerce es el canario en la mina. La próxima sorpresa quizá no sea tan inofensiva como un error de consola.
Sea cual sea el razonamiento de tu alojamiento, tu obligación con el sitio no cambia. Se audita lo que hay.
Qué auditar en la pantalla Connectors
Abre la pantalla Connectors en cada sitio del que eres responsable y responde a estas preguntas por orden. No des por sentado que la respuesta es “nada configurado”, sobre todo en alojamiento gestionado.
Primero, qué está conectado y quién lo conectó. ¿Hay algún proveedor configurado? ¿Lo pusiste tú, un compañero o el alojamiento? Si no puedes explicarlo, trátalo como hostil hasta que se demuestre lo contrario. Un conector que no creaste está en la misma categoría de riesgo que una cuenta de administrador que no creaste.
Segundo, qué complemento es dueño del conector. La pantalla Connectors es la superficie de configuración, pero suele ser un complemento el que media las llamadas. Identifícalo, comprueba el autor, la fecha de la última actualización, el número de instalaciones activas y los hilos de soporte. Si lo instaló un alojamiento, busca el anuncio, o la ausencia de él.
Tercero, qué puede hacer la clave. Esta es la parte que la mayoría se salta. Una clave de proveedor rara vez es ya “todo o nada”. La mayoría de los grandes proveedores de IA emiten claves limitadas y restringidas, con límites de gasto por clave, listas de modelos permitidos y topes de uso. Si la clave de tu pantalla Connectors es una clave de organización con acceso total y sin techo de presupuesto, ese es el hallazgo. El radio de impacto de una filtración es todo lo que la clave tiene permitido hacer, multiplicado por todo lo que tiene permitido gastar.
Cuarto, dónde se almacena la clave y cómo se transmite. ¿Está en la base de datos en texto plano, en una opción que un complemento vulnerable podría leer, o referenciada desde una variable de entorno o un gestor de secretos? El texto plano en wp_options es el peor caso común, porque cualquier inyección SQL o filtración de copia de seguridad entrega la clave directamente al atacante.
Quinto, con qué habla el conector. ¿El tráfico va directo al proveedor indicado, o se enruta primero a través del propio endpoint del proveedor del complemento? Un conector que hace de proxy de tus prompts y respuestas a través de un tercero es una decisión de tratamiento de datos, no solo de seguridad, y pesa más si el sitio procesa algo personal.
Privilegio mínimo, presupuestos limitados y rotación
Una vez que sabes qué hay en la pantalla, el trabajo de fortalecimiento es la misma disciplina que ya aplicas a cualquier credencial, adaptada a claves que facturan por token.
Emite la clave más estrecha que necesite la integración. Si el conector solo resume contenidos, no necesita una clave capaz de afinar modelos o acceder a toda tu organización en el proveedor. Crea una clave dedicada para el sitio WordPress, nunca reutilices una clave que también ejecuta el resto de tus herramientas, y limítala a los modelos y capacidades concretos en uso.
Pon un presupuesto rígido a la clave, no solo una alerta. Los límites blandos te notifican después del gasto; los topes rígidos lo detienen. Fija un techo que cubra con holgura el uso legítimo y nada más. Si una clave que debería costar una pequeña cantidad mensual de repente alcanza su tope un martes por la tarde, el tope contiene el daño y se convierte en tu alarma más temprana. Esta única medida convierte “perdimos una cantidad de cuatro cifras antes de darnos cuenta” en “la integración dejó de funcionar y lo investigamos”.
Rota según un calendario y por eventos. Elige un intervalo de rotación fijo y respétalo. Rota de inmediato en cualquiera de estos casos: la salida de un miembro del equipo o colaborador, una sospecha de compromiso, una copia de seguridad que sale de tu control, o un cambio iniciado por el alojamiento que no autorizaste. Cualquier clave que haya aparecido durante una instalación automática es no fiable por defecto; rótala a una que tú hayas creado y controles antes de confiar en ella.
Separa los entornos. El staging y el desarrollo nunca deberían compartir una clave de producción. Una clave de staging filtrada desde una máquina de pruebas menos protegida no debería poder gastar contra tu cuenta de producción en el proveedor.
Decide de forma deliberada si la IA debe estar siquiera en el sitio. La pantalla Connectors de WordPress 7.0 es de adhesión voluntaria para los proveedores que configures. Si un sitio no necesita IA a nivel de sitio, la configuración más segura es una pantalla vacía. Elimina cualquier conector preconfigurado que haya añadido un alojamiento, para que ninguna credencial activa quede sin usar, porque una clave sin usar es puro perjuicio: puede filtrarse pero no produce ningún valor.
Revisar lo que instaló tu alojamiento y mantener el resto parcheado
El episodio de SiteGround recuerda que tu inventario de complementos ya no está del todo bajo tu control en alojamiento gestionado. Crea el hábito de reconciliar los complementos instalados con lo que realmente elegiste.
Lleva un registro, aunque sea sencillo, de los complementos que se supone que debe ejecutar cada sitio y por qué. En tu próxima pasada de mantenimiento, compara la realidad con esa lista. Todo lo que no puedas explicar recibe la misma auditoría que un conector desconocido: quién lo instaló, hasta dónde puede llegar, si sigue siendo necesario. En alojamientos que instalan software de forma automática, comprueba en el panel si hay un ajuste que desactive o limite los cambios iniciados por el alojamiento, y actívalo donde la plataforma lo ofrezca.
Nada de esto sustituye la disciplina habitual de parcheo, que la conversación sobre IA tiende a eclipsar. La misma semana en que se desarrollaba el debate sobre los conectores de IA, Advanced Custom Fields 6.8.2 salió como una versión de seguridad que parcheaba dos vulnerabilidades en los formularios de frontend de ACF, instando a los usuarios a actualizar de inmediato. ACF está en una enorme proporción de sitios profesionales, y esa es la realidad poco glamorosa y recurrente de la seguridad en WordPress: una cadencia constante de parches de complementos que tienes que aplicar deprisa. Las claves de IA son el nuevo objetivo de alto valor, pero las viejas vías de ataque, los complementos vulnerables, siguen siendo la forma más habitual de que el atacante entre para llegar a ellas. Una clave limitada y con presupuesto detrás de un complemento de formularios sin parchear sigue expuesta. Ambos trabajos tienen que ocurrir.
Monitorización concebida para el abuso silencioso
Como el robo de credenciales es silencioso, tu monitorización tiene que buscar patrones de ausencia de ruido, no solo fallos ruidosos.
Vigila el uso del lado del proveedor, no solo los registros del lado del sitio. La mayoría de los proveedores exponen paneles o APIs de uso por clave. Un cambio repentino en el volumen de peticiones, un giro en los modelos que se están llamando, o tráfico a horas en que tu sitio suele estar inactivo son todos señales. Si gestionas muchos sitios, un pequeño script que extraiga el uso por clave a diario y señale anomalías se amortiza a sí mismo la primera vez que detecta una filtración.
Alerta cuando el tope del presupuesto se esté acercando, no solo cuando se alcance. Llegar al 70 por ciento de un tope mensual el día 3 del mes es algo que merece una mirada humana. Mantén activo el registro de auditoría de WordPress, para que la creación, modificación o cambio de clave de un conector quede registrado con marca de tiempo y usuario, que es también como reconstruyes los eventos tras un cambio iniciado por el alojamiento. Y revisa la pantalla Connectors como punto fijo en cada ciclo de mantenimiento, del mismo modo que revisas usuarios y actualizaciones pendientes. La pantalla es lo bastante nueva como para no figurar aún en la mayoría de las listas de comprobación, que es precisamente la razón por la que merece añadirse.
Lista de comprobación de fortalecimiento
| Comprobación | Por qué importa | Acción |
|---|---|---|
| Inventariar la pantalla Connectors | Un conector que no creaste es el mismo riesgo que una cuenta de administrador que no creaste | Enumera cada proveedor configurado en cada sitio; señala como no fiable todo lo inexplicado |
| Identificar el complemento propietario | La pantalla es configuración; un complemento media las llamadas y arrastra sus propias vulnerabilidades | Registra autor, última actualización, número de instalaciones y si lo instaló un alojamiento |
| Limitar la clave | Una clave de acceso total y sin tope vuelve catastrófica una filtración | Emite una clave dedicada y limitada por capacidades por sitio, nunca reutilizada entre herramientas |
| Fijar un tope de presupuesto rígido | Un tope rígido detiene el abuso; una alerta solo lo reporta después del gasto | Fija un techo justo por encima del uso legítimo; el tope es también tu alarma más temprana |
| Comprobar el almacenamiento de la clave | El texto plano en la base de datos lo entrega cualquier filtración SQL o robo de copia de seguridad | Prefiere variables de entorno o un gestor de secretos antes que opciones en texto plano |
| Rotar las claves | Las claves de larga duración amplían la ventana de cualquier filtración pasada | Rota según un calendario fijo y en salidas, sospecha de compromiso o cambios del alojamiento |
| Separar los entornos | Una clave de staging filtrada no debería facturar a tu cuenta de producción | Usa claves distintas para producción, staging y desarrollo |
| Auditar complementos instalados por el alojamiento | Los alojamientos gestionados pueden añadir software con alcance elevado sin tu visto bueno | Compara los complementos instalados con tu lista prevista; desactiva la instalación automática donde sea posible |
| Parchear con cadencia | Los complementos vulnerables siguen siendo la vía de entrada habitual para llegar a las claves almacenadas | Aplica las versiones de seguridad deprisa; trata los avisos del tipo ACF como trabajo del mismo día |
| Monitorizar el uso del lado del proveedor | El abuso de credenciales es deliberadamente silencioso y se queda por debajo de las alarmas del lado del sitio | Vigila el uso por clave y el tráfico fuera de horas; alerta cuando el tope del presupuesto se acerca |
La conclusión del operador con experiencia
La pantalla Connectors de WordPress 7.0 es una buena funcionalidad lanzada a un ecosistema que aún no ha terminado de adaptarse a ella. La tecnología está bien. La exposición viene de dos factores humanos: las claves que facturan por token están ahora en el CMS más atacado de internet, y algunos alojamientos decidieron configurarlas para los clientes sin preguntar. Oliver Sild tiene razón en que el retorno del atacante cambió, y los hilos del foro de SiteGround muestran que el fallo de control de cambios ya es real, no teórico.
La solución no es exótica. Es la misma disciplina de privilegio mínimo, presupuesto limitado, rotación y monitorización que los buenos operadores aplican a cualquier otra credencial, más un nuevo hábito: abrir la pantalla Connectors en cada sitio que tocas y decidir, de forma deliberada, qué debe estar ahí. Si prefieres entregar esa disciplina a un equipo que lo hace como rutina permanente, nuestro trabajo de mantenimiento y soporte técnico de WordPress está construido precisamente en torno a este tipo de auditoría recurrente, y si estás definiendo el alcance de una integración a medida o WooCommerce que usa conectores de IA, un desarrollador de WordPress debería conectar las claves con privilegio mínimo desde el primer día. El precio del fortalecimiento y el mantenimiento es siempre individual, porque el alcance adecuado depende de cuántos sitios gestiones y de lo que realmente hagan.
Los conectores ya están aquí. Decide qué hay en ellos antes de que lo haga otra persona.
