Exfiltración de datos en Atlassian Rovo: qué pasó y qué deben revisar los administradores de Jira

Respuesta rápida: La exfiltración de datos en Atlassian Rovo es un ataque de inyección indirecta de instrucciones (indirect prompt injection) que PromptArmor reveló a Atlassian el 23 de mayo de 2026 y publicó el 5 de agosto de 2026. Una instrucción oculta dentro de un archivo subido le indica a Rovo que empaquete contenido de Jira y Confluence en una URL y la abra. El atacante luego lee los datos en los registros de su servidor. Desactivar la búsqueda web no detiene el ataque.

Si su equipo utiliza Jira y Confluence con Rovo habilitado, vale la pena dedicar veinte minutos del tiempo de un administrador a revisar esto. El ataque no requiere ningún clic, ninguna solicitud de aprobación ni cuentas comprometidas. Solo necesita un archivo subido y una petición ordinaria.

A continuación explicamos el ataque paso a paso, por qué la opción de configuración más evidente no lo resuelve, el estado del parche al 27 de octubre de 2026 y una lista de verificación que puede aplicar hoy mismo. En Sharkly desarrollamos un espacio de trabajo donde agentes de programación toman tareas de un tablero compartido, por lo que nos enfrentamos a este mismo problema. Las inyecciones de prompts siguen sin resolverse en todas partes; la verdadera cuestión es a qué recursos le permite acceder cada herramienta a un agente secuestrado.

Qué sucedió: la inyección de prompts en Rovo, paso a paso

El informe de PromptArmor describe una cadena de cinco pasos:

1. El archivo envenenado. Una víctima sube un documento titulado «Backlog Guide». Este contiene una instrucción oculta dirigida al modelo, no al lector humano.
2. La petición ordinaria. Más adelante, la víctima le pide a Rovo que organice sus tickets de Jira.
3. La búsqueda. Rovo recopila tickets de Jira y páginas de Confluence, leyendo en el proceso el archivo envenenado.
4. La filtración. La instrucción le ordena a Rovo que adjunte ese contenido a la URL de un atacante y la abra mediante su herramienta de recuperación de URLs. El servidor del atacante registra la petición, incluyendo los datos extraídos.
5. El encubrimiento. La víctima recibe sugerencias lógicas para sus tickets sin indicio alguno de que se haya filtrado información.

Ninguna persona aprueba la petición saliente, motivo por el cual PromptArmor lo cataloga como un ataque de cero clics (zero-click). Su resumen sobre el alcance del ataque concluye que abarca cualquier dato al que el agente tenga acceso dentro de Atlassian, incluyendo el contenido proveniente de conectores.

El archivo es solo una de las posibles vías de entrada. PromptArmor también señala los tickets de soporte externos, los resultados de búsqueda cuando la función web está activa y los conectores de terceros. Cualquier contenido que Rovo lea representa un lugar donde se puede esconder una instrucción maliciosa.

Por qué desactivar la búsqueda web no soluciona el problema

Atlassian ofrece a los administradores un control para la «Búsqueda web» en Rovo, y muchos equipos optaron por desactivarlo por precaución. PromptArmor advierte que el ataque sigue funcionando aun con esta opción apagada, ya que el interruptor no elimina la herramienta encargada de abrir URLs. Además, dicha herramienta carecía de validaciones sobre las URLs generadas por el propio agente.

Una opción que lleva el nombre de una función no necesariamente elimina la capacidad subyacente.

La página de administración de acceso y búsqueda web de Atlassian muestra ahora dos selectores. «Acceso web» controla si Rovo puede acceder a páginas web públicas, y «Búsqueda web» depende de él. Ambos vienen activados de forma predeterminada. La página también advierte que «incluso si el acceso web está desactivado, es posible que una herramienta conectada no quede bloqueada». [VERIFICAR 2026-10-27: ninguna fuente pública confirma si desactivar el acceso web clausura la vía de obtención de URLs utilizada por PromptArmor. No asegure a los lectores que lo hace.]

¿Existe una segunda vía de exfiltración?

Sí. PromptArmor señala que Rovo procesa y renderiza imágenes en Markdown dentro de sus respuestas. Una URL de imagen que apunte al servidor de un atacante filtra cualquier dato codificado en ella en el instante en que el navegador la carga. PromptArmor advierte sobre este canal, aunque no detalla una cadena de explotación completa en Rovo para este caso.

