Seis semanas de webshells en Nextcloud por el CODE de Collabora

A las 19:51 del 10 de septiembre de 2026, una petición GET desde la dirección 139.28.18.122 llegó a /apps/richdocumentscode/proxy.php?status de un servidor Nextcloud con la app Collabora Online Built-in CODE Server y dejó una webshell PHP en el directorio de la aplicación. Cuarenta y tres días después, el 23 de octubre, CISA incorporó ese fallo, CVE-2026-110447, a su catálogo KEV con plazo hasta el 26 de octubre, mientras los administradores seguían encontrando ficheros shx*.php en servidores que creían protegidos por haber desactivado la app.

Un comando bash montado con la URL, así entra CVE-2026-110447 en proxy.php

Collabora Online Built-in CODE Server, richdocumentscode para la tienda de apps, es la forma rápida de tener Nextcloud Office sin montar un servidor Collabora aparte. La app descarga un AppImage de la Collabora Online Development Edition (CODE) y lo lanza en el mismo host que Nextcloud. El fichero proxy.php hace de intermediario entre el navegador y ese proceso local y, si el proceso no está arrancado, lo levanta.

Ahí vivía el fallo. Hasta la versión 26.4.302, la función startCoolwsd() construía la orden de arranque como una única cadena interpolada dentro de un bash -c entre comillas dobles, con datos de la petición mezclados en ella. El commit 6cc8dae del 9 de septiembre de 2026, firmado por el desarrollador caolanm con el título «tidy up how the coolwsd launch command is built» (ordenar cómo se construye la orden de arranque de coolwsd), separa la orden interna en una variable y la pasa por escapeshellarg() antes de concatenarla. Son tres líneas añadidas y una borrada en proxy.php, y las notas de la versión 26.4.303 del 11 de septiembre solo mencionan la versión del AppImage.

El aviso GHSA-g3vx-3m76-fghh, publicado el 14 de octubre, describe el resultado en una frase: «A request can cause an operating system command to run as the web server user» (una petición puede hacer que un comando del sistema operativo se ejecute como el usuario del servidor web). No hace falta autenticación ni que nadie pulse nada. La condición es que el servidor CODE integrado no esté corriendo en ese momento, algo que ocurre tras reiniciar el contenedor, durante una actualización o después de un cuelgue, porque es entonces cuando proxy.php intenta arrancarlo con la orden contaminada.

Los atacantes lo resolvieron con una URL que cuela una sustitución de comandos de bash en la ruta, usa la variable IFS en lugar de espacios para esquivar filtros y lleva un payload en base64 que sh decodifica y ejecuta. El resultado es un fichero PHP de una línea que ejecuta lo que llegue en el parámetro c. HeikoBw, el primer administrador que lo documentó, abrió el 11 de septiembre el issue 354 de richdocumentscode con los registros de dos de sus servidores, los de la captura superior, y una frase que resume el mes siguiente: «Since yesterday we're experiencing succesful hacks on our systems via richdocumentscode» (desde ayer sufrimos intrusiones con éxito en nuestros sistemas a través de richdocumentscode).

La captura del issue recoge los dos accesos del 10 y el 11 de septiembre desde 139.28.18.122, el objetivo explícito proxy.php?status, el salto de directorio superior con los puntos codificados en URL y la webshell recuperada. Collabora recuerda en el aviso que no es la primera vez que este fichero da problemas. CVE-2025-66208, corregido en la 25.04.702 en diciembre de 2025, era otra inyección de comandos en el mismo proxy.php a través de un proxy inverso intermedio, y el parche de aquel fallo no tapa este.

