Los investigadores de ciberseguridad han revelado un «punto ciego» de seguridad en la plataforma Vertex AI de Google Cloud que podría permitir que un atacante utilice agentes de inteligencia artificial (IA) para obtener acceso no autorizado a datos confidenciales y comprometer el entorno de nube de una organización.

Según la Unidad 42 de Palo Alto Networks, el problema se relaciona con cómo se puede hacer un mal uso del modelo de permisos de Vertex AI aprovechando la agente de servicioEl alcance excesivo del permiso de forma predeterminada.

«Un agente mal configurado o comprometido puede convertirse en un ‘agente doble’ que parece cumplir su propósito previsto, mientras extrae secretamente datos confidenciales, compromete la infraestructura y crea puertas traseras en los sistemas más críticos de una organización», dijo el investigador de la Unidad 42, Ofir Shaty. dicho en un informe compartido con The Hacker News.

Específicamente, la empresa de ciberseguridad descubrió que el agente de servicio por proyecto y por producto (P4SA) asociado con un agente de IA implementado creado con el kit de desarrollo de agentes de Vertex AI (ADK) tenía permisos excesivos otorgados de forma predeterminada. Esto abrió la puerta a un escenario en el que los permisos predeterminados de P4SA podrían usarse para extraer las credenciales de un agente de servicio y realizar acciones en su nombre.

Después de implementar el agente Vertex a través de Motor de agentecualquier llamada al agente invoca el servicio de metadatos de Google y expone las credenciales del agente de servicio, junto con el proyecto de Google Cloud Platform (GCP) que aloja al agente de IA, la identidad del agente de IA y los alcances de la máquina que aloja al agente de IA.

La Unidad 42 dijo que pudo usar las credenciales robadas para saltar del contexto de ejecución del agente de IA al proyecto del cliente, socavando efectivamente las garantías de aislamiento y permitiendo el acceso de lectura sin restricciones a todos los datos de los depósitos de Google Cloud Storage dentro de ese proyecto.

«Este nivel de acceso constituye un riesgo de seguridad significativo, transformando al agente de IA de una herramienta útil a una potencial amenaza interna», añadió.

Eso no es todo. Con el Vertex AI Agent Engine implementado ejecutándose dentro de un proyecto de inquilino administrado por Google, las credenciales extraídas también otorgaron acceso a los depósitos de Google Cloud Storage dentro del inquilino, ofreciendo más detalles sobre la infraestructura interna de la plataforma. Sin embargo, se descubrió que las credenciales carecían de los permisos necesarios para acceder a los depósitos expuestos.

Para empeorar las cosas, las mismas credenciales del agente de servicio P4SA también permitieron el acceso a repositorios restringidos de Artifact Registry propiedad de Google que se revelaron durante la implementación de Agent Engine. Un atacante podría aprovechar este comportamiento para descargar imágenes de contenedores de repositorios privados que constituyen el núcleo de Vertex AI Reasoning Engine.

Es más, las credenciales de P4SA comprometidas no solo permitieron descargar imágenes que aparecían en los registros durante la implementación de Agent Engine, sino que también expusieron el contenido de los repositorios de Artifact Registry, incluidas varias otras imágenes restringidas.

«Obtener acceso a este código propietario no sólo expone la propiedad intelectual de Google, sino que también proporciona al atacante un modelo para encontrar más vulnerabilidades», explicó la Unidad 42.

«El Artifact Registry mal configurado resalta una falla adicional en la gestión del control de acceso para la infraestructura crítica. Un atacante podría potencialmente aprovechar esta visibilidad no intencionada para mapear la cadena de suministro de software interna de Google, identificar imágenes obsoletas o vulnerables y planificar futuros ataques».

Google desde entonces actualizó su documentación oficial para explicar claramente cómo Vertex AI utiliza los recursos, las cuentas y los agentes. El gigante tecnológico también recomendó que los clientes utilicen Traiga su propia cuenta de servicio (BYOSA) para reemplazar al agente de servicio predeterminado y hacer cumplir el principio de privilegio mínimo (PoLP) para garantizar que el agente tenga solo los permisos que necesita para realizar la tarea en cuestión.

