La vulnerabilidad de SeaDoc abre la ejecución de código a quien tenga un enlace público de un documento: sin cuenta, sin contraseña y sin que nadie pulse nada raro. El registro CVE-2026-129167, publicado el 13 de noviembre, le asigna una puntuación CVSS 4.0 de 9,2, la franja crítica, y el fallo vive en el convertidor de SeaDoc, el editor de documentos de Seafile.

Basta abrir un enlace público de un archivo .sdoc, el formato de documento de SeaDoc, o una wiki publicada, y leer en el código de esa página el token anónimo que el sistema incrusta para que la vista previa funcione. Ese token, pensado solo para mirar un documento, termina aceptado en funciones que escriben archivos dentro del servidor.

Las versiones afectadas están acotadas: SeaDoc 2.0.4 a 2.0.10 y SeaDoc 3.0.0 a 3.0.7. La corrección llegó en las versiones 2.0.11 y 3.0.8, y las imágenes actuales que cita la investigación, 2.0.13 y 3.0.9, ya la traen.

Un nombre de archivo que sale de su carpeta



La cadena completa quedó documentada por Ostorlab, que publicó la investigación del fallo y reprodujo el ataque en un laboratorio con la instalación oficial. El convertidor revisa el token con una función que comprueba la firma y nada más: no mira el documento para el que fue emitido ni el permiso que lleva dentro. El token de lectura, con ese chequeo tan corto, pasa la puerta de todos los servicios del convertidor, incluido el importador de páginas de Confluence.

Ese importador recibe un nombre de archivo y arma la ruta con una función de Python que une carpetas. Cuando el segundo tramo empieza con una barra, Python descarta el primero entero: la extracción debía quedarse en /tmp/wiki y, con un nombre absoluto, escribe en la carpeta que elija el atacante.

La limpieza de los archivos corre al cerrar el proceso, y ese cierre espera una respuesta de subida que nunca llega si el servidor del atacante acepta la conexión y calla. Con la subida colgada, los archivos quedan en disco. Una segunda petición con un juego de caracteres concreto, cp273, obliga al intérprete a importar ese módulo y el código plantado se ejecuta en el proceso del convertidor, que en el contenedor oficial trabaja como root, el usuario con control total. La prueba lo dejó escrito con un marcador que devolvió uid=0 (root).

Con código en el convertidor se pueden leer y tocar los documentos a los que ese servicio llega, y entre sus datos de configuración está la clave compartida JWT_PRIVATE_KEY, la llave HMAC (código de autenticación de mensajes) con la que SeaDoc firma sus tokens. Corgea, que revisó el registro del CVE el 14 de noviembre, lo resume en la misma línea: un token de solo lectura acabó con permiso real para escribir.

No hay explotación conocida: ni Ostorlab ni el registro del CVE reportan ataques reales, y la falla no aparecía al 14 de noviembre en el catálogo KEV de la CISA (la agencia de ciberseguridad de Estados Unidos), que reúne las vulnerabilidades con explotación confirmada. La demostración es de laboratorio y el código corre en el contenedor del convertidor, no en el servidor que aloja todo Seafile. Es el mismo patrón de fondo de otro CVE reciente de puntuación alta: un servicio expuesto que procesa entradas de fuera con más confianza de la debida.

Parche publicado y revisión en cuatro puntos



La investigación se publicó el 24 de octubre. El arreglo del convertidor de código abierto llegó el 29 de octubre: rechaza cualquier nombre de archivo que no sea texto terminado en .html.zip, o que lleve barras, contrabarras o un byte nulo. Haiwen, la empresa detrás de Seafile, comunicó el 2 de noviembre que el componente cerrado sdoc-server también quedó corregido, y el CVE se publicó el 13 de noviembre a las 17:21 UTC.

Actualizar significa subir a SeaDoc 2.0.11 o 3.0.8, o a las imágenes actuales 2.0.13 y 3.0.9, y recrear los contenedores: descargar la imagen sin recrear deja corriendo el proceso viejo, con el fallo intacto. Quien no pueda actualizar tiene una salida parcial: bloquear el convertidor en el proxy inverso, retirar los enlaces públicos .sdoc que no hagan falta y despublicar las wikis. Esa salida corta la ruta del token anónimo; no arregla la salida de ruta en el código.

La revisión de una instalación expuesta tiene puntos concretos: buscar en los registros las peticiones POST al importador con nombres que empiecen con barra o lleven puntos dobles, y las conversiones cuya dirección de subida apunte fuera de la propia infraestructura. Dentro del contenedor, el directorio encodings no debe tener paquetes que nadie instaló, con atención a carpetas con nombre de códec como cp273. Ostorlab advierte un límite honesto: una petición que falla antes de extraer puede no dejar rastro.

Queda un detalle que define el caso: el token anónimo sigue existiendo porque la vista previa pública lo necesita. La diferencia entre una instalación sana y una abierta es qué puede hacer ese token cuando llega a un servicio que escribe. En las versiones corregidas, mirar un documento ya no alcanza para plantar código en el servidor que lo muestra.

Fuente: Ostorlab