Ocho productos, diecinueve versiones: el aviso de Atlassian dice qué hacer, no qué tienes

El aviso de Atlassian del 5 de octubre te manda hacer tres cosas: parchear a una de diecinueve versiones, sacar la instancia de internet mientras tanto y rebuscar en los access logs. Las tres son razonables y están bien explicadas. Las tres empiezan por una pregunta que ellos no pueden responder desde Australia: qué tienes montado y dónde.

Hablamos del CVE-2026-21589, publicado el 5 de octubre de 2026. Acceso arbitrario a ficheros, sin autenticar, 9,3 en CVSS 4.0 por valoración de la propia Atlassian, crítico. Afecta a ocho productos autoalojados: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible y Fisheye. En la tabla de versiones afectadas, los ocho dicen lo mismo: «All versions are affected». Atlassian Cloud ya está parcheado y no requiere acción de sus clientes.

La descripción del fallo, entera y sin recortar. Son dos párrafos seguidos del aviso:

«This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory in affected versions. Exploitation requires prior knowledge of the target file's exact name and path; this vulnerability does not allow attackers to enumerate or list directory contents.»

«In some configurations, there may be sensitive files present that increase your risk. All Data Center products listed below are at risk and require immediate attention.»

Las dos mitades tiran en direcciones distintas y las dos son del fabricante. La primera acota: sin listado de directorio, hay que saber el nombre y la ruta exactos. La segunda avisa de que en algunas configuraciones habrá ficheros sensibles que suben el riesgo, y cierra con «require immediate attention». Cuál de las dos es tu caso depende de cómo tengas la instalación, y eso Atlassian no lo sabe. Lo pone por escrito más abajo, en la sección de detección: «Atlassian cannot confirm if your instances have been affected by this vulnerability». Un apunte de precisión, ya que estamos: esa frase dice «All Data Center products», y dos de los ocho afectados —Crucible y Fisheye— no llevan Data Center en el nombre. Están en la lista igual.

Instrucción uno: parchea. Son diecinueve versiones

La tabla del aviso, con las filas en nuestro orden. La columna de la derecha, tal como lo leemos nosotros, son las ramas de mantenimiento vivas de cada producto, y lo normal es que cada instalación suba dentro de la suya; Atlassian lo escribe más abierto: «patch each of your affected installations to fixed versions or the latest version», o sea que saltar a la última también vale si te lo puedes permitir. Y recomienda la versión LTS corregida o posterior.

Diecinueve versiones correctivas en un solo aviso. Crowd, que en muchas casas es el servicio de identidad que hay delante de todo lo demás, aparece con cuatro ramas vivas. Los dos Jira van con tres ramas cada uno. Crucible y Fisheye comparten la 4.9.15, que es lo normal porque comparten media base de código.

Prueba a preguntar en tu equipo «¿en qué versión vamos?». Si la respuesta es «en la 10.2», hay tres productos del aviso con una rama 10.2 —Bitbucket, Confluence y Bamboo— y los tres llevan parches distintos. Si la respuesta es «en la última», tampoco sirve: hay tres últimas de Jira Software y tres de Jira Service Management. Ya le dimos una vuelta parecida a esto cuando el número de versión de un NetScaler no bastaba para saber si estabas expuesto; aquí el listón está más abajo, porque el número tampoco basta para saber qué parche te toca.

Instrucción dos: si no puedes parchear, bájalo de internet

Atlassian pide que retires la instancia de internet hasta que puedas parchear o mitigar, y añade que las instancias accesibles desde internet público «including those with user authentication» deberían quedar fuera del alcance externo mientras tanto. Que esté detrás de un login no cuenta como mitigación, y eso descarta de un plumazo la respuesta rápida que daría mucha gente.

Si bajarlo no es viable, el aviso numera tres opciones, y conviene fijarse en el paréntesis de cada una porque no cubren lo mismo. La opción 1, única marcada «For All Affected Products», es una regla de cortafuegos de aplicación o capa proxy que bloquee el patrón por expresión regular; la intención declarada es cortar .. cuando aparece pegado a /, \ o ::, también en sus formas codificadas. La opción 2 es el RewriteValve de Tomcat, y vale solo para Confluence, Jira Service Management, Jira, Bamboo y Crowd. La opción 3 es una regla en urlrewrite.xml, y el aviso la marca «For Bitbucket only».

