JC Rueda
Ciberseguridad · Aviso

Atlassian Data Center (Jira, Confluence, Bitbucket y otros) · Lectura de archivos sin autenticación, ya explotada

Un fallo en una biblioteca común a ocho productos de Atlassian permite leer archivos internos sin credenciales y, en ciertas configuraciones con Crowd, puede acabar en acceso de administrador a Jira.

Publicado Lectura 8 min Ref. CVE-2026-21589 CVSS 9.3 (Atlassian (fabricante y CNA), CVSS v4.0) Estado Explotación activa

Resumen

La vulnerabilidad CVE-2026-21589 permite a un atacante remoto, sin credenciales, leer archivos concretos de la aplicación web si conoce su nombre y ruta exactos. Atlassian publicó versiones corregidas el 5 de octubre de 2026 y la puntúa con un CVSS v4.0 de 9,3. CISA la añadió el 15 de octubre a su catálogo de vulnerabilidades explotadas, aunque en las fuentes consultadas no constan víctimas concretas. La medida principal es actualizar y comprobar en los registros si hubo accesos anteriores.

Materias: Vulnerabilidades, Path traversal, Atlassian, Gestión de parches, CISA KEV

Si su organización tiene Jira, Confluence, Bitbucket u otro producto de Atlassian instalado en sus propios servidores, este aviso le afecta. Un fallo ya corregido permite a cualquiera que alcance el servidor por red leer ciertos archivos internos sin iniciar sesión. Hay intentos de ataque registrados y CISA, la agencia estadounidense de ciberseguridad, lo da por explotado. Lo que no consta públicamente es cuántas organizaciones han sufrido una intrusión real.

Descripción

Qué es

CVE-2026-21589 es un fallo de acceso arbitrario a archivos: permite obtener archivos que no deberían ser accesibles desde fuera. La descripción oficial solo contempla la lectura, y el vector CVSS de Atlassian no asigna impacto directo sobre la integridad ni sobre la disponibilidad del producto vulnerable.

El registro CVE lo clasifica como path traversal (recorrido de directorios: manipular una ruta para llegar a ubicaciones no previstas). CISA añade CWE-552, la categoría de archivos o directorios accesibles a terceros.

Gravedad

Atlassian lo califica de crítico, con un CVSS v4.0 de 9,3. El CVSS es la escala habitual de gravedad, de 0 a 10. La nota refleja que no hace falta autenticación ni interacción de un usuario, y que el impacto puede extenderse a otros sistemas.

Otras fuentes dan cifras distintas: watchTowr indica 7,5 en su ficha y la plantilla de Nuclei, 9,8 en CVSS 3.1. La referencia de este aviso es la del fabricante.

A quién afecta

Según Atlassian, están afectadas todas las versiones anteriores a las corregidas de Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo y Crowd Data Center, además de Crucible y Fisheye. Rapid7 precisa que esto incluye las versiones sin soporte. Data Center es la modalidad que el cliente instala y administra en su propia infraestructura.

Atlassian Cloud no requiere ninguna acción del cliente: el fabricante indica que ya está corregido y que su investigación no halló indicios de explotación allí.

Mecánica

El fallo

Según el análisis de watchTowr, el origen está en la biblioteca compartida atlassian-plugins-webresource, que sirve recursos web de los complementos (plugins). Su código de enrutado convierte las secuencias :: en separadores de ruta, lo que permite eludir las protecciones habituales y pedir archivos de la propia aplicación sin autenticarse.

Requisitos y límites

  • El atacante necesita acceso de red a la instancia, pero no credenciales.
  • Debe conocer el nombre y la ruta exactos del archivo, porque el fallo no permite listar directorios. Las rutas estándar del producto son, sin embargo, predecibles.
  • Solo se alcanzan archivos de la aplicación web, incluido WEB-INF. watchTowr no logró salir del contexto de Tomcat, el servidor que ejecuta la aplicación.
  • El resultado varía según el producto: en Bitbucket, por ejemplo, web.xml está bloqueado, aunque otros archivos de WEB-INF son accesibles.

El escenario más grave: integración con Crowd

Crowd es el producto de Atlassian para gestionar usuarios e inicios de sesión de forma centralizada. watchTowr demostró esta cadena en un Jira integrado con Crowd:

  1. Leyó WEB-INF/classes/crowd.properties, que guarda en texto plano el nombre y la contraseña de la aplicación, así como la dirección de Crowd.
  2. Con esas credenciales se dirigió a la API de Crowd, la interfaz que permite operar con el servicio de forma programática.
  3. Creó un usuario y lo añadió al grupo jira-administrators, lo que le dio privilegios de administrador en Jira.

La cadena no se da en toda instalación. Exige la integración con Crowd y que el atacante pueda llegar a ese servicio. Una lista de IP permitidas en Crowd bloquea el camino directo, aunque watchTowr advierte que podría sortearse desde otra máquina comprometida o con técnicas de tipo SSRF, que hacen que el propio servidor realice la petición.

