Calc de LibreOffice/OpenOffice permite ejecución de código remoto al abrir hojas con ODB/JDBC

Investigadores han demostrado que una hoja de cálculo maliciosa puede obligar a LibreOffice y Apache OpenOffice a ejecutar código controlado por un atacante en el momento en que se abre el archivo, sin mostrar la advertencia de confianza que aparece antes de ejecutar una macro. El vector explota la capacidad de Calc para definir rangos de datos vinculados a bases de datos externas (archivos ODB) y la facultad de cargar controladores JDBC en Java, de modo que la aplicación descarga y arranca un JAR remoto dentro de su propio proceso. LibreOffice ya lanzó una corrección (seguida como CVE-2026-63277) el 5 de octubre; Apache OpenOffice sigue vulnerable en su versión actual 4.1.16 y registra la falla como CVE-2026-59265, con un arreglo previsto para la 4.1.17.

En términos técnicos, el ataque encadena tres funciones legítimas de Calc. Primero, un "database range" puede configurarse para refrescarse automáticamente desde una fuente externa; esa fuente puede ser un archivo ODB cuya ubicación se guarda en la hoja. Segundo, un ODB puede indicar qué controlador de base de datos Java (JDBC) usar y dónde reside su código, normalmente empaquetado en un archivo JAR. Tercero, si el soporte Java está activo en la instalación de LibreOffice/OpenOffice, la suite descarga el JAR y arranca el controlador dentro del mismo proceso de la aplicación. El problema de seguridad no es una función rota, sino la combinación de esas funciones que resulta en ejecución de código sin la comprobación de confianza que se aplica a las macros.

Los investigadores llevaron a cabo una prueba de concepto en Windows y Linux; en ese PoC el "driver" malicioso abría la calculadora del sistema como demostración inocua, pero la misma cadena puede ejecutar cualquier código Java una vez que el JAR se carga. En las demostraciones públicas los archivos residían localmente para facilitar la reproducción, pero los autores señalan que un ataque real colocaría el ODB y los JAR en servidores controlados por el atacante para que la víctima los descargue al abrir la hoja.

Hechos confirmados: LibreOffice corrigió la vulnerabilidad y recomienda actualizar a las versiones 26.2.5 o 26.8.0; Apache OpenOffice reconoce la falla y mantiene todas sus versiones hasta 4.1.16 como afectadas, con una solución prevista en 4.1.17. Los errores fueron reportados por las firmas de investigación citadas (V12 Security y Codean Labs) y la corrección de LibreOffice fue implementada por un desarrollador de Collabora Productivity. No hay, por ahora, informes públicos verificados de que el exploit haya sido usado en ataques reales.

Estimaciones y puntos todavía inciertos: no está claro cuántos usuarios mantienen habilitado el soporte Java en estas suites en entornos de escritorio ni qué fracción de despliegues en empresas podría ser vulnerable por configuración. Tampoco hay pruebas públicas de campañas masivas que estén aprovechando este camino; la disponibilidad de un PoC aumenta la probabilidad de que aparezcan exploits dirigidos, pero la transición de PoC a explotación real depende de factores operativos (por ejemplo, que la víctima abra una hoja de cálculo no confiable y tenga Java habilitado).

¿A quién afecta esto? Principalmente a usuarios y organizaciones que usan LibreOffice o Apache OpenOffice con el soporte Java activado y que abren hojas de cálculo procedentes de orígenes no verificados. Los entornos donde se aceptan archivos ODF/Ods de proveedores externos, equipos de finanzas, administración o cualquier flujo que procese hojas de cálculo recibidas por correo son especialmente relevantes, porque un archivo que a primera vista es una hoja de cálculo puede contener la referencia ODB que desencadena la descarga y carga del JAR malicioso.

Consecuencias reales posibles: ejecución remota de código en el contexto del proceso de la suite ofimática, lo que puede derivar en robo de datos locales, descarga de cargas adicionales, movimiento lateral en redes internas o establecimiento de persistencia si el atacante dispone de privilegios suficientes. Dado que la ejecución se produce dentro del proceso de usuario, los permisos disponibles serán los del usuario que abrió el documento.

Medidas concretas que debe tomar el lector ahora mismo:

1) Actualice si usa LibreOffice. Instale las versiones corregidas indicadas por el proyecto (mencionadas por la propia fundación) o la última versión estable disponible en el sitio oficial: https://www.libreoffice.org. Esa es la defensa definitiva para instalaciones que no puedan prescindir del soporte Java.

2) Si usa Apache OpenOffice y no puede actualizar aún, desactive Java. Abra las opciones del programa y desmarque el uso de un entorno de ejecución Java (JRE). Esto impide que Calc descargue y arranque controladores JDBC externos y bloquea este vector de ataque. La configuración de Java está expuesta en la interfaz de opciones de ambas suites; si no está seguro, contacte con su equipo de TI.

3) No abra hojas de cálculo de origen desconocido o inesperado. Trate con especial cautela archivos recibidos por correo, incluso si proceden de contactos legítimos cuyos sistemas podrían haber sido comprometidos. Cuando necesite analizar un archivo sospechoso, hágalo en una máquina aislada o en una sandbox/VM sin acceso a credenciales corporativas.

4) Reduzca la exposición por red y por proceso. En entornos corporativos, limite la capacidad de la suite ofimática para establecer conexiones salientes mediante reglas de firewall o proxies, y considere políticas que impidan que procesos de oficina descarguen código ejecutable. Aplicaciones como AppArmor o SELinux pueden ayudar a restringir lo que el binario de LibreOffice/OpenOffice puede cargar o ejecutar.

5) Para administradores: actualizar inventario, aplicar mitigaciones y monitorizar. Identifique equipos con Java habilitado en LibreOffice/OpenOffice y priorice actualizaciones o la desactivación de Java. Agregue detección de tráfico inusual a servidores que alojen ODB/JAR remotos y revise los registros de endpoints por procesos que abran conexiones HTTP(S) tras la apertura de documentos ofimáticos.

Para comprender mejor el componente JDBC que permite este abuso puede consultarse la documentación técnica de Oracle sobre JDBC: https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/. Para información oficial y descargas de las suites afectadas, use las páginas de los proyectos: LibreOffice y Apache OpenOffice.

En resumen: la vulnerabilidad no es un fallo de una sola función sino el resultado de la orquestación de mecanismos legítimos que, combinados, permiten ejecutar código sin pedir la confirmación que se exige a las macros. Actualizar LibreOffice o desactivar Java en OpenOffice, junto con buenas prácticas de manejo de documentos y controles de red, son las defensas más eficaces hasta que Apache publique su corrección. Mantendremos la cobertura conforme los proyectos publiquen avisos y parches adicionales.