Haz la cuenta cruzando los paréntesis con la lista de afectados y sale lo que importa: para Crucible y Fisheye no hay opción 2 ni opción 3. Si tienes esos dos y no puedes parchearlos hoy, te quedan la regla de cortafuegos o retirarlos de internet, y no hay tercera. La regla exacta y las rutas concretas están en el aviso; no las copiamos aquí para que nadie las aplique desde una traducción. Lo que sí hace falta antes de elegir cualquiera de las tres es saber, producto por producto, cuáles llegan desde fuera, por dónde entran y qué hay delante. Con un Confluence eso se contesta de memoria; con ocho productos repartidos entre un proxy, una VPN y un acceso que se abrió «provisionalmente» para un proveedor, es media mañana antes de poder tocar nada.

Instrucción tres: mira los logs. ¿Los tienes?

La sección de detección ocupa un párrafo. Atlassian reconoce que no puede confirmar si tu instancia se ha visto afectada, pide que tu equipo de seguridad revise todas las instalaciones afectadas en busca de indicios y da el método: descodificar cada línea de petición del access log —hasta dos pasadas de descodificación, porque el patrón puede venir doblemente codificado— y buscar después .. pegado a /, \ o ::. Alternativamente, aplicar la misma expresión regular sobre las líneas en crudo.

Es una instrucción excelente y por eso duele la pregunta siguiente: ¿hasta cuándo llegan tus access logs? El aviso salió el 5 de octubre, pero la vulnerabilidad afecta a todas las versiones anteriores a las corregidas, o sea que la ventana que querrías mirar no empieza el 5 de octubre. Si el rotado se queda en siete días, o si el log está en la máquina que vas a reinstalar, la instrucción es perfecta y aun así no se puede ejecutar. Ya escribimos sobre cómo el título de una issue acababa filtrando un token de Jira; el hilo conductor es el mismo, que lo que no queda registrado no se puede reconstruir después.

Dónde se concentra el historial: trece, ocho y cero

A día de hoy no hay explotación catalogada de este CVE. Lo comprobamos esta mañana contra el fichero público del catálogo KEV de CISA, el de vulnerabilidades con explotación confirmada, versión 2026.10.04 y 1.734 entradas: CVE-2026-21589 no está. Conviene no estirar ese dato: que CISA no lo haya catalogado no significa que nadie lo esté usando, y lo único que dice Atlassian sobre Cloud es que su investigación no ha encontrado indicios de explotación.

Ya puestos, preguntamos por el fabricante entero en vez de por el CVE. La consulta tarda lo que tarde la descarga:

curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq -r '[.vulnerabilities[] | select(.vendorProject=="Atlassian")]
           | length,
             (map(select(.knownRansomwareCampaignUse=="Known")) | length),
             (map(select(.product | test("Cloud"))) | length)'

13
8
0

Trece vulnerabilidades históricas de Atlassian con explotación confirmada. Ocho de las trece marcadas con uso conocido en campañas de ransomware. Y la tercera cifra: ninguna corresponde a un producto Cloud. Eso no demuestra que Cloud sea más seguro, y no lo vamos a vender así —un fallo de Cloud lo arregla el fabricante sin que nadie tenga que catalogarlo, así que por construcción no llega al KEV—. Lo que sí describe es dónde cae el trabajo cuando sale un aviso como el del lunes. Un detalle que aparece solo al ordenar por fecha: la entrada más conocida de esa lista, el CVE-2023-22515 de Confluence, entró en el catálogo un 5 de octubre, tres años justos antes de este aviso.

El orden en que lo haríamos

Lo que no afirmamos

Con un Confluence y poco más, esto es una tarde y no necesitas a nadie: miras la rama, subes y compruebas por dónde se llega. Pesa cuando son los ocho, cada uno en su rama, con un Crowd delante autenticando al resto y un Fisheye del que nadie se acuerda desde hace años. Ahí el cuello de botella deja de ser técnico: es saber qué hay, en qué rama y quién lo mira, y que alguien lea el aviso el lunes a primera hora y no el jueves, que es literalmente lo que es un soporte 24×7. Con el conflicto de interés por delante: vendemos las dos cosas. Si eso ya lo lleva tu gente, perfecto y no nos debes nada. Si no lo lleva nadie, que es lo habitual, hablémoslo.

Fuentes