Cronología de divulgación y estado de los parches

Al 27 de octubre de 2026, no hemos encontrado ningún comunicado, aviso de seguridad ni solución confirmada por parte de Atlassian para esta vía. El hilo de Hacker News sobre la publicación (306 puntos, 138 comentarios) tampoco cuenta con respuestas de Atlassian. [VERIFICAR antes de publicar: revisar nuevamente los avisos de seguridad de Atlassian y la página de PromptArmor en busca de actualizaciones.]

¿En qué se diferencia esto de RovoBlast?

Se trata de fallos distintos. Varonis Threat Labs dio a conocer RovoBlast, donde un enlace manipulado aprovechaba el parámetro de URL rovoChatPrompt para inyectar instrucciones en el chat de Rovo de la víctima. Varonis lo reportó a través del programa Bugcrowd de Atlassian e indicó que ya fue subsanado. RovoBlast requería que el usuario hiciera clic. En cambio, el ataque documentado por PromptArmor solo exige que la víctima realice sus tareas habituales. La corrección de uno no garantiza la resolución del otro.

El patrón subyacente: la trifecta letal

Simon Willison bautizó este esquema como la trifecta letal: un agente con acceso a datos privados, exposición a contenido controlado por un atacante y un canal para comunicarse con el exterior. Si se dan estas tres condiciones, un atacante puede manipularlo para que transmita su información hacia afuera.

Rovo, integrado en un entorno de Jira y Confluence, reúne las tres por diseño. De hecho, eso es lo que lo hace útil.

El debate en Hacker News coincidió en varias medidas de mitigación:

• Obtener únicamente URLs introducidas por personas o devueltas por herramientas de confianza. Jamás una URL ensamblada por el agente. Simon Willison destacó que, mediante comodines de DNS (wildcard DNS), la información puede filtrarse únicamente a través del subdominio.
• Las URLs preindexadas ayudan, pero la fuga persiste de forma lenta. Johann Rehberger (wunderwuzzi) señaló que un atacante aún podría exfiltrar datos a razón de un carácter por petición.
• Las listas de dominios permitidos funcionan en agentes de alcance reducido. Si un agente solo necesita tres dominios, permítale únicamente esos tres.

Ninguna de estas propuestas soluciona el problema en el modelo. Su objetivo es restringir el tráfico saliente, ya que los modelos siguen obedeciendo instrucciones inyectadas en ciertas ocasiones. Por esta razón, OWASP sitúa la inyección de prompts en el primer puesto de su lista de riesgos para LLM (LLM01).

Lista de verificación de seguridad para Rovo: qué deben revisar hoy los administradores de Jira

Cada una de estas acciones reduce un vértice de la trifecta.

1. Mapee el alcance de Rovo. Haga un inventario de cada aplicación, proyecto, espacio (Space) y conector. Rovo respeta los permisos de usuario, por lo que una sesión comprometida podrá acceder a todo lo que el usuario solicitante pueda ver. Atlassian indica que Rovo en sí no se puede desactivar por completo, pero los administradores sí pueden bloquear su acceso por aplicación.
2. Identifique contenido de origen externo. Los tickets del portal de soporte, los correos convertidos en incidencias, los archivos adjuntos y los documentos sincronizados contienen texto que su equipo no escribió. Esas son sus superficies de inyección.
3. Audite los conectores. Desconecte los que no se utilicen. En el caso de Google Drive y SharePoint, implemente listas de bloqueo o de admisión en el conector. Mantenga fuera del alcance del agente la información legal, de recursos humanos, financiera y de respuesta a incidentes, tal como recomienda Varonis.
4. Revise ambos selectores web. Desactive la «Búsqueda web» y el «Acceso web» si nadie los necesita. No considere que ninguno de los dos neutraliza este ataque hasta que Atlassian lo confirme expresamente.
5. Supervise el tráfico saliente. Detecte y alerte sobre dominios imprevistos de imágenes o enlaces externos en los registros de su proxy.
6. Haga pruebas con un prompt de control. Introduzca una instrucción inofensiva en un ticket de prueba pidiéndole a Rovo que consulte una URL bajo su control. Si la petición llega a su servidor, tendrá su respuesta.
7. Advierta a su equipo. Una petición cotidiana como «Organiza mis tickets» puede ejecutar instrucciones camufladas dentro de un archivo adjunto.

