Ilustración abstracta de pintura fluida en tonos rojo, naranja y crema para la noticia: CISA confirma ataques al fallo de Atlassian en Jira y Confluence

Vulnerabilidades

CISA confirma ataques al fallo de Atlassian en Jira y Confluence

Atlassian corrige un fallo que permite leer archivos en Jira, Confluence y Bitbucket sin autenticación y CISA lo incluye en el KEV tras los ataques.

Atlassian corrigió el 5 de octubre de 2026 el fallo CVE-2026-21589, un acceso arbitrario a archivos sin autenticación que afecta a ocho de sus productos Data Center, entre ellos Jira, Confluence y Bitbucket. Diez días después, el 15 de octubre, CISA lo añadió a su catálogo de vulnerabilidades explotadas tras confirmarse ataques, con una fecha límite de parcheo para las agencias federales de solo tres días.

Qué ha pasado

El fallo lo divulgó Atlassian en un aviso de seguridad fuera de ciclo el 5 de octubre. Un día después, los investigadores de watchTowr Labs publicaron el análisis técnico completo y una prueba de concepto que convierte una simple lectura de archivo en control total de un Jira. El aviso del fabricante describe el problema en términos escuetos: «allows an unauthenticated attacker to access specific files» (permite a un atacante no autenticado acceder a archivos concretos) dentro del directorio raíz de la aplicación web.

La explotación empezó casi de inmediato. La firma Previdian registró los primeros intentos contra su red de señuelos el 6 de octubre a las 20:52 UTC, menos de dos horas después de que watchTowr publicara su informe. GreyNoise creó el 7 de octubre una etiqueta propia para el patrón de ataque, clasificada como maliciosa. Johannes Ullrich, del SANS Internet Storm Center, también vio el 6 de octubre peticiones de explotación en sus honeypots, procedentes de trece direcciones de DigitalOcean que atribuye a un mismo actor por la coincidencia de tiempos y objetivos.

El 15 de octubre CISA cerró el debate sobre si había explotación real: incorporó CVE-2026-21589 a su catálogo KEV, marcó el requisito de triaje forense y fijó el 18 de octubre como fecha límite para que las agencias federales apliquen las mitigaciones. Antes lo habían hecho los catálogos privados de VulnCheck, que el 7 de octubre observó actividad contra Bamboo Data Center.

Detalles técnicos

Dato

Valor

CVE

CVE-2026-21589

CVSS y vector (Atlassian, CVSS 4.0)

9,3 crítica (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H)

CVSS y vector (NVD, CVSS 3.1)

7,5 alta (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

Tipo

Acceso arbitrario a archivos sin autenticar (CWE-552)

Productos

8 productos Data Center: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible y Fisheye

Versiones afectadas

Todas las anteriores a las corregidas

Versiones corregidas

Confluence 9.2.26 y 10.2.19, Jira 9.12.40, 10.3.26 y 11.3.12, Bitbucket 9.4.26, 10.2.8 y 10.5.1, entre otras

Explotación activa

Sí. En el KEV de CISA desde el 15/10/2026, fecha límite 18/10/2026

Gravedad

Crítica

Hay una diferencia notable entre las puntuaciones. Atlassian, como CNA, califica el fallo con un CVSS 4.0 de 9,3 y vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H, en la banda crítica. El NVD, en cambio, le asigna un CVSS 3.1 de 7,5 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), alta. La brecha nace del nuevo modelo de CVSS 4.0, que puntúa el impacto en sistemas posteriores al vulnerable, algo que el 3.1 no contempla y que aquí pesa mucho, porque el archivo filtrado puede abrir la puerta a otros sistemas.

El origen lo destapó watchTowr diferenciando la versión 6.0.7 de la biblioteca compartida atlassian-plugins-webresource frente a la 6.0.8 ya corregida. Esa biblioteca, presente en los ocho productos, convierte en sus rutas las barras en una secuencia de dos puntos dobles y viceversa. Un método de descarga de recursos construye la ruta del archivo a partir de datos del usuario y la limpia antes de decodificarla, no después. Los controles contra el salto de directorio buscan barras y secuencias clásicas, pero no la codificación con dobles dos puntos, así que la petición escapa del directorio previsto. CrowdSec lo resume así: «The root cause is that the path is cleaned before it is decoded, not after» (la causa es que la ruta se limpia antes de decodificarla, no después).

La cadena de ataque que watchTowr demostró encaja en pocos pasos. La primera petición pide un recurso estático bajo la ruta de los webresources y añade al final la travesía con dobles dos puntos hasta un archivo del directorio WEB-INF. En Jira el objetivo de ejemplo es web.xml, en Bitbucket urlrewrite.xml y en Confluence de nuevo web.xml. El equipo confirmó que no se puede salir del contexto de Tomcat, pero sí leer cualquier archivo dentro de la aplicación: «it is possible to read any file within the application server itself» (es posible leer cualquier archivo dentro del propio servidor de aplicaciones).