La fila de versiones afectadas tiene letra pequeña. UlliDieckmann, el segundo administrador del issue, actualizó a 26.4.303 el 14 de septiembre y preguntó por qué las peticiones del atacante seguían llegando al proxy.php de una app que él tenía desactivada. Nadie de Collabora respondió a esa pregunta en el hilo, pero el aviso de octubre la zanja: «It is not sufficient to disable the app to avoid the problem» (no basta con desactivar la app para evitar el problema). Desactivar deja el fichero en el disco y el servidor web sigue sirviéndolo. Hay que actualizar o borrar el directorio. Las versiones corregidas requieren Nextcloud 30 o posterior, así que quien siga en Nextcloud 29 o anterior tiene que actualizar el servidor o eliminar la app. La ficha en NVD seguía el 24 de octubre en estado Deferred, sin análisis propio, y solo refleja la puntuación 9,2 de MITRE.

Lo que las webshells shx*.php hicieron en los servidores comprometidos

HeikoBw revisó los comandos que pasaron por la webshell en uno de sus servidores. Eran búsquedas de bases de datos de KeePass (ficheros .kdbx), de wallet.dat y de directorios .ethereum, es decir, gestores de contraseñas y carteras de criptomonedas. No vio órdenes de empaquetar ni de exfiltrar, pero advirtió de que todo lo que puede leer la cuenta del servidor web debe darse por expuesto. Los payloads llamaban a webhook.site, un servicio legítimo de recepción de peticiones que aquí hacía de baliza para confirmar cada infección. Un tercer administrador, ahlund, descubrió el 18 de septiembre que estaba comprometido al recibir correos de su propio servidor por intentos de sudo fallidos del usuario www-data.

La agencia italiana ACN publicó el 16 de octubre el boletín BL02/261016/CSIRT-ITA con el análisis de un servidor comprometido en Italia. El atacante instaló tres webshells, ejecutó un único comando de verificación y se llevó un fichero de configuración con credenciales técnicas y secretos de la aplicación, entre ellos la base de datos local y un buzón de servicio. CSIRT Italia no encontró indicios de acceso a documentos, de escalada a administrador, de persistencia distinta de las webshells ni de movimiento lateral, y describe la actividad como una campaña automatizada en curso con varios actores detrás.

CERT Polska fue más lejos el 20 de octubre en su comunicado 194/2026 y afirma que el fallo se está usando en ataques de ransomware y en tomas de control de servidores. Ninguna otra fuente lo respaldaba a 24 de octubre. El catálogo KEV marca el uso en campañas de ransomware como desconocido y BleepingComputer, que preguntó a Nextcloud, tampoco pudo confirmarlo. Las webshells son el mismo tipo de artefacto que dejó la campaña contra BeyondTrust Remote Support, y en ambos casos lo que convierte un acceso oportunista en un incidente serio es lo que el atacante encuentra después.

El 15 de octubre, un día después del aviso, la base de datos de vulnerabilidades dbugs de Positive Technologies anunció en X la publicación de una prueba de concepto para el fallo, que sigue con la referencia PT-2026-113607. Desde ese momento, el conocimiento necesario para explotar proxy.php dejó de estar solo en manos de quien ya lo usaba en septiembre.

Los indicadores salen de los informes de los administradores en el issue 354 y del foro de Nextcloud, no de un aviso del fabricante, así que conviene tratarlos como punto de partida y no como lista cerrada. Los nombres de las webshells cambian de servidor a servidor y el fichero Nx_33143.php que un usuario del foro encontró el 16 de octubre no sigue el patrón shx*, lo que apunta a más de un operador.

Quién expone el CODE integrado, según Censys, y qué pasa en España

Censys contó el 16 de octubre 19.454 hosts y 103.350 propiedades web con la app visible desde Internet, cifras que incluyen los 1.001 hosts que usan la variante richdocumentscode_arm64, sobre la que el aviso de Collabora no dice nada. El recuento no distingue versiones, así que mide el universo donde buscar y no el número de servidores aún vulnerables.

El mapa de Censys reparte esos hosts por países y deja claro dónde vive el CODE integrado. Alemania concentra 6.965, seguida de Francia (1.819), Estados Unidos (1.607), Rusia (1.348), Austria (498), Brasil (471), Italia (451), Países Bajos (424), Finlandia (374) y Polonia (367). España no entra en los diez primeros y aparece en el mapa en la franja baja de la escala. El reparto se parece al de la propia base de usuarios de Nextcloud, con el mundo germanófono muy por delante, y explica que los primeros avisos nacionales hayan salido de Italia, Polonia y Letonia.