«Otorgar a los agentes permisos amplios de forma predeterminada viola el principio de privilegio mínimo y es una falla de seguridad peligrosa por diseño», dijo Shaty. «Las organizaciones deben tratar la implementación de agentes de IA con el mismo rigor que el nuevo código de producción. Validar los límites de permisos, restringir los alcances de OAuth al mínimo privilegio, revisar la integridad de la fuente y realizar pruebas de seguridad controladas antes del lanzamiento de la producción».

Salesforce ha advertido sobre un aumento en la actividad de los actores de amenazas que tiene como objetivo explotar configuraciones erróneas en sitios de Experience Cloud de acceso público mediante el uso de una versión personalizada de una herramienta de código abierto llamada AuraInspector.

La actividad, según la empresa, implica la explotación de los derechos de los clientes. Configuraciones de usuarios invitados de Experience Cloud demasiado permisivas para obtener acceso a datos sensibles.

«La evidencia indica que el actor de la amenaza está aprovechando una versión modificada de la herramienta de código abierto AuraInspector. […] para realizar escaneos masivos de sitios públicos de Experience Cloud», Salesforce dicho.

«Si bien el AuraInspector original se limita a identificar objetos vulnerables al sondear los puntos finales API que estos sitios exponen (específicamente el punto final /s/sfsites/aura), el actor ha desarrollado una versión personalizada de la herramienta capaz de ir más allá de la identificación para extraer datos, explotando configuraciones de usuario invitado demasiado permisivas».

AuraInspector se refiere a una herramienta de código abierto diseñada para ayudar a los equipos de seguridad a identificar y auditar configuraciones incorrectas del control de acceso dentro del marco de Salesforce Aura. Fue lanzado por Mandiant, propiedad de Google, en enero de 2026.

Los sitios de Salesforce de acceso público utilizan un perfil de usuario invitado dedicado que permite a un usuario no autenticado acceder a páginas de destino, preguntas frecuentes y artículos de conocimiento. Sin embargo, si este perfil está mal configurado con permisos excesivos, potencialmente puede otorgar a usuarios no autenticados acceso a más datos de los previstos.

Como resultado, un atacante podría aprovechar esta debilidad de seguridad para consultar directamente objetos de Salesforce CRM sin iniciar sesión. Para que este ataque funcione, los clientes de Experience Cloud deben cumplir dos condiciones: están utilizando el perfil de usuario invitado y no han cumplido con la guía de configuración recomendada de Salesforce.

«En este momento, no hemos identificado ninguna vulnerabilidad inherente a la plataforma Salesforce asociada con esta actividad», Salesforce dicho. «Estos intentos se centran en las configuraciones del cliente que, si no se protegen adecuadamente, pueden aumentar la exposición».

La compañía atribuyó la campaña a un conocido grupo de actores de amenazas sin mencionar su nombre, lo que plantea la posibilidad de que pueda ser obra de ShinyHunters (también conocido como UNC6240), que tiene un historial de atacar entornos de Salesforce a través de aplicaciones de terceros de Salesloft y Gainsight.

Salesforce recomienda a los clientes revisar la configuración de sus usuarios invitados de Experience Cloud, asegurarse de que el acceso externo predeterminado para todos los objetos esté configurado en Privado, deshabilitar el acceso de los usuarios invitados a las API públicas, restringir la configuración de visibilidad para evitar que los usuarios invitados enumeren a los miembros internos de la organización, deshabilitar el registro automático si no es necesario y monitorear los registros para consultas inusuales.

«Esta actividad de los actores de amenazas refleja una tendencia más amplia de ‘basado en la identidad‘ segmentación», añadió. «Los datos recopilados en estos escaneos, como nombres y números de teléfono, a menudo se utilizan para crear campañas de seguimiento de ingeniería social dirigidas y ‘vishing’ (phishing de voz)».

Una nueva investigación ha descubierto que se podría abusar de las claves API de Google Cloud, generalmente designadas como identificadores de proyecto con fines de facturación, para autenticarse en puntos finales sensibles de Gemini y acceder a datos privados.

Los hallazgos provienen de Truffle Security, que descubrió casi 3.000 claves API de Google (identificadas por el prefijo «AIza») incrustadas en el código del lado del cliente para proporcionar servicios relacionados con Google, como mapas incrustados en sitios web.

«Con una clave válida, un atacante puede acceder a los archivos cargados, a los datos almacenados en caché y cargar el uso de LLM a su cuenta», dijo el investigador de seguridad Joe Leon. dichoañadiendo las claves «ahora también se autentican en Gemini aunque nunca fueron destinadas a ello».

