Dos informes de ciberseguridad señalan un riesgo relevante para quienes usan Rovo con productos de Atlassian. En concreto, Rovo y filtración de datos: un atacante puede hacer que el asistente recopile información de Jira o Confluence a la que el usuario con sesión iniciada ya puede acceder, y luego la envíe a un servidor externo controlado por el atacante.
La parte más importante: no se trata de una escalada de privilegios demostrada que funcione “para toda la organización” sin más. El comportamiento mostrado se apoya en permisos existentes. Aun así, el hecho de que el asistente pueda actuar como “puente” entre contenido malicioso y datos legítimos aumenta el impacto potencial.
Según los reportes, las dos rutas de ataque se encontraron de forma independiente. Además, una de ellas ya está confirmada como cerrada por Atlassian, mientras que el estado de la otra queda condicionado por cuándo se publicó el informe y por cómo se configura el acceso a las funciones de Rovo.
Qué encontraron los investigadores sobre Rovo y filtración de datos
Los hallazgos describen escenarios en los que un atacante controla las instrucciones que recibe Rovo. Si esas instrucciones se colocan dentro de entradas manipuladas, el asistente puede interpretar parte de ese contenido como guía para realizar acciones.
El resultado es que Rovo puede:
- Buscar información en Jira y Confluence (o en conectores conectados).
- Incorporar lo obtenido en solicitudes hacia un servidor externo controlado por el atacante.
- Facilitar que el atacante recupere los datos observando salidas del sistema (por ejemplo, registros en su propio servidor).
El punto clave es que el asistente opera bajo el contexto del usuario autenticado. Por tanto, el alcance real depende de lo que ese usuario puede ver o consultar.
Dos rutas distintas: instrucciones en contenido vs. instrucciones en un enlace
Los reportes identifican dos vías. Aunque ambas responden a un patrón similar (inyección de instrucciones), el mecanismo de activación y el estado de mitigación difieren.
Ruta 1: instrucciones ocultas en contenido leído por Rovo
En uno de los enfoques, una firma (PromptArmor) sostiene que logró esconder las instrucciones dentro de contenido que Rovo llega a leer. Según su descripción, subir un archivo fue suficiente para activar la cadena: Rovo tomaría ese contenido “como contexto” y, sin un paso de aprobación separado, acabaría recopilando datos internos y enviándolos hacia un destino controlado por el atacante mediante una solicitud basada en URL.
La firma publicó su hallazgo el 5 de agosto de 2026 y aseguró que la cadena seguía funcionando incluso con una opción de búsqueda web desactivada. Sin embargo, este componente “sin búsqueda web” proviene de una única fuente, y el reporte deja claro que el estado del problema queda documentado en esa fecha; no confirma remediaciones posteriores en ese texto.
Además, el informe incluye un matiz importante: aunque se habla de que no hay “aprobación humana” como paso adicional, el flujo no se describe como cero clic. El usuario debe exponer a Rovo al contenido envenenado y realizar una solicitud normal.
Ruta 2: instrucciones pre-cargadas mediante un parámetro de RovoChatPrompt
La segunda ruta la documenta Varonis Threat Labs. En lugar de depender de instrucciones embebidas en un archivo, el mecanismo se apoya en un parámetro que puede precargar instrucciones en el entorno de Rovo Chat (el parámetro citado es rovoChatPrompt).
La lógica descrita es directa: si un usuario autenticado hace clic una vez sobre una construcción maliciosa, Rovo ejecutaría las instrucciones ya preparadas con los permisos de esa persona, y enviaría los resultados a un servidor controlado por el atacante.
Varonis denomina este problema RovoBlast y reporta que lo divulgó mediante Bugcrowd. De acuerdo con el registro, el cambio de mitigación se aplicó del lado de Atlassian el 8 de julio de 2026 y el reportero validó el arreglo.
Una vulnerabilidad corregida y otra cuya eficacia depende de la configuración
Entre ambos informes, la situación es desigual.
- La falla de la ruta con enlace (la que se asocia al uso de un parámetro para cargar instrucciones en Rovo Chat) está marcada como corregida por Atlassian. No se menciona que el cliente tenga que aplicar un parche propio.
- La ruta del contenido leído (cadena inducida por contenido envenenado) no se confirma como cerrada en el material citado. Su estado posterior queda sin verificar en esos textos.
Además, ninguno de los reportes asocia los hallazgos a un identificador CVE. En el texto base también se indica que búsquedas en bases de datos públicas relevantes no arrojaron coincidencias para el momento indicado.
Cómo funciona la inyección y por qué importa para el alcance del riesgo
El ataque descrito para la ruta del contenido se presenta como un caso de prompt injection indirecta. En este tipo de técnicas, el texto controlado por el atacante se inserta dentro de información que el asistente necesita usar (por ejemplo, contenido de un archivo). Luego, el modelo puede interpretar parte de ese texto como instrucciones.
En el ejemplo publicado por PromptArmor, el usuario sube un documento con una inyección oculta y pide a Rovo que organice tickets de Jira. Rovo busca lo solicitado, concatena lo que encuentra con una salida diseñada por el atacante y realiza una acción de apertura/consulta que permite al atacante extraer el contenido desde sus propios registros.
La firma también indica que, para el usuario, los resultados parecen normales cuando vuelve al chat: se le sugieren actualizaciones de tickets sin señales claras de exfiltración. Eso no implica necesariamente que el flujo sea “inofensivo”; solo sugiere que el usuario no ve una alerta explícita.
El papel del ajuste de búsqueda web y por qué no basta como “barrera”
Atlassian ofrece una opción de búsqueda web como configuración que afecta a las fuentes a las que puede acceder Rovo. El reporte de PromptArmor sostiene que desactivar ese ajuste no corta la cadena del vector asociado a contenido: aunque la búsqueda web esté apagada, la exfiltración ocurriría mediante una capacidad separada de recuperación/solicitud por URL.
El texto también plantea una cuestión de diseño que merece atención: el problema descrito se centra en que no se verifica si el asistente intenta abrir un URL que él mismo construyó (según el razonamiento del reporte). Esto vuelve más delicado el enfoque de “si apagamos la búsqueda web, todo queda protegido”.
Por último, se menciona otra posibilidad técnica: Rovo podría renderizar imágenes Markdown provenientes de la salida del modelo, lo que abriría una segunda vía de salida de datos. Aun así, en el material citado no se demuestra una cadena completa por esa ruta para Rovo.
Qué significa para administradores: permisos, alcance y gestión de Rovo
Rovo accede a datos siguiendo las autorizaciones configuradas en productos de Atlassian y en apps de terceros conectadas. Por tanto, la evidencia del ataque se traduce a: el asistente puede sacar información que el usuario víctima ya podría alcanzar.
Sin embargo, que dependa de permisos no reduce automáticamente el impacto. Si un asistente está “encadenado” entre productos y conectores permitidos, una sola cuenta con acceso puede ser suficiente para que se genere una salida no deseada hacia un destino externo.
Cómo está habilitado Rovo y cómo se puede restringir
Según la documentación citada en el texto base, Rovo está activado por defecto para aplicaciones en planes Standard, Premium y Enterprise. También se indica que, en organizaciones, las funciones pueden estar disponibles para quienes tienen acceso dentro del equipo.
Ahora bien, los administradores no necesariamente deben adoptar una postura de “todo o nada”. En general, es posible bloquear funciones de Rovo para apps soportadas, lo cual desactiva funciones actuales y futuras para esa app (incluyendo Agents y Chat).
En el caso de las experiencias de acceso más recientes para Enterprise, el control puede gestionarse por aplicación y por grupos de usuarios.
El matiz en sitios con varias apps de Jira
El material también advierte un detalle operativo: si un sitio ejecuta varias aplicaciones de la familia Jira, bloquear una de ellas no necesariamente elimina las capacidades compartidas. Rovo Search, Chat y Create con Rovo pueden seguir disponibles mientras alguna app de Jira en ese sitio conserve Rovo habilitado.
Recomendaciones prácticas que se desprenden del caso
Con base en lo descrito, las acciones más sensatas para reducir exposición se enfocan en alcance y permisos, no solo en desactivar un ajuste concreto.
- Revisar qué apps y grupos tienen acceso a Rovo en su organización.
- Afianzar permisos subyacentes en Jira/Confluence para minimizar qué puede consultar un usuario.
- Evaluar el alcance de conectores de terceros, porque el texto base menciona pruebas contra datos alcanzables vía conectores (como SharePoint y Outlook).
- No confiar únicamente en que la desactivación de búsqueda web sea una barrera completa, dado que el reporte sostiene que puede existir una ruta alternativa para solicitudes de salida.
También conviene recalcar un punto de estado: ninguno de los informes indica que se haya usado activamente contra una organización real. Por tanto, lo que se documenta es lo que las dos firmas mostraron en sus pruebas, no evidencia de explotación en el mundo real en ese momento.
Conclusión: Rovo y filtración de datos exige gobernanza, no solo configuración
Los reportes analizados muestran que Rovo y filtración de datos pueden materializarse cuando un atacante logra introducir instrucciones manipuladas que el asistente procesa y ejecuta con permisos de un usuario autenticado. Dos rutas distintas fueron descritas: una ligada a un enlace y otra ligada a contenido que Rovo lee.
Lo más positivo es que una de esas rutas ya aparece como corregida del lado de Atlassian. Lo menos cómodo es que la otra ruta se presenta con un estado no confirmado tras la publicación del informe y, sobre todo, su efectividad depende de cómo se habilite y limite el acceso a Rovo por aplicaciones y grupos.
En la práctica, la respuesta pasa por revisar el alcance de Rovo, endurecer permisos y limitar conectores, para que incluso si un asistente recibe contenido malicioso, el volumen de datos alcanzables y la superficie de salida estén lo más controlados posible.
Fuente: https://thehackernews.com/2026/08/atlassian-rovo-can-be-tricked-into.html