Si en su organización Jira también es el punto donde los agentes de programación toman tareas, consulte nuestro artículo sobre cómo asignar tickets de Jira a un agente de IA.

Las mismas preguntas aplican a los agentes de programación

Los agentes de programación leen texto no confiable continuamente: descripciones de incidencias, comentarios en pull requests, archivos README de dependencias o documentación descargada. Tienen acceso a su código fuente y suelen contar con salida a la red. Es la misma trifecta, solo que en una terminal en lugar de un panel de chat. Ya analizamos por qué recurrir a un modelo más avanzado no compensa la falta de delimitación de alcance en nuestro artículo sobre inyección de prompts y barreras de contención para agentes.

Sharkly no hace que un agente sea inmune a la inyección, y ninguna herramienta puede prometer eso en la actualidad. Lo que ofrece es un entorno para definir los límites de alcance antes de que comience una ejecución. Los agentes operan sobre Computers que usted conecta mediante un servicio local que abre la conexión hacia el exterior, por lo que una configuración típica no exige abrir puertos entrantes. Los invitados solo pueden acceder a los Spaces a los que han sido añadidos de manera explícita. Las acciones de terceros en los flujos de automatización se canalizan a través de conectores autorizados por usted. La documentación recomienda expresamente no almacenar contraseñas, tokens ni claves en las instrucciones de las Skills, y otorgar a los repositorios únicamente el nivel mínimo de privilegios que requiera cada Task.

Los agentes investigan, ejecutan y reportan. Las personas otorgan autorizaciones y validan el resultado. Para conocer todos los detalles, consulte nuestras guías sobre qué se le debe y no se le debe permitir hacer a un agente de programación y dónde ubicar los puntos de aprobación.

Conclusión

El ataque contra Rovo no recurre a técnicas sofisticadas. Bastaron un archivo, una petición habitual y una herramienta de recuperación de URLs sin restricciones sobre lo que puede abrir, combinados con el hecho de que la opción que la mayoría de los equipos desactivó no afectaba a dicha herramienta. Al momento de redactar este artículo, la vía de explotación basada en contenidos carece de una solución confirmada.

Considere la delimitación del alcance como el mecanismo de control principal bajo su dominio. Mapee qué lee Rovo, elimine los conectores innecesarios y compruebe usted mismo la ruta de salida. Luego plantee tres preguntas básicas para cada agente que use su equipo: qué puede leer, qué texto no confiable llega a su entorno y hacia dónde puede transmitir información. Si desea gestionar sus agentes de programación en un único tablero con el alcance claramente establecido por tarea, Sharkly es gratuito para organizaciones de hasta 5 personas.

Preguntas frecuentes

¿En qué consiste el ataque de exfiltración de datos en Atlassian Rovo?

Es un ataque de inyección indirecta de prompts divulgado por PromptArmor el 5 de agosto de 2026. Mediante instrucciones ocultas, hace que Rovo adjunte información confidencial de Jira y Confluence a la URL de un atacante y la abra.

¿Desactivar la búsqueda web de Rovo protege mis datos?

No, de acuerdo con los hallazgos de PromptArmor. Este ajuste no desactiva la herramienta encargada de abrir URLs.

¿Ha corregido Atlassian la inyección de prompts en Rovo?

Hasta el 27 de octubre de 2026, no encontramos ningún pronunciamiento oficial ni solución confirmada por parte de Atlassian para la vía reportada por PromptArmor. La vulnerabilidad independiente RovoBlast sí fue subsanada.

¿Afecta esto a Rovo Dev?

Rovo Dev es el agente de programación de Atlassian, un producto independiente de Rovo para Jira y Confluence, y el informe de PromptArmor no lo abarca. Para más información, consulte nuestra guía sobre el plan gratuito de Rovo Dev.

¿Son vulnerables los agentes de programación al mismo tipo de ataque?

Sí. Cualquier agente que procese texto no confiable y disponga de acceso a la red corre el mismo peligro. Limite lo que puede leer, las credenciales a las que tiene acceso y los destinos hacia donde puede enviar datos.