Una vulnerabilidad en la aplicación Collabora CODE permitió ejecutar comandos sin autenticación e instalar puertas traseras en servidores Nextcloud. La corrección existe, pero desactivar la aplicación no basta para proteger los sistemas afectados.
Un fallo de seguridad en una herramienta utilizada para editar documentos en línea ha permitido a atacantes introducir puertas traseras en servidores Nextcloud. Los primeros ataques documentados se remontan al 10 de septiembre de 2026, mientras que la vulnerabilidad se hizo pública el 14 de octubre, según la investigación publicada por The Hacker News.
El problema afecta a Collabora Online – Built-in CODE Server, una aplicación opcional que ejecuta localmente el servidor de edición de documentos de Collabora dentro de Nextcloud. La vulnerabilidad, identificada como CVE-2026-110447, permitía ejecutar comandos en el servidor sin necesidad de iniciar sesión, bajo determinadas condiciones.
Los administradores afectados encontraron archivos PHP maliciosos capaces de ejecutar instrucciones enviadas mediante solicitudes web. Aunque no se conoce el número total de servidores comprometidos, varios responsables de sistemas comunicaron incidentes similares.
La alerta deja una advertencia clara para las empresas y organizaciones que gestionan sus propios servicios de almacenamiento: instalar una solución de nube privada no elimina los riesgos de seguridad; también es imprescindible mantener actualizados sus componentes y vigilar los accesos al servidor. The Hacker News.
Qué es Nextcloud y por qué importa esta vulnerabilidad
Nextcloud es una plataforma de colaboración y almacenamiento de archivos que permite alojar documentos, calendarios y otros servicios en servidores propios o contratados. Empresas, administraciones y usuarios particulares la utilizan como alternativa a las plataformas de nube gestionadas íntegramente por grandes proveedores.
Una de sus ventajas es que las organizaciones pueden mantener un mayor control sobre la infraestructura y los datos. Sin embargo, esa autonomía también implica responsabilidades: alguien debe gestionar las actualizaciones, controlar las aplicaciones instaladas, supervisar los registros y responder ante posibles incidentes.
La vulnerabilidad no afecta indistintamente a todas las instalaciones de Nextcloud. El elemento señalado es richdocumentscode, el paquete correspondiente a la aplicación Collabora Online – Built-in CODE Server.
Este componente descarga y ejecuta en el propio servidor una edición de desarrollo de Collabora Online, conocida como CODE. Su finalidad es facilitar la edición de documentos sin desplegar necesariamente un servidor Collabora independiente.
La aplicación está orientada principalmente a pruebas, uso personal y equipos pequeños. Por eso, conviene distinguir entre quienes tienen instalado este componente integrado y quienes utilizan Nextcloud Office con un servidor Collabora independiente.
Según el aviso de seguridad de Collabora, los servidores Collabora Online independientes no están afectados por este fallo concreto. Tampoco se considera afectada una instalación que utilice únicamente la aplicación Nextcloud Office, identificada como richdocuments, sin el componente vulnerable richdocumentscode.
CVE-2026-110447: cómo funcionaba el fallo
El problema se encontraba en el archivo proxy.php, encargado de intervenir cuando el servidor local de documentos necesita iniciarse.
En las versiones vulnerables, hasta la 26.4.302, el código incorporaba texto procedente de la solicitud HTTP —incluida parte de su ruta— a una orden ejecutada mediante Bash. Debido a la forma en que se construía esa orden, un atacante podía introducir expresiones que el intérprete de comandos ejecutaba como instrucciones.
El resultado era una vulnerabilidad de inyección de comandos: un tercero podía conseguir que el servidor ejecutara órdenes sin tener que autenticarse previamente.
El ataque no funcionaba de forma idéntica en cualquier circunstancia. La condición descrita por los investigadores era que el servidor local de CODE estuviera detenido y tuviera que iniciarse, algo que puede suceder durante un reinicio, una actualización o después de un fallo.
Cuando se daban esas condiciones, una solicitud manipulada podía activar la ejecución de comandos con los permisos de la cuenta que utilizaba el servidor web.
Este detalle es importante. La vulnerabilidad no otorgaba automáticamente privilegios de administrador del sistema o acceso de root. Sin embargo, cualquier archivo, configuración o secreto que pudiera leer la cuenta comprometida debía considerarse potencialmente expuesto.
El aviso de Collabora identifica el fallo con el código CVE-2026-110447 y señala que se había explotado en ataques reales durante septiembre y octubre de 2026.
Los atacantes instalaron puertas traseras PHP
La investigación de The Hacker News recoge los testimonios de tres administradores que detectaron intrusiones en sus instalaciones.
El primer incidente documentado se registró el 10 de septiembre. Los registros de acceso de dos servidores mostraban solicitudes dirigidas al archivo proxy.php?status, con instrucciones maliciosas ocultas en la ruta de la petición.
Los atacantes utilizaron esas solicitudes para depositar una pequeña puerta trasera escrita en PHP dentro del directorio de la aplicación. Este tipo de herramienta se conoce como web shell.
Una web shell es un archivo que permite ejecutar comandos en el servidor a través de solicitudes web. Si un atacante logra instalarla y acceder a ella, puede mantener una vía de control sobre el sistema mientras el archivo siga disponible y conserve los permisos necesarios.
En uno de los servidores, el código malicioso trató de enviar información básica del sistema a un servicio externo. Posteriormente, el atacante utilizó la puerta trasera para buscar archivos relacionados con gestores de contraseñas y monederos de criptomonedas.
Entre los nombres buscados figuraban archivos con extensiones y denominaciones asociadas a bases de datos de credenciales, Bitcoin y otras criptomonedas.
Los registros revisados no mostraron órdenes que archivaran o transfirieran esos archivos fuera de los servidores analizados. Eso no demuestra que los datos estuvieran a salvo: la propia cuenta del servidor web podía acceder a determinada información y, por tanto, esta debía tratarse como potencialmente expuesta.
Un segundo administrador detectó un archivo PHP nuevo después de que el sistema de comprobación de integridad de Nextcloud señalara una modificación inesperada. Otro recibió avisos relacionados con intentos fallidos de utilizar sudo.
Los informes disponibles no acreditan que los atacantes obtuvieran privilegios de root en esos incidentes. Tampoco permiten determinar cuántas instalaciones fueron comprometidas en total.
La cronología: los ataques comenzaron antes del aviso público
Uno de los aspectos más relevantes del caso es la secuencia temporal descrita por los investigadores.
- 20 de agosto: se escribió un cambio de código que posteriormente resultaría relevante para corregir el problema.
- 31 de agosto: se publicó la versión 26.4.302, que seguía siendo vulnerable.
- 9 de septiembre: se registró el cambio de código que cerraba la vulnerabilidad.
- 10 de septiembre: aparecen los primeros ataques documentados por los administradores.
- 11 de septiembre: se publicó la versión 26.4.303 con la corrección.
- 3 de octubre: se difundió una advertencia en el foro de la comunidad Nextcloud sobre la explotación activa del fallo.
- 14 de octubre: Collabora publicó el aviso de seguridad con el identificador CVE-2026-110447.
La secuencia plantea preguntas sobre la comunicación de las vulnerabilidades. El cambio de código que solucionó el problema se publicó inicialmente con una descripción técnica general, sin una explicación pública inmediata que permitiera identificarlo claramente como una corrección de seguridad.
La documentación disponible no establece con precisión cuándo conoció Collabora la explotación ni cuándo recibió el primer aviso sobre los ataques. Por eso, no sería riguroso concluir que la empresa conocía toda la dimensión del incidente y decidió ocultarla.
Lo que sí está documentado es que la corrección técnica llegó en septiembre y el aviso de seguridad se publicó el 14 de octubre, después de que usuarios y administradores ya hubieran alertado de intrusiones.
Esta diferencia temporal es importante para los responsables de sistemas: una actualización puede incluir una corrección relevante aunque sus notas de publicación no expliquen de forma explícita el riesgo que está resolviendo.
Qué versiones están afectadas y quién debe actuar
El aviso de seguridad de Collabora señala como vulnerables las versiones de Built-in CODE Server anteriores a la 26.4.303. La corrección se publicó el 11 de septiembre.
La distinción entre aplicaciones es esencial. No todos los usuarios de Nextcloud tienen instalado el componente afectado y no todos los despliegues de Collabora utilizan el modo integrado.
| Configuración | Situación descrita |
|---|---|
richdocumentscode anterior a 26.4.303 | Vulnerable al fallo investigado |
richdocumentscode 26.4.303 | Versión identificada como corregida |
Solo richdocuments con Collabora independiente | No afectado por esta vulnerabilidad concreta |
| Nextcloud 29 o anterior | Requiere atención especial por incompatibilidad y fin de soporte |
La versión 26.4.303 exige Nextcloud 30 o posterior. Las instalaciones antiguas que no puedan actualizar el componente deben valorar la actualización de Nextcloud o la retirada de la aplicación vulnerable.
El repositorio oficial también muestra una versión posterior, 26.4.402, publicada el 24 de septiembre. Sin embargo, The Hacker News recogía que algunos administradores habían comunicado problemas de funcionamiento con esa versión. Antes de desplegarla en producción, conviene comprobar el estado actual de las notas de versión y las indicaciones de seguridad del proveedor.
La recomendación central no cambia: no basta con apagar el componente y dejarlo instalado en una versión vulnerable.
Cómo comprobar si un servidor ha sido comprometido
Actualizar el software corrige la vulnerabilidad conocida, pero no elimina automáticamente una puerta trasera que un atacante haya instalado antes de la actualización. Las organizaciones que hayan ejecutado la aplicación vulnerable deberían realizar una revisión de seguridad.
Entre las comprobaciones recomendadas figuran:
- Verificar la versión instalada. Revisar la lista de aplicaciones de Nextcloud y confirmar si aparece Collabora Online – Built-in CODE Server (
richdocumentscode). - Actualizar o retirar el componente. Instalar una versión corregida compatible o eliminar la aplicación si no se necesita.
- Examinar los registros web. Buscar solicitudes sospechosas dirigidas a
proxy.php?status, especialmente si contienen rutas manipuladas o patrones relacionados con la ejecución de comandos. - Buscar archivos PHP inesperados. Los administradores afectados notificaron ficheros con nombres similares a
shx*.phpdentro del directorio de la aplicación. - Revisar accesos y privilegios. Comprobar intentos anómalos de ejecutar
sudo, procesos inesperados y accesos a almacenes de credenciales. - Evaluar la posible exposición de datos. Si se confirma una intrusión, revisar qué información podía leer o modificar la cuenta del servidor web y actuar según el plan de respuesta a incidentes.
La presencia de un indicador aislado no siempre demuestra una intrusión; debe analizarse junto con los registros y el contexto de cada sistema. Si se confirma una puerta trasera, eliminar el archivo sospechoso no debería ser la única medida: hay que investigar el alcance del acceso, cambiar las credenciales potencialmente expuestas y valorar la reconstrucción del servidor desde una fuente fiable.
Las organizaciones con datos sensibles deberían recurrir a su equipo de seguridad o a especialistas en respuesta a incidentes. La prioridad es determinar si hubo acceso no autorizado, no limitarse a conseguir que la aplicación vuelva a funcionar.
Qué deben hacer las empresas y administraciones
El incidente también pone de relieve un problema habitual en la seguridad informática: las aplicaciones auxiliares pueden convertirse en un punto de entrada aunque no sean el servicio principal de una organización.
Para reducir el riesgo, los responsables de sistemas deberían mantener un inventario actualizado de las aplicaciones instaladas, aplicar las actualizaciones de seguridad con rapidez y evitar exponer innecesariamente servicios administrativos a Internet.
También es recomendable limitar los permisos de las cuentas de servicio, separar los sistemas críticos y mantener copias de seguridad protegidas frente a modificaciones no autorizadas. Las copias deben probarse periódicamente; disponer de ellas no garantiza una recuperación segura si el atacante también pudo acceder a ellas.
La gestión de vulnerabilidades requiere, además, una comunicación clara entre los desarrolladores, los proveedores de aplicaciones y los administradores. Cuando una corrección se publica sin que el riesgo quede suficientemente explicado, los responsables de sistemas pueden tardar más en identificar la urgencia de la actualización.
Una alerta que va más allá de Nextcloud
La vulnerabilidad de Collabora demuestra que la seguridad de una plataforma depende también de sus componentes integrados y de cómo se ejecutan las órdenes del sistema. En este caso, una construcción insegura de un comando permitió que una solicitud manipulada llegara al intérprete de comandos.
El incidente no significa que todas las instalaciones de Nextcloud estén comprometidas ni que se haya demostrado el robo masivo de documentos. El número total de servidores afectados sigue sin estar claro, y los informes públicos describen varios casos concretos, no un recuento global.
Sí existe una conclusión operativa: quienes utilicen la aplicación integrada vulnerable deben comprobar su versión, actualizarla o retirarla y examinar el sistema si pudo estar expuesto durante el periodo de explotación.
La seguridad de una nube privada no depende solo de quién aloja los datos. También depende de la disciplina con la que se actualizan sus aplicaciones, de la vigilancia de los accesos y de la capacidad de detectar una intrusión antes de que se convierta en un incidente mayor.
Toqueteo
Toqueteo
Toqueteo