Vulnerabilidades en LibreOffice y OpenOffice permiten la ejecución silenciosa de código a través de hojas de cálculo

Investigadores de seguridad han identificado vulnerabilidades críticas en LibreOffice y Apache OpenOffice que permiten que hojas de cálculo maliciosas ejecuten código arbitrario inmediatamente al abrirse. El fallo evade las advertencias estándar de seguridad de macros, lo que supone un riesgo significativo para los usuarios que dependen de estas suites ofimáticas de código abierto para el manejo diario de documentos.

Qué ha ocurrido

La vulnerabilidad explota la forma en que ambas aplicaciones gestionan fuentes de datos externas dentro de los archivos de hoja de cálculo. Concretamente, aprovecha una función llamada "rango de base de datos", que permite a un bloque de celdas extraer y actualizar automáticamente datos de una fuente externa. En este escenario de ataque, la hoja de cálculo contiene una referencia a un archivo de base de datos externo, conocido como ODB, alojado en una dirección web controlada por el atacante. Cuando el usuario abre la hoja de cálculo, la aplicación descarga automáticamente este archivo ODB.

El archivo ODB descargado especifica luego un controlador de base de datos Java, o driver JDBC, y apunta a un archivo JAR que contiene el código del atacante. La suite ofimática procede a descargar este archivo JAR y ejecuta el controlador dentro de la propia aplicación. Dado que cada paso utiliza funciones legítimas destinadas a la conectividad de datos, el software no activa las habituales solicitudes de seguridad que aparecen al ejecutar macros. Esta cadena de eventos resulta en la ejecución silenciosa de código, otorgando al atacante el control total sobre el contexto de la aplicación.

Aunque la prueba de concepto demostrada por los investigadores solo abrió la aplicación Calculator como una prueba inofensiva, el mismo mecanismo puede ejecutar cualquier código Java que elija el atacante. El ataque funciona tanto en sistemas Windows como Linux, siempre que el soporte de Java esté habilitado en la configuración de la suite ofimática. Los investigadores señalaron que, en un escenario real, los archivos maliciosos de base de datos y código estarían alojados en servidores remotos controlados por el atacante, en lugar de localmente como se mostró en la demostración.

Detalles clave

• LibreOffice ha publicado correcciones para CVE-2026-63277 en las versiones 26.2.5 y 26.8.0, disponibles desde el 5 de octubre.
• Apache OpenOffice sigue siendo vulnerable con CVE-2026-59265 afectando a todas las versiones hasta la 4.1.16 inclusive.
• Se espera una corrección para Apache OpenOffice en la versión 4.1.17, que actualmente está en fase de pruebas.
• El ataque requiere que el soporte de Java esté habilitado en la configuración de la aplicación para funcionar.
• No existen reportes de explotación activa en entornos reales todavía; los hallazgos se basan en demostraciones de prueba de concepto.
• Deshabilitar Java o evitar hojas de cálculo de fuentes no confiables son las principales medidas de mitigación para los usuarios de OpenOffice hasta que se publique un parche.

Contexto

Para entender esta vulnerabilidad, ayuda saber cómo las suites ofimáticas modernas gestionan los datos dinámicos. Funciones como los rangos de bases de datos están diseñadas para mantener las hojas de cálculo actualizadas con información en vivo de bases de datos externas. Esto es útil para la inteligencia empresarial y los informes, pero introduce complejidad en la forma en que la aplicación confía en recursos externos. Normalmente, el software ofimático trata las macros—scripts incrustados en documentos—como de alto riesgo y requiere permiso explícito del usuario para ejecutarlas. Sin embargo, las funciones de conectividad de datos suelen tratarse como de menor riesgo porque se consideran herramientas pasivas de recuperación de datos.

Java juega un papel central en esta explotación porque tanto LibreOffice como OpenOffice lo utilizan para diversas operaciones backend, incluida la conectividad de bases de datos. Los drivers JDBC son componentes estándar que permiten a las aplicaciones Java interactuar con bases de datos. Al encadenar la actualización automática de un rango de base de datos con la carga de un driver JDBC personalizado, los atacantes pueden evadir por completo el modelo de seguridad de macros. Esto destaca un desafío común de seguridad: las funciones individuales pueden ser seguras por separado, pero su interacción puede crear superficies de ataque inesperadas.

Por qué importa

Para equipos que alojan su propia infraestructura o dependen de herramientas de código abierto por razones de costo y control, este incidente subraya la importancia de una gestión puntual de parches. Los usuarios de LibreOffice que actualizan rápidamente están protegidos, pero aquellos que gestionan flotas de máquinas deben asegurarse de que todos los endpoints reciban las nuevas versiones. Retrasar las actualizaciones deja a las organizaciones expuestas a posibles ataques de ejecución remota de código, lo que podría derivar en robo de datos o compromiso del sistema.

Los usuarios de Apache OpenOffice enfrentan una situación más difícil ya que no hay parche disponible actualmente. Muchas pequeñas empresas y sistemas heredados aún dependen de OpenOffice debido a la costumbre o requisitos específicos de compatibilidad. Estos usuarios deben configurar activamente su software para mitigar el riesgo, como deshabilitar el soporte de Java. Esta solución alternativa puede romper funcionalidad legítima que depende de Java, forzando a los gestores de TI a equilibrar la seguridad frente a las necesidades operativas. También sirve como recordatorio para evaluar si continuar usando software con ciclos de lanzamiento más lentos es sostenible para entornos conscientes de la seguridad.

Además, esta vulnerabilidad afecta tanto a entornos Windows como Linux, disipando la noción de que los escritorios Linux son inmunes a tales amenazas. Dado que muchos servidores y estaciones de trabajo de desarrollo ejecutan Linux, los administradores deben verificar que sus instalaciones de LibreOffice estén actualizadas. La naturaleza multiplataforma del fallo significa que las políticas de seguridad no pueden ser específicas del SO; deben abordar la capa de aplicación de manera consistente en todos los dispositivos.

Qué puedes hacer

• Actualiza LibreOffice inmediatamente a la versión 26.2.5 o 26.8.0 para aplicar la corrección para CVE-2026-63277.
• Si usas Apache OpenOffice, deshabilita el soporte de Java en la configuración de la aplicación para evitar que el exploit se ejecute.
• Evita abrir hojas de cálculo de fuentes no confiables, especialmente aquellas que solicitan conexiones de datos externas.
• Monitorea el lanzamiento de Apache OpenOffice 4.1.17 y planifica la actualización tan pronto como esté disponible.