CVE-2026-21589 en Atlassian Data Center: análisis de riesgos y acciones urgentes

La vulnerabilidad crítica CVE-2026-21589 (CVSS 9.3) en los productos de Atlassian Data Center ya está siendo comprobada de forma dirigida por atacantes: según datos de telemetría, se han registrado al menos 15 intentos de explotación tan solo dos horas después de la publicación de los detalles técnicos, lo que convierte la actualización inmediata y la aislación de las instancias vulnerables de internet en una tarea prioritaria para todas las organizaciones que utilicen despliegues locales de Jira, Confluence, Bitbucket, Bamboo, Crowd y otros sistemas de Atlassian.

Detalles técnicos de CVE-2026-21589

La vulnerabilidad CVE-2026-21589 se clasifica como acceso arbitrario a archivos dentro del directorio raíz de la aplicación web (webroot) sin autenticación. La descripción formal y la información básica pueden encontrarse en la base NVD siguiendo el patrón de CVE: ficha CVE-2026-21589 en NVD.

Se ven afectados los siguientes productos de Atlassian (ediciones Data Center y soluciones servidor relacionadas):

• Bitbucket Data Center: versiones corregidas: 9.4.26, 10.2.8, 10.5.1
• Confluence Data Center: 9.2.26, 10.2.19
• Jira Service Management Data Center: 5.12.40, 10.3.26, 11.3.12
• Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12
• Bamboo Data Center: 10.2.24, 12.1.12
• Crowd Data Center: 6.3.7, 7.0.3, 7.1.7, 7.2.4
• Crucible: 4.9.15
• Fisheye: 4.9.15

Según el proveedor, los productos en la nube Atlassian Cloud ya han sido actualizados.

La clave de la explotación reside en el mecanismo de procesamiento de recursos web de Atlassian. Los investigadores de watchTowr demostraron que la lógica de resolución de rutas transforma cadenas del tipo \"..::..::..::..::WEB-INF::web.xml\" en una ruta relativa estándar \"../../../../WEB-INF/web.xml\". Un análisis técnico detallado está disponible en su publicación: análisis de CVE-2026-21589 de watchTowr.

A continuación, esta característica se combina con el recurso del plugin jQuery colorpicker, ubicado en la ruta /includes/jquery/plugins/colorpicker/images/. Gracias al carácter «/» al final, el atacante puede “escapar” del directorio de imágenes y acceder a otros archivos de la aplicación utilizando una única petición HTTP. Ejemplo de petición para Jira:

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: <Jira-Hostname>

Limitación de la vulnerabilidad: el atacante debe conocer con precisión el nombre del archivo y su ruta; la vulnerabilidad no permite enumerar el contenido de los directorios. No obstante, en una configuración típica, dentro del webroot se encuentran archivos de configuración con credenciales y claves, lo que incrementa drásticamente el nivel de riesgo.

El escenario es especialmente crítico para Crowd y Jira: es accesible el archivo WEB-INF/classes/crowd.properties, que contiene las credenciales de Crowd. Los investigadores muestran que, una vez obtenidos estos datos, un atacante puede lograr acceso administrativo a la aplicación, crear nuevas cuentas y elevar privilegios hasta el nivel Jira Administrator. El material complementario y los ejemplos se presentan en el repositorio de watchTowr: watchTowr vs Atlassian CVE-2026-21589.

Primeros indicios de explotación e IOC

La empresa Previdian, especializada en evaluación proactiva de vulnerabilidades, registró el inicio de ataques contra sus sistemas honeypot dos horas después de la publicación de los detalles técnicos del exploit de watchTowr. Según su telemetría, se registraron 15 intentos de explotación procedentes de tres direcciones IP únicas en Japón y Estados Unidos. Los detalles están disponibles en su informe: telemetría sobre CVE-2026-21589 de Previdian.

Indicadores de compromiso (IOC) destacados:

• 38.60.157[.]86
• 146.70.187[.]234
• 159.26.119[.]225

Estos son indicios tempranos de tráfico de reconocimiento y pruebas. Es importante que el desencadenante principal de la ola de escaneos haya sido la divulgación pública de los detalles técnicos y la disponibilidad de plantillas listas para herramientas de escaneo automatizado (Nuclei). Tras la publicación de la plantilla correspondiente, tal y como advierte Previdian, el escaneo masivo de perímetros externos en busca de esta vulnerabilidad se convertirá en una tarea trivial incluso para atacantes con poca experiencia.

Evaluación del impacto y perfil de riesgo

Las organizaciones más expuestas al riesgo son aquellas que:

• exponen instancias de Jira, Confluence, Bitbucket, Bamboo, Crowd y otros productos Atlassian Data Center directamente a internet;
• utilizan Crowd como punto central de autenticación para otras aplicaciones;
• almacenan dentro del webroot archivos de configuración con contraseñas, claves API y tokens de acceso (incluidos archivos como web.xml, crowd.properties y similares).

