Nextcloud y CVE-2026-110447: el agujero se abre cuando algo se cae

El 14 de octubre Collabora publicó el aviso de la CVE-2026-110447: inyección de comandos del sistema operativo, sin autenticación y sin interacción del usuario, en una app opcional de Nextcloud que mucha gente instaló una tarde para poder abrir documentos en el navegador. Puntúa 9,2 sobre 10 en CVSS 4.0. Ya se estaba explotando desde septiembre, con webshells plantados en servidores de empresas que no sabían que tenían eso instalado.

Hasta aquí, un aviso más de un miércoles de octubre. Lo que hace que este merezca media hora de tu tiempo es una frase del propio aviso, literal: «The attack only works while the built-in CODE server is not running. So on a container restart, an upgrade, or after a crash.» El ataque solo funciona mientras el servidor de documentos integrado no está corriendo. En un reinicio del contenedor, en una actualización, o después de que se haya caído.

Léela otra vez pensando en tu calendario. La ventana de explotación es tu ventana de mantenimiento. Y las otras dos veces que se abre son las que no apuntas en ningún sitio: el proceso que se murió el martes a las tres de la madrugada y volvió solo, y el que se murió y no volvió.

Por qué el agujero necesita que algo esté caído

La app se llama Collabora Online - Built-in CODE Server (richdocumentscode) y es la versión «todo en uno»: en lugar de montar un servidor de Collabora aparte, mete el motor dentro de la propia instalación de Nextcloud. Para hablar con ese motor hay un intermediario en PHP, apps/richdocumentscode/proxy.php.

Ese intermediario tiene una cortesía que resulta ser la puerta: si nadie contesta al otro lado, intenta arrancar el motor él mismo. Para arrancarlo construye una línea de comandos de shell y, al construirla, mete dentro datos que vienen de la petición. Si lo que viene en la petición tiene la forma $(...), el shell no lo trata como texto: lo ejecuta. Y lo ejecuta con el usuario del servidor web, que es el usuario que puede escribir en el directorio de las apps.

De ahí sale la precondición. Si el motor está corriendo, el intermediario se limita a pasar la petición y no construye nada: no hay comando, no hay inyección. El agujero no es un estado permanente del sistema, es un estado transitorio. Y ahí está lo incómodo: ese estado transitorio no lo provoca el atacante. Lo provocas tú, cada vez que actualizas. O lo provoca el propio servidor, cuando el proceso se queda sin memoria a las tantas.

Un apunte para quien crea que esto ya lo parcheó: el aviso dedica una frase a aclararlo. «This is not the same path as CVE-2025-66208, and the fix for that issue does not prevent it.» No es el mismo camino que el fallo anterior del mismo componente, y haber corregido aquel no te cubre de este.

El 9,2 lleva una letra que casi nadie lee

El vector completo del aviso es CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. La pieza que casi nunca sale en las noticias es AT:P: Attack Requirements: Present. Es un campo que CVSS 4.0 añadió precisamente para esto, para decir que el ataque depende de que se dé una condición de despliegue o de ejecución que no está siempre presente. En otros fallos, ese AT:P es un consuelo razonable: la condición es rara, o depende de una carrera que hay que ganar con suerte.

Aquí no. Es el caso más claro que recordamos en el que ponerse al día con las actualizaciones abre, durante unos segundos, exactamente la puerta que las actualizaciones vienen a cerrar. No es una paradoja profunda: es una propiedad del arranque bajo demanda. Lo que sí cambia es cómo se lee el número, porque el 9,2 no dice cuántas veces al mes se da la condición. Eso solo lo sabes tú, y probablemente tampoco.

Tu monitorización dice verde

Piensa en qué vigila hoy tu sistema de monitorización sobre esa máquina. Casi siempre: que el puerto 443 conteste, que la página de inicio devuelva 200, que el certificado no caduque, que el disco no se llene. Con el motor de documentos muerto, las cuatro cosas siguen en verde. Nextcloud contesta, la gente entra, los ficheros se sincronizan y el cliente de escritorio no se queja. Lo único que no funciona es abrir un documento en el navegador, y eso casi nunca genera un ticket: genera que alguien lo descargue y lo abra en su portátil, que es lo que hubiera hecho igualmente.

