Alerta de seguridad en Rovo de Atlassian revela vectores de exfiltración de datos de usuarios autenticados por URL y contenido cargado

Dos equipos de seguridad independientes describieron en julio y agosto de 2026 formas distintas en que Rovo —el asistente de IA integrado en productos de Atlassian— puede ser inducido a extraer datos a los que un usuario autenticado ya tiene acceso y enviarlos a un servidor externo controlado por un atacante. El hallazgo confirmado y cerrado por Atlassian involucra una cadena que se activaba desde un parámetro de URL (rovoChatPrompt); otro, publicado por una firma diferente, describe una inyección de instrucciones ocultas dentro de contenido que Rovo procesa y cuyo estado de remediación no fue confirmado públicamente por el fabricante al momento de las comunicaciones originales.

Hechos confirmados: Varonis Threat Labs reportó que un parámetro de URL (rovoChatPrompt) podía precargar instrucciones maliciosas en Rovo Chat de modo que un usuario autenticado que haga clic en un enlace ejecute esas instrucciones con sus privilegios y el asistente exfiltre datos; ese informe fue divulgado a través de Bugcrowd, y el registro de Bugcrowd indica que Atlassian desplegó un arreglo server‑side el 8 de julio de 2026 y que el investigador validó la corrección. Por separado, PromptArmor publicó el 5 de agosto de 2026 una prueba de concepto en la que un archivo subido con instrucciones ocultas provocaba que Rovo buscara contenido interno y abriera una URL externa con esos resultados, sin una aprobación adicional explícita por parte del usuario. La corrección del vector basado en enlace está confirmada; el estado de la cadena basada en contenido fue descrito por su descubridor como no resuelto cuando la publicó. Además, las búsquedas públicas en bases de datos de vulnerabilidades indicadas por los propios investigadores (por ejemplo, NVD y el catálogo de CISA) no mostraban identificadores o entradas asociadas a estas fallas al 8 de agosto de 2026 (NVD, CISA KEV).

Cómo funcionan técnicamente las cadenas descritas: Rovo actúa con los permisos del usuario autenticado y puede consultar Jira, Confluence y conectores externos según la configuración y alcances autorizados. En la variante detectada por Varonis, un parámetro de URL preinyecta un prompt completo en la sesión de Rovo; con un solo clic de un usuario autenticado, el asistente ejecuta esas instrucciones, recopila información accesible para el usuario (por ejemplo, tickets o páginas) y la incorpora en la ruta de una imagen o una petición que Rovo obtiene —esa solicitud llega al servidor atacante donde queda registrada. En la variante publicada por PromptArmor, el atacante insertó instrucciones dentro de un archivo cargado por el usuario; Rovo trató parte del contenido del archivo como directivas y realizó búsquedas internas y una petición saliente a una URL construida con los resultados. En ambos casos no se demuestra una elevación de privilegios: lo que sale es lo que el usuario autenticado ya podía ver, pero sin que el usuario haya aprobado conscientemente la exfiltración.

Qué implica esto y a quién afecta: la principal repercusión es exfiltración de datos a los que un usuario legítimo tiene acceso sin que ese usuario haya iniciado explícitamente la transferencia. No se trata de un bypass de permisos a nivel tenant que permita ver información fuera del alcance normal del usuario, sino de un nuevo vector por el que datos autorizados pueden salir de la organización. En organizaciones donde Rovo está habilitado por defecto (documentado por Atlassian para planes Standard, Premium y Enterprise) cualquier persona con acceso a esas funciones podría, inadvertidamente, activar una de estas cadenas. El riesgo es mayor en entornos con conectores amplios (SharePoint, Outlook, API keys en Confluence, etc.), en los que un único usuario puede consultar datos sensibles.

Qué está confirmado y qué no: confirmado está que la cadena vía parámetro de URL fue reportada, corregida por Atlassian y validada por el investigador; confirmado también está que PromptArmor publicó una prueba de concepto y afirmó que su método funcionó aún con la opción de “web search” desactivada en Rovo. No confirmado está si Atlassian aplicó cambios adicionales posteriores al 5 de agosto que mitiguen la ruta descrita por PromptArmor; tampoco hay, en las divulgaciones públicas originales, evidencia de explotación real en entornos de clientes. Tampoco había, al 8 de agosto, entradas públicas en NVD o el catálogo de CISA asociadas a estas cadenas.

Medidas concretas que deberían tomar administradores y usuarios inmediatemente: 1) Revisar qué apps y grupos tienen habilitado Rovo: en organizaciones con controles de administración, limitar Rovo a los grupos estrictamente necesarios y deshabilitarlo en apps que no requieran inteligencia asistida. 2) No confiar únicamente en el toggle de “web search”: PromptArmor mostró que Rovo puede componer y recuperar URLs de forma distinta; trate ese toggle como una capa, no como una barrera completa. 3) Restringir y auditar conectores: reducir el alcance de conectores (SharePoint, Outlook, otros) y aplicar el principio de menor privilegio en credenciales y API keys. 4) Supervisar ejes de salida y registros de proxy: habilitar logging detallado de salidas HTTP/HTTPS, revisar peticiones salientes generadas por asistentes y buscar patrones de fetch a dominios externos inesperados. 5) Implementar controles de egress y DLP para bloquear o alertar cuando contenido con datos sensibles se envía fuera de dominios permitidos. 6) Rotar credenciales expuestas en pruebas y revisar auditoría de accesos recientes si se sospecha exposición. 7) Consultar el estatus de la mitigación con Atlassian y mantener sistemas actualizados; pida aclaraciones sobre si fixes adicionales se aplicaron al comportamiento de recuperación de URLs compuesto por el agente.

Recomendaciones técnicas adicionales para equipos de seguridad: deshabilitar la renderización automática de imágenes remotas en contenidos generados por la IA cuando sea posible (esto reduce un canal de exfiltración vía URLs de imágenes en Markdown), forzar validación de dominios externos por una lista blanca, y practicar pruebas internas de red-team orientadas a inyecciones de prompt contiguas a contenido subido. Para desarrolladores y administradores de identidad, monitorizar atributos de sesión y bloquear acciones que impliquen fetch de recursos externos desde sesiones con scopes elevados sin aprobación explícita.

En resumen: una vulnerabilidad basada en parámetro de URL fue confirmada y corregida por Atlassian; una segunda técnica, de inyección dentro de contenido que el asistente procesa, fue divulgada públicamente y su remediación no estuvo documentada en las comunicaciones originales. La exposición real es la salida de datos que el usuario ya puede ver, no una escalada de privilegios por defecto, pero eso no reduce la urgencia: en entornos donde los asistentes IA están integrados con múltiples fuentes internas, la capacidad de un solo usuario de filtrar información silenciada o inadvertida puede ser significativa. Las organizaciones deben actuar sobre configuración, permisos, registro y egress para mitigar el riesgo mientras esperan aclaraciones y parches definitivos del proveedor.