El problema ocurre cuando los usuarios habilitan la API de Gemini en un proyecto de Google Cloud (es decir, API de lenguaje generativo), lo que hace que las claves de API existentes en ese proyecto, incluidas aquellas a las que se puede acceder a través del código JavaScript del sitio web, obtengan acceso subrepticio a los puntos finales de Gemini sin ninguna advertencia o aviso.

Esto permite efectivamente que cualquier atacante que raspe sitios web obtenga dichas claves API y las utilice con fines nefastos y robo de cuotas, incluido el acceso a archivos confidenciales a través de los puntos finales /files y /cachedContents, así como realizar llamadas a la API Gemini, acumulando enormes facturas para las víctimas.

Además, Truffle Security descubrió que la creación de una nueva clave API en Google Cloud tiene como valor predeterminado «Sin restricciones», lo que significa que es aplicable para todas las API habilitadas en el proyecto, incluido Gemini.

«El resultado: miles de claves API que se implementaron como tokens de facturación benignos ahora son credenciales de Gemini activas en la Internet pública», dijo Leon. En total, la compañía dijo que encontró 2.863 claves activas accesibles en la Internet pública, incluido un sitio web asociado con Google.

La divulgación se produce cuando Quokka publicó un informe similar, en el que encontró más de 35.000 claves API únicas de Google integradas en su análisis de 250.000 aplicaciones de Android.

«Más allá del posible abuso de costos a través de solicitudes automatizadas de LLM, las organizaciones también deben considerar cómo los puntos finales habilitados para IA podrían interactuar con mensajes, contenido generado o servicios en la nube conectados de manera que amplíen el radio de explosión de una clave comprometida», dijo la empresa de seguridad móvil. dicho.

«Incluso si no se puede acceder a datos directos del cliente, la combinación de acceso a inferencia, consumo de cuotas y posible integración con recursos más amplios de Google Cloud crea un perfil de riesgo que es materialmente diferente del modelo de identificador de facturación original en el que confiaron los desarrolladores».

Aunque inicialmente se consideró que el comportamiento era intencionado, desde entonces Google intervino para solucionar el problema.

«Somos conscientes de este informe y hemos trabajado con los investigadores para abordar el problema», dijo un portavoz de Google a The Hacker News por correo electrónico. «Proteger los datos y la infraestructura de nuestros usuarios es nuestra principal prioridad. Ya hemos implementado medidas proactivas para detectar y bloquear claves API filtradas que intentan acceder a la API de Gemini».

Actualmente no se sabe si este problema alguna vez fue explotado en la naturaleza. Sin embargo, en un publicación en Reddit publicado hace dos días, un usuario afirmó que una clave API de Google Cloud «robada» resultó en cargos de $82,314.44 entre el 11 y el 12 de febrero de 2026, frente a un gasto regular de $180 por mes.

Nos comunicamos con Google para obtener más comentarios y actualizaremos la historia si recibimos una respuesta.

Se recomienda a los usuarios que hayan configurado proyectos de Google Cloud que verifiquen sus API y servicios, y verifiquen si las API relacionadas con la inteligencia artificial (IA) están habilitadas. Si están habilitadas y son de acceso público (ya sea en JavaScript del lado del cliente o registradas en un repositorio público), asegúrese de que las claves estén rotadas.

«Empiece primero con las claves más antiguas», dijo Truffle Security. «Es más probable que se hayan implementado públicamente bajo la antigua guía de que las claves API se pueden compartir de forma segura y luego obtuvieron privilegios de Gemini de manera retroactiva cuando alguien de su equipo habilitó la API».

«Este es un gran ejemplo de cómo el riesgo es dinámico y cómo las API pueden tener permisos excesivos después del hecho», dijo Tim Erlin, estratega de seguridad de Wallarm, en un comunicado. «Las pruebas de seguridad, el escaneo de vulnerabilidades y otras evaluaciones deben ser continuas».

«Las API son complicadas en particular porque los cambios en sus operaciones o los datos a los que pueden acceder no son necesariamente vulnerabilidades, pero pueden aumentar directamente el riesgo. La adopción de IA que se ejecuta en estas API y su uso solo acelera el problema. Encontrar vulnerabilidades no es suficiente para las API. Las organizaciones tienen que perfilar el comportamiento y el acceso a los datos, identificar anomalías y bloquear activamente la actividad maliciosa».