Fallo en Collabora CODE abre puertas traseras en Nextcloud

Fallo en Collabora CODE abre puertas traseras en Nextcloud

Los atacantes llevan cerca de un mes aprovechando una vulnerabilidad crítica de ejecución de comandos en una aplicación de Collabora para Nextcloud. El fallo no ha recibido un identificador CVE hasta esta semana.

El error tiene asignado el identificador CVE-2026-110447. Afecta a la aplicación Collabora Online - Built-in CODE Server, conocida internamente como richdocumentscode. Los administradores de Nextcloud usan esta aplicación opcional para ejecutar un servidor de documentos de Collabora integrado directamente en su instancia de Nextcloud, de modo que no tienen que desplegar uno aparte.

Según varios administradores, la explotación comenzó a mediados de septiembre. Es decir, unas cuatro semanas antes de que se publicaran el boletín de seguridad, el aviso de GitHub y la entrada CVE.

Cómo funciona el ataque

La vulnerabilidad está presente en todas las versiones de richdocumentscode anteriores a la 26.4.303. Se encuentra en el código que utiliza la aplicación de Nextcloud para arrancar el servidor de Collabora integrado.

Los atacantes envían una petición manipulada al endpoint proxy.php de la aplicación, lo que provoca una inyección de comandos en el sistema operativo. No hace falta autenticación ni interacción del usuario. Solo hay una condición: el servidor CODE integrado tiene que estar detenido cuando llega la petición. Eso puede ocurrir tras un reinicio, una actualización o un fallo.

Collabora asegura que el problema se limita a la aplicación opcional del servidor CODE integrado. Los servidores independientes de Collabora Online no están afectados. Tampoco lo están las instalaciones en Docker, las instaladas mediante paquetes RPM/DEB ni los despliegues de Nextcloud All-in-One.

Webshells, búsqueda de contraseñas y robo de monederos

Los administradores que detectaron actividad maliciosa en sus sistemas informaron de ataques contra varios endpoints; los primeros se remontan al 10 de septiembre.

Al parecer, los intrusos instalaron webshells en PHP en los servidores comprometidos. Es un método similar al observado en intentos recientes de colocar puertas traseras en sitios WordPress. Después, los atacantes utilizaron las webshells para buscar bases de datos de contraseñas, restos de gestores de contraseñas y monederos de criptomonedas.

Algunos usuarios afirmaron además que grupos de ransomware están aprovechando el fallo. BleepingComputer, que fue el primero en informar de los ataques, no ha podido verificarlo de forma independiente.

Actualizar o eliminar la aplicación

Los administradores deberían actualizar richdocumentscode a la versión 26.4.303 o posterior. Si no necesitan el servidor integrado, pueden eliminar la aplicación por completo. Collabora advierte de que limitarse a desactivarla no basta para estar protegido.

La cronología muestra cuánto tiempo estuvieron los administradores sin una referencia clara:

  • 9 de septiembre: se publicó el commit con la corrección
  • 10 de septiembre: primeros ataques de los que se tiene constancia
  • 11 de septiembre: se lanzó la versión 26.4.303
  • 3 de octubre: un aviso de la comunidad instó a los administradores a actualizar de inmediato por la explotación en curso
  • 14 de octubre: se publicaron el aviso y el CVE

Los responsables del proyecto sí emitieron avisos a mediados de septiembre. Sin embargo, sin un identificador CVE resultaba más difícil para los administradores identificar el problema, cotejarlo con sus inventarios de activos y aplicar las defensas adecuadas.

Los fabricantes culpan al atasco de los CVE

Nextcloud explicó a BleepingComputer que Collabora comunicó la vulnerabilidad a mediados de septiembre y que la actualización se distribuyó a través de la tienda de aplicaciones. La empresa dijo que retrasó la divulgación para dar tiempo a los usuarios a actualizar y que no había observado una explotación generalizada.

En una entrada de blog sobre los ataques, Collabora dio otro motivo principal para el retraso. Lo atribuyó a la acumulación de trabajo en la tramitación de CVE de GitHub, que, según la empresa, está desbordada por el creciente número de informes de seguridad generados con IA.

Esa opinión coincide con una investigación reciente de Second Security. La empresa analizó casos reales de vulnerabilidades en software de código abierto y midió el tiempo transcurrido entre la publicación de una corrección y la del CVE. La mediana era de 5,1 días en enero y había crecido hasta los 39 días en agosto.

Los investigadores creen que el volumen cada vez mayor de vulnerabilidades descubiertas con ayuda de la IA está saturando la tramitación de CVE y provocando los retrasos. También comprobaron que, en muchos casos, aparecía código de explotación público a las pocas horas de una corrección, varios días antes de que se publicara el CVE correspondiente. Según Second Security, las herramientas de IA facilitan a los atacantes convertir las correcciones publicadas en exploits funcionales.

Análisis

El caso de Collabora es un buen ejemplo de un problema que probablemente irá a más. Muchas organizaciones se basan en los identificadores CVE para decidir qué parchear y cuándo. Los escáneres de vulnerabilidades, los flujos de gestión de incidencias y los controles de cumplimiento normativo a menudo solo reaccionan cuando ya existe un CVE. Si las correcciones salen semanas antes que el identificador, los equipos que dependen de esos procesos son los últimos en enterarse, mientras que los atacantes pueden estudiar el commit público desde el primer momento.

Esto indica que los administradores de herramientas autoalojadas como Nextcloud no deberían tratar el canal de CVE como su único sistema de alerta temprana. Los registros de cambios de los fabricantes, las actualizaciones de la tienda de aplicaciones y los foros de la comunidad también merecen atención, sobre todo en el caso del software colaborativo expuesto a internet que almacena archivos sensibles.

Las mismas herramientas de IA que están acelerando el descubrimiento de fallos parecen estar sumando presión al propio proceso de divulgación. Habrá que ver si GitHub y otras autoridades de numeración CVE cambian sus procesos para hacer frente a la carga. También está por ver si se confirman los informes, aún sin verificar, sobre actividad de ransomware vinculada a este fallo.