Fallo RCE sin clic en cuatro agentes de IA: 925 plugins secuestrados
Una vulnerabilidad sin interacción del usuario afecta a cuatro agentes de codificación con IA a través de la cadena de suministro de plugins. Debajo del incidente late el problema de las credenciales permanentes.
El jueves se hicieron públicos los detalles de una vulnerabilidad de ejecución remota de código sin clic que afecta a cuatro agentes de codificación con IA de uso mayoritario. La cadena de ataque entra por la cadena de suministro de plugins, y los informes hablan de 925 plugins secuestrados, con dos fabricantes que todavía no han publicado parche. La cifra sale de esos informes, no de una confirmación de los afectados.
Debajo del titular hay un detalle más silencioso. Cada uno de esos plugins sostenía una credencial permanente en algún sistema, esperando a que alguien la pidiera. El atacante no tuvo que emitir acceso nuevo: ya estaba ahí, válido a todas horas.
El contexto ayuda a leerlo. Dos días antes, el estudio de Exabeam situaba a los agentes de IA que operan con acceso excesivo, comprometido o no previsto como la mayor amenaza para su organización según el 48% de los responsables de seguridad consultados. Por delante de los atacantes externos y de la amenaza interna.
El problema no es la clave, sino que no caduque
A un agente se le entrega una credencial que no expira porque la alternativa parece inoperable. Sus tareas son impredecibles y no siempre se puede acotar el permiso cuando no sabes qué va a tocar. Depurar es más cómodo si el agente lo ve todo. Y como la credencial funciona igual para un script que para un agente, nadie construyó un segundo sistema.
El problema es que esa credencial también funciona a las tres de la mañana de un sábado, en manos de una inyección de prompt y sin nadie mirando. Una persona con permisos de administrador permanentes al menos se va a casa. Un agente con esos permisos está en casa todo el tiempo, y también quien averigüe cómo hablarle.
Permisos por tarea y con fecha de caducidad
Piensa en un agente de conciliación. Cada noche cruza 40.000 recibos de gasto contra 40.000 apuntes contables. Necesita lectura sobre el bucket de recibos y escritura sobre una única tabla de resultados, entre las 2:00 y las 4:00, hora de la costa este. Ese es el permiso: no todo el almacén de datos, no indefinido, no heredable por la siguiente tarea que decida coger.
El sujeto del permiso es la instancia del agente, no la clase. Una ejecución concreta recibe su credencial y esta muere con ella, así que un prompt comprometido no alcanza la siguiente. Sin comodines, sin roles heredados. El permiso va atado a un identificador de tarea y marcado como no transferible: si el agente delega una subtarea en otro agente, ese otro pide su propio permiso al motor de políticas. Las credenciales no se pasan de mano en mano como un pase de pasillo.
Ese motor hace lo que ya hace el sistema de solicitudes de acceso para personas: comprueba quién pide, para qué y por cuánto tiempo, y lo registra. La diferencia es la latencia, porque la comprobación tiene que resolverse en milisegundos, al arrancar cada tarea. Eso implica políticas como código, evaluadas en local y con la decisión escrita en un log.
Los tiempos de vida cortos hacen la mayor parte del trabajo. Un exploit sin clic que aterriza en un agente con un permiso de quince minutos para leer un bucket de recibos encuentra poco que robar. El mismo exploit en un agente con una cuenta de servicio permanente encuentra todo lo que esa cuenta haya acumulado nunca.
Queda por ver cuándo llegan los parches de los dos fabricantes que aún no los han publicado, y si las credenciales permanentes que sostienen buena parte de los agentes en producción siguen pareciendo una decisión de una tarde.