A las 17:30 UTC del 24 de octubre no hemos localizado aviso propio de INCIBE-CERT ni del CCN-CERT sobre CVE-2026-110447, aunque INCIBE-CERT sí tiene ficha del fallo anterior de proxy.php, CVE-2025-66208. Para una empresa española que tenga Nextcloud Office con el CODE integrado, la referencia práctica son el boletín italiano y el polaco, que coinciden en lo esencial con el aviso de Collabora y añaden qué buscar en los logs.

La captura que acompaña al blog de Collabora muestra el selector de Nextcloud Office con la opción marcada. El CODE integrado se describe allí como fácil de instalar, para uso doméstico o grupos pequeños, algo más lento que un servidor independiente. Esa frase retrata al afectado típico: la organización pequeña o el aficionado que montó Nextcloud Office con dos clics y nunca volvió a pensar en el AppImage que corre al lado del servidor web. Nextcloud es una aplicación PHP, y quien la administre lleva ya una semana atento a PHP2Shell, así que este es un segundo frente en la misma máquina.

Cinco pasos para cerrar proxy.php y buscar la webshell

Estos comandos, ejecutados desde la raíz de Nextcloud, cubren la actualización de la app, la búsqueda de ficheros PHP ajenos y el rastreo de las peticiones de explotación en el access log de Apache (ajusta la ruta si usas nginx o un proxy inverso delante):

# Versión instalada y actualización de la app
sudo -u www-data php occ app:list | grep -i richdocumentscode
sudo -u www-data php occ app:update richdocumentscode

# Ficheros PHP que no deberían estar en el directorio de la app
find apps/richdocumentscode -name 'shx*.php' -o -name 'shrf*.php' -o -name 'Nx_*.php'
sudo -u www-data php occ integrity:check-app richdocumentscode

# Peticiones de explotación desde el 10 de septiembre
zgrep -E 'proxy\.php\?status' /var/log/apache2/access.log* | grep -Ei 'IFS|%2e|[$][(]'

Con esa información en la mano, el orden de las acciones es este:

1. Actualiza richdocumentscode a 26.4.303 o posterior en todos los Nextcloud, también en los que tengan la app desactivada. Si el servidor sigue en Nextcloud 29 o anterior, actualízalo primero a una versión con soporte o borra el directorio apps/richdocumentscode. Si la 26.4.402 no arranca o no abre documentos, vuelve a la 26.4.303 y nunca a una anterior, que es lo que recogen The Hacker News y Rescana de varios administradores.
2. Revisa el access log desde el 10 de septiembre buscando peticiones a proxy.php?status con el salto de directorio codificado en URL, la sustitución de comandos de bash o la variable IFS, los tres patrones que CERT Polska da como firma. Si los logs rotan cada pocas semanas, recupéralos de las copias de seguridad, y si no los centralizas, este incidente es un buen motivo para repasar las soluciones open source de gestión de logs que ya analizamos.
3. Busca ficheros PHP que no sean de la app en apps/richdocumentscode y lanza la comprobación de integridad. Un fichero extra que llame a las funciones de PHP de ejecución de comandos del sistema es una webshell, aunque no se llame shx. Si aparece, no te limites a borrarla: elimina la app entera y vuelve a instalarla desde la tienda.
4. Si hubo webshell, aísla el servidor y preserva las evidencias antes de limpiar nada, como pide CSIRT Italia. Después rota desde un equipo de confianza todo lo que puede leer el usuario del servidor web: la contraseña de la base de datos, los valores secret y passwordsalt de config.php, las credenciales del buzón de envío, las contraseñas de aplicación y cualquier clave de API o certificado guardado en el servidor. Revisa también si esas cuentas se han usado desde fuera.
5. Notifica. Las empresas y los particulares pueden hacerlo a INCIBE-CERT y el sector público al CCN-CERT. Si en el Nextcloud había datos personales y confirmas el acceso al fichero de configuración, el plazo de 72 horas para la AEPD empieza a contar desde que lo sabes.