Es el mismo patrón del que ya hemos escrito en otro contexto: el trabajo sale en verde y se ha saltado discos. El verde de un panel no dice que todo funcione; dice que lo que medimos funciona. Nosotros monitorizamos con Zabbix y SmokePing y llevamos años con la misma manía: la alerta útil no vigila la portada, vigila el proceso. Un check que mire si el motor de documentos tiene su socket escuchando no te habría protegido de la CVE —el agujero existe precisamente mientras no hay nadie escuchando— pero te habría dicho una cosa que hoy no sabes: cuántas horas de este mes estuviste en el estado vulnerable.

El parche salió como una versión normal

La cronología:

Durante esos treinta y tres días, quien tenía las actualizaciones al día estuvo protegido. Pero no por una decisión: por casualidad. Nadie podía priorizar un parche que nadie había marcado como urgente. Es el espejo de algo que contamos hace unas semanas —el parche de tu switch llevaba 97 días publicado— y conviene no sacar la lección fácil. La fácil sería «actualiza siempre todo a ciegas». La real tiene matiz: el 24 de septiembre salió la 26.4.402 y, según un usuario recogido por IT-Connect, el servidor CODE dejó de arrancar en instalaciones cuyo open_basedir de PHP-FPM no permite /dev/null. Actualizar a ciegas tampoco es gratis.

Deshabilitar no es desinstalar

El aviso dedica una línea a esto y es la línea más importante para quien tenga prisa: «It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed.» Deshabilitar la app no basta: hay que actualizarla o quitarla.

«Deshabilitado» es un estado que entiende Nextcloud, no el servidor web. El fichero proxy.php sigue en el disco, dentro de la carpeta que Apache o nginx sirven, y sigue siendo un PHP ejecutable al que se puede llegar por URL. Quien pide ese fichero no pasa por la lógica de apps de Nextcloud: pasa por el intérprete de PHP. El interruptor del panel de administración apaga la app para tus usuarios, no para internet.

Si ya te pasó

