Una hoja de cálculo maliciosa puede hacer que LibreOffice Calc o Apache OpenOffice carguen y ejecuten código Java controlado por un atacante al abrir el archivo, según una prueba de concepto publicada recientemente.
La técnica aprovecha la compatibilidad de las suites ofimáticas con fuentes de bases de datos externas y controladores Java Database Connectivity. No depende de una macro convencional del documento y, según los investigadores, la vía de ejecución probada no mostró la advertencia de confianza de macros que los usuarios podrían esperar.
Para que el ataque funcione, debe estar habilitada la compatibilidad con Java. Los investigadores demostraron la técnica en Windows y Linux, lo que indica que la exposición no se limita a un solo sistema operativo.
Hay dos vulnerabilidades relacionadas con este problema: CVE-2026-63277, en LibreOffice Calc, y CVE-2026-59265, en Apache OpenOffice. Ya hay actualizaciones de LibreOffice disponibles, mientras que, según la información publicada, la versión corregida de OpenOffice sigue en fase de pruebas.
Los enlaces a bases de datos externas abren la puerta a la ejecución de código
La cadena de ataque combina funciones legítimas de hojas de cálculo, bases de datos e integración con Java.
Los documentos de Calc pueden incluir rangos de base de datos que importan información de una fuente externa. El enlace queda guardado en la hoja de cálculo, lo que permite que la aplicación recupere y actualice los datos vinculados al abrir el documento.
En el escenario de los investigadores, la hoja de cálculo apunta a un archivo OpenDocument Database (ODB) externo mediante una dirección web. Una vez descargado el archivo, la suite ofimática procesa su configuración de base de datos.
El ODB puede especificar un controlador JDBC y una ubicación desde la que cargar sus clases Java. Esa ubicación puede apuntar a un archivo JAR alojado de forma remota. La aplicación descarga e inicia entonces el controlador, lo que hace que su código Java se ejecute dentro del proceso de la suite ofimática.
Esta secuencia permite que un atacante pase de un documento manipulado a la ejecución de código Java arbitrario:
- El usuario abre una hoja de cálculo maliciosa.
- El documento actualiza un rango de base de datos integrado.
- La aplicación recupera un archivo ODB al que apunta la hoja de cálculo.
- El ODB especifica un controlador JDBC y la ubicación de su código.
- La aplicación carga el controlador y ejecuta su código Java.
En su demostración inocua, los investigadores aprovecharon esta capacidad de ejecución de código para abrir la aplicación Calculadora. Los archivos de prueba de concepto se guardaron localmente por comodidad, pero los investigadores señalaron que un atacante podría alojar el archivo de base de datos y la carga Java en una infraestructura bajo su control.
La acción decisiva del usuario es abrir el documento. Según el informe, esta vía no requiere que la víctima autorice una macro mediante la advertencia descrita en el informe original.
LibreOffice corrige CVE-2026-63277 en dos ramas
Según el artículo, la vulnerabilidad de LibreOffice afecta a las versiones anteriores a 26.2.5 o 26.8.0. Se recomienda actualizar a 26.2.5 o 26.8.0, según la rama instalada.
El informe indica que las actualizaciones con la corrección se publicaron el 5 de octubre, pero no especifica el año. El material proporcionado tampoco incluye una fecha aparte para el descubrimiento o la divulgación pública.
La descripción de CVE-2026-63277 de NVD se centra en que un rango de celdas de Calc puede mantener un vínculo con una fuente de datos externa dentro del documento. Un archivo malicioso puede usar ese enlace para indicar un controlador de base de datos Java cuyo código esté alojado de forma remota.
La corrección restringe las entradas de la ruta de clases de Java. En las versiones corregidas de LibreOffice, esas entradas deben usar una URL de archivo, lo que impide la carga remota que hace posible el ataque demostrado.
CVE-2026-63277 está clasificada como CWE-829, que abarca las funciones importadas desde fuera del ámbito de control previsto sin las medidas de protección adecuadas.
El problema de LibreOffice fue reportado de forma independiente por Rick de Jager, del equipo de seguridad V12, y por Thomas Rinsma y Edoardo Geraci, de Codean Labs. Caolán McNamara, de Collabora Productivity, desarrolló la corrección para LibreOffice.
Los usuarios de Apache OpenOffice esperan la versión 4.1.17
Apache OpenOffice 4.1.16 y versiones anteriores están afectadas por CVE-2026-59265. NVD describe el fallo como un problema de integración con Java que permite que un documento no confiable ejecute código arbitrario —incluido código obtenido de forma remota— cuando el usuario lo abre.
La corrección prevista es Apache OpenOffice 4.1.17. Sin embargo, el material disponible sitúa esa versión en la fase de candidata a lanzamiento y no indica que ya se haya publicado como versión definitiva.
Hasta que esté disponible la versión 4.1.17, NVD recomienda desactivar Java runtime integration en el cuadro de diálogo de preferencias. Según la descripción de la vulnerabilidad, esto impide el ataque.
Si no es posible desactivar la integración con Java, o como medida adicional, se recomienda no abrir archivos de fuentes no confiables. Cuando se publique la versión definitiva 4.1.17, habrá que actualizar las instalaciones afectadas.
CVE-2026-59265 está clasificada como CWE-426, que abarca las rutas de búsqueda no confiables. Codean Labs figura como responsable de reportar la vulnerabilidad de OpenOffice, mientras que el equipo V12 publicó una prueba de concepto que afecta a ambas suites ofimáticas.
El ataque requiere Java, pero no la aprobación de una macro
La consecuencia inmediata es la ejecución de código con los permisos de la cuenta que ejecuta la suite ofimática. Un atacante podría usar código Java distinto de la carga inocua que abre la Calculadora en la demostración.
Para que la técnica funcione, deben cumplirse varias condiciones. La víctima debe recibir y abrir el documento manipulado, y la compatibilidad con Java debe estar activa en la suite ofimática afectada. Después, la aplicación debe procesar las referencias a la base de datos externa y al controlador incluidas en la cadena de ataque.
La ausencia de la advertencia de confianza de macros descrita cambia las precauciones que gli utenti potrebbero adottare con le hojas de cálculo sospechosas. Quien espere que el contenido potencialmente ejecutable active una advertencia convencional sobre macros podría no recibir ese aviso por esta vía.
La prueba de concepto se probó tanto en Windows como en Linux. Esto demuestra que la técnica puede funcionar en distintas plataformas en los entornos de prueba de los investigadores, pero no confirma que todas las configuraciones de ambos sistemas operativos se vean afectadas de la misma manera.
Según la información publicada, no se conocen ataques que estén explotando estas vulnerabilidades. Se trata de una afirmación de la investigación publicada, no de una confirmación independiente de que nunca se hayan producido ataques.
Los extractos disponibles de NVD no incluyen una puntuación ni un vector CVSS para ninguna de las dos vulnerabilidades. Tampoco indican si aparecen en el catálogo Known Exploited Vulnerabilities de CISA ni incluyen una fecha límite para aplicar medidas correctivas. Estas omisiones no deben interpretarse como prueba de que los CVE no figuren en el catálogo KEV.
Qué deben hacer administradores y usuarios
Los administradores de LibreOffice deben comprobar la rama exacta instalada y actualizar los sistemas que ejecuten versiones afectadas a 26.2.5 o 26.8.0. La corrección modifica el tratamiento de las rutas de clases Java para que las entradas pertinentes deban ser URL de archivo.
OpenOffice plantea un problema operativo distinto, ya que 4.1.17 sigue descrita como candidata a lanzamiento. Para las instalaciones que continúen en 4.1.16 o versiones anteriores, desactivar Java runtime integration es la medida provisional concreta que recomienda NVD.
Las organizaciones que necesiten las funciones de Java deberían aplicar controles más estrictos al manejo de documentos hasta que se publique la versión corregida de OpenOffice. En particular, los usuarios no deberían abrir hojas de cálculo ni documentos inesperados procedentes de fuentes cuya legitimidad no puedan verificar.
Los equipos de seguridad también pueden revisar si necesitan la integración con Java en las instalaciones ofimáticas que administran. Eliminar una dependencia del entorno de ejecución que no sea necesaria reduce la exposición a esta cadena de ataque concreta, aunque no sustituye la instalación del software corregido cuando ya hay un parche disponible.
La diferencia principal es clara: según la información publicada, los usuarios de LibreOffice ya pueden instalar versiones corregidas, mientras que los de OpenOffice deben aplicar la medida de mitigación indicada hasta que 4.1.17 se publique como versión definitiva.