Para producción, Collabora lleva años diciendo que el CODE integrado no es la forma recomendada de desplegar. Un servidor Collabora Online separado, en su imagen Docker o con los paquetes RPM y DEB, no está afectado por este fallo ni por el de diciembre, y deja el proceso de ofimática fuera del host que sirve PHP.

Treinta y tres días sin CVE y una app que Collabora no recomienda en producción

Entre la versión que corrige el fallo y el aviso que lo cuenta pasaron 33 días. La tabla recoge lo que ocurrió en medio.

Collabora explica el retraso en su blog del 15 de octubre por la carga de trabajo del sistema de CVE, que atribuye al aluvión de informes de seguridad generados con IA, y anuncia que quiere convertirse en CNA para asignar sus propios identificadores. Nextcloud dijo a BleepingComputer que Collabora le comunicó el fallo a mediados de septiembre, que la actualización estaba disponible en la tienda de apps y que retrasar el anuncio dio tiempo a los usuarios a actualizar sin haber observado «widespread exploitation» (explotación generalizada).

En su cuenta de Mastodon, Collabora enmarcó el 15 de octubre el fallo como «A serious problem specific to a minority of users» (un problema serio específico de una minoría de usuarios). La app es minoritaria dentro de Nextcloud, y aun así Censys contó 19.454 hosts con ella expuesta al día siguiente. El retraso del CVE es un problema del ecosistema, pero las notas de versión las escribe cada proyecto. Un administrador que leyó en septiembre que la 26.4.303 traía el AppImage cp-26.04.3-3 no tenía ningún motivo para correr. Quien avisó fue un usuario del foro de Nextcloud el 3 de octubre, y lo hizo con palabras que ningún canal oficial había escrito aún: «The new version fixes a shell command injection vulnerability that is already being exploited» (la nueva versión corrige una inyección de comandos de shell que ya se está explotando).

CISA, en cambio, no esperó. El 23 de octubre incluyó el fallo en KEV con tres días de plazo y triaje forense obligatorio para las agencias federales, el mismo tratamiento que dio ese día al zero-day de VeloCloud Orchestrator y una semana antes al fallo de FortiOS usado para instalar PEERSTITCH. En el feed JSON del catálogo descargado el 24 de octubre, 146 entradas de 2026 llevan ese plazo de tres días bajo la directiva BOD 26-04, 26 de ellas añadidas en octubre. El plazo no obliga a ninguna organización española, pero refleja la prisa que la agencia considera razonable cuando ya circulan webshells y una PoC pública, como con el fallo de Atlassian.

Un Nextcloud con el CODE integrado es un servidor PHP expuesto que, además, lanza binarios con datos de la petición. Si lo tienes en producción, que la actualización de hoy sea la última: la siguiente instalación de Nextcloud Office debería ir contra un servidor Collabora separado, como recomienda el propio fabricante.

Dudas habituales sobre Collabora Online en Nextcloud

¿Qué es Collabora Online y para qué sirve?

Collabora Online es una suite ofimática web basada en LibreOffice que edita documentos, hojas de cálculo y presentaciones en el navegador. Nextcloud la integra con la app Nextcloud Office mediante el protocolo WOPI, y el administrador elige entre un servidor Collabora propio, uno de demostración o el CODE integrado que descarga un AppImage en el mismo host. Solo esta última opción está afectada por CVE-2026-110447.

¿Cómo actualizar Nextcloud?

El proceso es activar el modo mantenimiento, hacer copia de la base de datos y del directorio de datos y ejecutar php updater/updater.phar seguido de php occ upgrade. Solo se puede subir una versión mayor cada vez, así que un servidor en la 29 pasa por la 30 antes de llegar a la 35, y la 30 es el mínimo que exigen las versiones corregidas de richdocumentscode.