Salida del generador de artefactos de detección de watchTowr que marca una instancia de Jira como vulnerable
Fuente: watchTowr Labs, «You Won’t Hear About These, Even In Myths»

El salto de lectura de archivo a administrador depende de la configuración. Cuando Jira se integra con Crowd, el gestor de identidades de Atlassian, el archivo WEB-INF/classes/crowd.properties guarda en texto plano el nombre de la aplicación, su contraseña y la URL del servidor de Crowd. watchTowr leyó ese archivo con el fallo, se autenticó contra la API REST de Crowd con esas credenciales, creó un usuario nuevo y lo metió en el grupo jira-administrators. El resultado es acceso de administrador de Jira a partir de una sola lectura de archivo sin autenticar.

Terminal con la prueba de concepto de watchTowr que lee crowd.properties y crea un usuario administrador en Jira
Fuente: watchTowr Labs, «You Won’t Hear About These, Even In Myths»

Esa escalada tiene freno. Crowd permite restringir por lista blanca de direcciones IP qué equipos hablan con su API, y en ese caso el atacante necesitaría pivotar a través de la propia instancia o abusar de una petición del lado del servidor para alcanzar Crowd. watchTowr advierte de que en Internet conviven despliegues permisivos y despliegues bien cerrados, así que el peor caso es real pero no universal.

Para comprobar si una instancia es vulnerable sin lanzar el ataque completo, watchTowr liberó un generador de artefactos de detección en GitHub que prueba Jira, Confluence y Bitbucket. Existe además una plantilla oficial de Nuclei integrada en el repositorio de ProjectDiscovery, acreditada a sus autores y a watchTowr, que automatiza la comprobación. El código de la prueba de concepto que escala a administrador también es público, lo que explica la velocidad de los primeros intentos.

A quién afecta

A cualquier organización que opere una instancia autoalojada de los ocho productos Data Center por debajo de las versiones corregidas, sobre todo si responde desde Internet. watchTowr dimensionó el problema contando cerca de 700.000 instancias de Confluence expuestas en una búsqueda en Internet y sitúa la cifra de afectados en el rango de seis a siete cifras. Los clientes de Atlassian Cloud no tienen que hacer nada, porque el fabricante ya parcheó esa versión.

La telemetría de CrowdSec da una foto del reparto de los ataques. Entre el 7 y el 12 de octubre registró 89 direcciones IP únicas atacando, con un pico de actividad el 9 de octubre, cuando la empresa elevó la fase a «escalada rápida». Buena parte del ruido procede de escáneres de investigación como LeakIX, que concentró el 88 % de las señales. Por destino, Alemania recibió el 35 % de los intentos, Francia el 15 %, Estados Unidos el 11 % y Sudáfrica el 8 %, y por sector el comercio acumuló el 56 %.

Cronología de explotación de CVE-2026-21589 de CrowdSec, con las IP atacantes por día entre el 5 y el 12 de octubre de 2026
Fuente: CrowdSec, «CVE-2026-21589: Atlassian Jira & Confluence Flaw Exploited»

En España, INCIBE-CERT publicó el 6 de octubre el aviso INCIBE-2026-700, de importancia crítica, que recoge la vulnerabilidad y las versiones corregidas. CERT-EU hizo lo propio con su aviso 2026-015 el mismo día. En el momento de escribir esta noticia no hay un recuento público de instancias españolas expuestas ni víctimas confirmadas en el país, pero el perfil del software, muy extendido en equipos de desarrollo y de soporte, deja claro que la superficie es amplia. Quien gestione estos servicios encontrará en nuestra guía sobre DevSecOps el contexto de por qué las plataformas de desarrollo son un objetivo prioritario.

Qué hacer

  1. Actualiza de inmediato a una versión corregida. Confluence Data Center salta a 9.2.26 o 10.2.19, Jira Software y Jira Service Management a 9.12.40, 10.3.26 u 11.3.12, Bitbucket a 9.4.26, 10.2.8 o 10.5.1, Bamboo a 10.2.24 o 12.1.12, Crowd a 6.3.7, 7.0.3, 7.1.7 o 7.2.4, y Crucible y Fisheye a 4.9.15. Trátalo como un parcheo de emergencia fuera del ciclo habitual.
  2. Si no puedes parchear ya, saca la instancia de Internet o restringe el acceso externo, incluso si exige inicio de sesión.
  3. Aplica como medida temporal una de las tres mitigaciones del fabricante. En el firewall de aplicaciones o el proxy, bloquea las URL que encajen con el patrón que publica Atlassian. Este es el filtro recomendado:
(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*
  1. En Confluence, Jira, Jira Service Management, Bamboo y Crowd puedes activar en su lugar el RewriteValve de Tomcat y colocar la regla de reescritura del aviso en el WEB-INF del producto. En Bitbucket la mitigación equivalente es una regla en urlrewrite.xml.
  2. Revisa los registros de acceso en busca de explotación. Atlassian recomienda decodificar cada línea hasta dos veces y buscar dos puntos seguidos pegados a una barra, una contrabarra o unos dos puntos dobles, o aplicar su expresión regular directamente sobre las líneas sin decodificar. Este comando resume esa búsqueda sobre un registro ya decodificado:
grep -E '(\.\.(/|\\|::))' access.log
  1. Si usas Crowd integrado y el crowd.properties pudo quedar expuesto, da por comprometidas esas credenciales de aplicación, rótalas y revisa los grupos de administración de Jira en busca de cuentas nuevas que no reconozcas.
  2. Para el seguimiento, usa el generador de watchTowr o la plantilla de Nuclei contra tus propias instancias y mantén la vigilancia después de parchear, porque el fallo no deja rastro de enumeración. En España, las empresas pueden notificar los incidentes a INCIBE-CERT y el sector público, al CCN-CERT.

Análisis

La frase del aviso que más tranquiliza es también la más engañosa. Atlassian insiste en que el atacante «must already know the exact file name and path» (debe conocer ya el nombre y la ruta exactos del archivo) y que no se pueden listar directorios. En un producto empaquetado, donde todas las instalaciones comparten la misma estructura, esa barrera apenas existe: la ruta a crowd.properties es la misma en todas partes. El caso de Crowd enseña que un fallo etiquetado como simple lectura de archivos vale, en la configuración adecuada, lo mismo que una ejecución remota de código.

La cronología repite un patrón que venimos viendo este mes. El parche sale, un laboratorio publica el análisis con prueba de concepto, aparece una plantilla de Nuclei y, en horas, los señuelos registran los primeros intentos. Pasó con el zero-day de PAN-OS y con los tres fallos de Ivanti Connect Secure, y la ventana entre divulgación y explotación se mide ya en horas, no en días. El consejo operativo es el mismo que en el fallo crítico de GitLab en el CI/CD: las plataformas de colaboración y desarrollo no deberían estar expuestas a Internet, y menos cuando guardan credenciales en texto plano.

La entrada en el KEV también sirve para calibrar a Atlassian como objetivo. El fabricante acumula catorce vulnerabilidades en el catálogo de CISA, y este CVE es el primero que entra en 2026 tras un 2025 en blanco. Confluence y Jira llevan años siendo blanco recurrente de atacantes que buscan un pie dentro de la red corporativa.

Vulnerabilidades de Atlassian añadidas al catálogo KEV de CISA por año, de 2021 a 2026
Elaboración propia con datos de CISA

Para quien gestiona estos sistemas, la lección va más allá del parche puntual. Exponer la administración de un servicio de identidad como Crowd a Internet es un riesgo que conviene revisar dentro de una estrategia más amplia de protección de accesos, como la que detallamos al hablar de cómo proteger las APIs que estos productos exponen.

Preguntas frecuentes

¿CVE-2026-21589 permite ejecutar código en el servidor?

Por sí mismo, no. Es una lectura de archivos sin autenticar limitada al directorio de la aplicación web. El riesgo de control total aparece cuando el archivo leído contiene secretos, como el crowd.properties de una integración con Crowd, que permite crear un administrador de Jira. En otras configuraciones el impacto se queda en la exposición de información sensible.

¿Están afectados los clientes de Atlassian Cloud?

No. Atlassian parcheó las versiones en la nube antes de publicar el aviso, por lo que los clientes de Cloud no necesitan actuar. La vulnerabilidad afecta solo a las instalaciones autoalojadas de los ocho productos Data Center y Server por debajo de las versiones corregidas.

¿Cómo sé si ya han intentado explotar mi instancia?

Revisa los registros de acceso del servidor. Decodifica cada petición hasta dos veces y busca dos puntos seguidos pegados a una barra, una contrabarra o unos dos puntos dobles, el patrón del salto de directorio. Como el fallo no permite enumerar directorios, un intento deja huella en los logs aunque no haya tenido éxito, así que la revisión conviene mantenerla también después de aplicar el parche. Si gestionas un parque de servicios expuestos y quieres entender cómo encaja este incidente en una respuesta ordenada, nuestro análisis sobre resiliencia digital desarrolla el enfoque.

Temas

No hay comentarios todavía