Posibles consecuencias de una explotación exitosa:

• Compromiso de credenciales: extracción de contraseñas, tokens y claves de cifrado a partir de archivos de configuración.
• Escalada de privilegios: transición desde acceso no autenticado hasta permisos de administrador de la aplicación de Atlassian gracias a los datos de Crowd robados.
• Interferencia profunda en los procesos de negocio: creación de cuentas administrativas ocultas, modificación de permisos de usuarios, manipulación de colas de tareas, repositorios de código y pipelines de build.
• Compromiso en cadena: uso de las credenciales obtenidas para acceder a otros sistemas integrados con Atlassian (CI/CD, service desk, sistema de autenticación).

Desde el punto de vista sectorial, existe una sensibilidad especial en aquellas compañías donde Jira y Confluence son elementos críticos de la actividad operativa: proveedores de TI, desarrolladores de software, organizaciones financieras, telecomunicaciones y grandes empresas industriales. Para ellas, la pérdida de integridad o confidencialidad de los datos en el entorno Atlassian impacta directamente en la resiliencia operativa y en el cumplimiento de los requisitos regulatorios.

Recomendaciones prácticas de protección

1. Priorización e instalación de parches

La prioridad recomendada es la actualización inmediata de todas las instancias afectadas a versiones que incluyan la corrección:

• Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1;
• Confluence Data Center: 9.2.26, 10.2.19;
• Jira Service Management Data Center: 5.12.40, 10.3.26, 11.3.12;
• Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12;
• Bamboo Data Center: 10.2.24, 12.1.12;
• Crowd Data Center: 6.3.7, 7.0.3, 7.1.7, 7.2.4;
• Crucible y Fisheye: 4.9.15.

Tiene sentido organizar el orden de actualización empezando por las instancias accesibles públicamente y los sistemas en los que Atlassian está relacionado con la gestión de accesos (Crowd) y el desarrollo (Jira, Bitbucket, Bamboo).

2. Medidas temporales cuando no sea posible actualizar de inmediato

Hasta la instalación de los parches, conviene aplicar todas las medidas temporales recomendadas:

• Retirar la instancia del acceso directo desde internet: ubicarla detrás de una VPN, un proxy o restringir el acceso mediante listas de IP permitidas.
• Configurar reglas en el Web Application Firewall para bloquear peticiones sospechosas hacia recursos /download/resources/…/images/ que contengan secuencias ..:: e intentos de acceso a WEB-INF.
• Utilizar Tomcat RewriteValve (para Confluence, Jira, Jira Service Management, Bamboo, Crowd) para rechazar de forma forzada estos patrones de URL.
• Para Bitbucket: añadir la regla correspondiente en urlrewrite.xml que bloquee los saltos desde rutas de imágenes hacia directorios de sistema.

Incluso después de instalar los parches, tiene sentido mantener parte de estos filtros como capa de protección adicional frente a posibles bypasses futuros.

3. Detección de posibles explotaciones

Pasos recomendados para comprobar si ya se han producido intentos de ataque:

• Analizar los registros de acceso del servidor web y de los proxies inversos en busca de peticiones que contengan:
  • secuencias ..::..:: en la URL;
  • accesos a rutas del tipo /download/resources/*color-picker-popup/images/;
  • menciones a WEB-INF/web.xml, crowd.properties y otros archivos sensibles.
• Revisar los registros en busca de accesos desde las direcciones IP:
  • 38.60.157[.]86
  • 146.70.187[.]234
  • 159.26.119[.]225

  correlacionando posteriormente por hora y contexto de las peticiones.

• Reevaluar los registros de autenticación en Jira y Crowd: aparición de nuevas cuentas administrativas, cambios en los permisos de usuarios existentes en el periodo posterior a la publicación del exploit.

4. Limitación de las consecuencias de la posible filtración de archivos de configuración

Aun en ausencia de indicios claros de explotación, conviene partir de la hipótesis de que los archivos de configuración podrían haberse leído mientras existía la ventana de vulnerabilidad. Mínimos prácticos:

• cambio de contraseñas y claves que pudieran almacenarse en web.xml, crowd.properties y archivos similares;
• revocación y reemisión de tokens utilizados en integraciones con sistemas externos (CI/CD, repositorios de código, sistemas de autenticación);
• verificación de actividad anómala en los sistemas integrados a los que se pudiera haber accedido mediante credenciales comprometidas.

La acción clave para las próximas 24–48 horas es actualizar todas las instancias vulnerables de Atlassian Data Center a versiones corregidas, limitar temporalmente su accesibilidad desde internet y, a continuación, analizar de forma dirigida los registros en busca de peticiones características con ..:: y accesos a WEB-INF, acompañándolo del cambio de todas las credenciales potencialmente accesibles desde los archivos de configuración.