Qué se sabe de la explotación

  • Confirmado: CVE-2026-21589 figura en el catálogo KEV de CISA desde el 15 de octubre. En ese catálogo, el uso en campañas de ransomware (secuestro de datos) consta como desconocido.
  • Según Previdian: su red de honeypots (sistemas señuelo) registró intentos unas dos horas después del análisis de watchTowr, publicado el 6 de octubre. Security Affairs recoge 15 intentos desde tres IP de Japón y Estados Unidos. Son intentos contra señuelos, no intrusiones en organizaciones reales.
  • Según VulnCheck: añadió el fallo a su propia lista el 7 de octubre tras observar actividad contra Bamboo Data Center.
  • No consta: en las fuentes consultadas no hay víctimas identificadas, cifras de compromisos reales ni autoría atribuida.

El titular sobre la «prueba de concepto» pide un matiz. Help Net Security afirma que watchTowr creó un exploit (código de ataque de demostración) sin publicarlo, y difundió solo un script de comprobación. Rapid7 y el registro CVE, en cambio, sí hablan de exploit o de pruebas de concepto públicas, y existe una plantilla para Nuclei, un escáner automatizado. En cualquier caso, los detalles técnicos públicos bastan para automatizar comprobaciones.

Respuesta del creador

Atlassian

Publicó el aviso y las versiones corregidas el 5 de octubre de 2026, junto con mitigaciones provisionales. Declara que no puede determinar si la instancia de un cliente concreto ha sido comprometida y remite a cada organización a sus propios equipos de seguridad para buscar indicios. La versión del aviso consultada, con última modificación del 5 de octubre, no confirma explotación en Data Center. El fabricante no publica indicadores de compromiso propios, como IP o huellas de archivos.

Según la cronología de watchTowr, Atlassian adjuntó el archivo de mitigación rewrite.config a un ticket público el 2 de octubre, antes del aviso.

Autoridades

  • CISA (EE. UU.): incluyó el fallo en KEV el 15 de octubre, con plazo hasta el 18 de octubre para las agencias federales estadounidenses, y exige además un triaje forense conforme a la directiva BOD 26-04. Esta obligación no vincula a empresas privadas ni a entidades españolas, pero sirve de referencia sobre la prioridad.
  • Centro Canadiense de Ciberseguridad: su aviso AV26-1002, actualizado el 15 de octubre, recoge la explotación según fuentes abiertas y la inclusión en KEV.
  • INCIBE-CERT: no hemos localizado un aviso propio en nuestras búsquedas, lo que no descarta que exista.

La página de NVD no pudo consultarse durante la elaboración de este aviso. Los datos de clasificación proceden del registro CVE, que incluye la información de Atlassian y de CISA.

Parches y mitigaciones

Versiones corregidas

Atlassian no publica parches binarios sueltos: la corrección llega mediante versiones de mantenimiento.

  • Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1
  • Confluence Data Center: 9.2.26, 10.2.19
  • Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12
  • Jira Service Management Data Center: 5.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

Algunas fuentes secundarias presentan pequeñas diferencias en estos números. Ante cualquier duda, prevalece el aviso de Atlassian.

Mitigaciones provisionales

No sustituyen a la actualización. Atlassian recomienda retirar la instancia de Internet hasta poder actuar y, si no se puede actualizar de inmediato, ofrece estas opciones:

  • Cualquier producto afectado: una regla en el WAF (cortafuegos de aplicaciones web) o en el proxy que bloquee las URL con .. junto a /, \ o ::, también en sus variantes codificadas. Debe probarse antes de su despliegue.
  • Confluence, Jira, Jira Service Management, Bamboo y Crowd: activar RewriteValve de Tomcat y añadir las reglas de denegación en rewrite.config, en todos los nodos del clúster y con reinicio.
  • Bitbucket: añadir la regla indicada al inicio de urlrewrite.xml, en todos los nodos y réplicas (mirrors), y reiniciar.

Los patrones exactos deben copiarse del aviso del fabricante.

Qué hacer ya

  1. Inventariar las instancias propias y comprobar su versión y si son accesibles desde Internet.
  2. Actualizar fuera del ciclo habitual de parches. Si no es posible, restringir el acceso externo y aplicar las mitigaciones.
  3. Revisar los registros de acceso, también tras actualizar: decodificar cada URL hasta dos veces y buscar .. junto a /, \ o ::, o aplicar directamente la expresión de búsqueda de Atlassian. Si se revisa de forma retroactiva, conviene hacerlo como mínimo desde antes del 5 de octubre.
  4. Rotar credenciales y secretos si hay indicios de acceso a archivos de configuración, en especial a crowd.properties, y revisar en Crowd los usuarios creados y los cambios en grupos de administradores.
  5. Reforzar Crowd con una lista de IP permitidas y limitar por red quién puede alcanzarlo.
  6. Bloquear IP conocidas como medida secundaria: Previdian señaló 38.60.157.86, 146.70.187.234 y 159.26.119.225. Son datos de principios de octubre y pueden haber quedado obsoletos, por lo que este bloqueo no sustituye a la actualización.

Vertiente jurídica

Un intento registrado no equivale por sí solo a una brecha. Si la investigación concluye que se accedió a datos personales, por ejemplo mediante una cuenta de administrador obtenida a través de Crowd, el responsable del tratamiento debe valorar la notificación a la AEPD en 72 horas (art. 33 RGPD) y la comunicación a los afectados si el riesgo para ellos es alto (art. 34 RGPD). Conviene documentar la revisión y sus conclusiones aunque no se detecte intrusión. Las entidades sujetas a normativa sectorial o de ciberseguridad deben comprobar además sus propias obligaciones de notificación.

Fuentes