Los informes públicos de los administradores afectados y la cobertura técnica coinciden en qué mirar. Nosotros no hemos respondido a ninguno de estos incidentes, así que lo pasamos tal cual, con su procedencia: ficheros con nombre shx*.php o shrf*.php (en el informe público aparecen shxa35d0.php y shrf4645.php) dentro de apps/richdocumentscode, y en los registros de acceso peticiones a proxy.php?status desde el 10 de septiembre cuya ruta contenga %2e%2e, $( o ${IFS}. Como direcciones asociadas a la actividad se citan 139.28.18.122 y 89.38.98.50.

Lo que buscaron después dice bastante de quién estaba al otro lado y de por qué esto no es un problema «de ficheros»: bases de datos de contraseñas (.kdbx), carpetas de gestores de credenciales, carteras de criptomonedas (wallet.dat, keystore.json). Un servidor de ficheros de empresa es, de hecho, el sitio donde la gente guarda el fichero del gestor de contraseñas «mientras» cambia de portátil. Ya tratamos esa misma lección con otra herramienta autoalojada: el panel de datos que también era el llavero. Si encuentras algo, el orden no es «borrar el webshell y seguir»: es rotar credenciales, porque el acceso duró lo que duró y tú no sabes cuánto.

Cuándo esto no es tu problema

Lo decimos pronto y claro, porque la alternativa es que alguien pase la tarde buscando un fallo que no tiene. Afecta solo a la app opcional del servidor CODE integrado. No afecta a un servidor de Collabora Online montado aparte —ni en Docker, ni con paquetes de Linux, ni alojado por un tercero— ni al despliegue Nextcloud All-in-One, ni a Nextcloud Office si nunca instalaste esa app. Si tu instalación está en una de esas casillas, cierra la pestaña: hoy no te toca.

Y una cosa que tampoco vamos a afirmar: cuántos servidores hay expuestos. No lo hemos medido y no hay cifra pública: el número de servidores afectados es desconocido, y la prensa especializada dice haber preguntado a Nextcloud sin llegar a publicar respuesta. Tampoco está, a día de hoy, en el catálogo de vulnerabilidades explotadas de CISA: lo hemos comprobado contra la versión 2026.10.16 del catálogo, 1.748 entradas, y la CVE-2026-110447 no aparece. Ese catálogo nunca le ha impuesto fechas a una empresa española —obliga a las agencias federales estadounidenses—, pero es el termómetro que casi todo el mundo mira. Aquí no marca nada. Solo el aviso del fabricante y el hecho de que ya se esté usando.

Lo que haríamos esta semana

1. Averiguar si la tienes, antes que nada. La pregunta no es «¿usamos Nextcloud?», es «¿está instalada la app del servidor CODE integrado y en qué versión?». Son dos preguntas distintas y la segunda casi nunca tiene dueño.
2. Actualizar a 26.4.303 o superior, o quitarla. Si nadie edita documentos en el navegador —y en muchas casas nadie lo hace—, quitarla es la opción buena: menos superficie y una app menos que mantener. Deshabilitarla no cuenta.
3. Mirar atrás en los registros hasta el 10 de septiembre buscando los patrones de arriba, y en el directorio de la app los ficheros que no pusiste tú. Si aparece algo, esto deja de ser una actualización y pasa a ser un incidente con rotación de credenciales.
4. Añadir un check del proceso, no de la portada. Que la monitorización sepa distinguir «la web contesta» de «todos los servicios de la web están arriba». Esto no arregla la CVE: arregla que la próxima caída silenciosa la veas tú antes que nadie.
5. Y la pregunta que generaliza esto a todo tu parque: ¿qué otros servicios tienes que arrancan solos, bajo demanda, cuando alguien los pide? Esos tienen un estado «parado» que nadie ha revisado nunca. Este fallo no es sobre Nextcloud: es sobre arrancar cosas al vuelo con datos que vienen de fuera.

Lo que hacemos nosotros, y lo que no afirmamos

No somos resellers de ninguna plataforma concreta y esto no es un argumento contra el software autoalojado: nosotros lo usamos. Operamos contenedores en producción con Docker Swarm y Kubernetes, con despliegues reproducibles y reversibles desde GitLab, y tenemos herramientas autoalojadas en nuestro propio día a día —n8n, por ejemplo— tratadas como lo que son: servicios de producción, inventariados, con dueño y con ventana de actualización. La diferencia entre un servidor de documentos propio y un problema no está en si es autoalojado; está en si alguien tiene escrito, en algún sitio, que esa pieza existe y de quién es. Eso es la mitad del mantenimiento informático que de verdad sirve.

Y lo que no afirmamos: no hemos ejecutado el exploit, no hemos respondido a ninguno de estos incidentes y no sabemos cuántos sistemas hay afectados. Los indicadores de arriba son de los informes públicos, no de nuestra telemetría.

Fuentes (consultadas el 17-10-2026): la frase «The attack only works while the built-in CODE server is not running. So on a container restart, an upgrade, or after a crash», la frase «It is not sufficient to disable the app to avoid the problem, it must be upgraded to >= 26.4.303 or removed», la puntuación 9,2 con su vector completo y la versión corregida salen del aviso de seguridad de Collabora Online (GHSA-g3vx-3m76-fghh, 14-10-2026). La clasificación CWE-78 y el «as exploited in the wild in September and October 2026», de la ficha de la CVE-2026-110447 en la base de avisos de GitHub. La fecha y el título del commit del 9 de septiembre, las horas de los dos primeros ataques documentados (10-09 19:51 y 11-09 09:56), la versión 26.4.302 de las víctimas, la salida de la 26.4.303 el 11 de septiembre sin mención de seguridad, los problemas de arranque de la 26.4.402 en algunas configuraciones de PHP-FPM, las direcciones IP y los patrones de registro, de IT-Connect (15-10-2026). Los patrones de webshell shx*.php y shrf*.php y la búsqueda posterior de bases de contraseñas, carpetas de gestores de credenciales y carteras de criptomonedas, de IT-Connect y Security Online; los nombres de fichero concretos y las marcas de tiempo, del hilo público donde los administradores afectados lo reportaron. Que no hay cifra de sistemas afectados y que se preguntó por ella a Nextcloud, de BleepingComputer. La ausencia en el catálogo de vulnerabilidades explotadas de CISA la hemos comprobado nosotros contra la versión 2026.10.16 del catálogo (1.748 entradas). Nuestro, y lo acotamos: la lectura del AT:P como condición que produce tu propio calendario de cambios, el argumento de por qué deshabilitar no basta, lo de la monitorización en verde, los cinco pasos y el encuadre del «cuándo no es tu problema» (el alcance exacto de lo no afectado es del aviso y de BleepingComputer).