LibreOffice / OpenOffice Calc permet l'exécution de sources distantes lors de l'ouverture de l'ODB / JDBC

Les chercheurs ont montré qu'un tableur malveillant peut forcer LibreOffice et Apache OpenOffice à exécuter le code contrôlé par un attaquant au moment de l'ouverture du fichier, sans montrer l'avertissement de confiance qui apparaît avant d'exécuter une macro. Le vecteur explore la capacité de Calc à définir des plages de données liées à des bases de données externes (fichier ODB) et la puissance de charger des pilotes JDBC en Java, donc l'application télécharge et démarre un JAR distant dans son propre processus. LibreOffice a déjà publié une correction (suivi sous le nom de CVE-2026-63277) le 5 octobre ; Apache OpenOffice reste vulnérable dans sa version actuelle 4.1.16 et enregistre l'échec sous le nom de CVE-2026-59265, avec un arrangement prévu pour 4.1.17.

En termes techniques, l'attaque relie trois fonctions Calc légitimes. Premièrement, une « plage de base de données » peut être configurée pour être automatiquement rafraîchie à partir d'une source externe; cette source peut être un fichier ODB dont l'emplacement est stocké sur la feuille. Deuxièmement, un ODB peut indiquer quel contrôleur de base de données Java (JDBC) utiliser et où réside votre code, habituellement emballé dans un fichier JAR. Troisièmement, si le support Java est actif dans l'installation LibreOffice / OpenOffice, la suite télécharge le JAR et démarre le contrôleur dans le même processus d'application. Le problème de sécurité n'est pas une fonction cassée, mais la combinaison de ces fonctions qui conduit à l'exécution de code sans le contrôle de confiance qui s'applique aux macros.

Les chercheurs ont effectué un test de concept sur Windows et Linux ; en ce que PoC le "pilote" malveillant a ouvert la calculatrice système comme une démonstration inoffensive, mais la même chaîne peut exécuter n'importe quel code Java une fois le JAR chargé. Dans les manifestations publiques, les fichiers résidaient localement pour faciliter la reproduction, mais les auteurs soulignent qu'une véritable attaque placerait ODB et JAR sur les serveurs contrôlés par l'agresseur à télécharger lors de l'ouverture de la feuille.

Faits confirmés : LibreOffice corrige la vulnérabilité et recommande de mettre à jour les versions 26.2.5 ou 26.8.0; Apache OpenOffice reconnaît la défaillance et maintient toutes ses versions jusqu'à 4.1.16 comme affectées, avec une solution attendue à 4.1.17. Ces erreurs ont été signalées par les entreprises de recherche susmentionnées (V12 Security et Codean Labs) et la correction de LibreOffice a été mise en œuvre par un développeur Collabora Productivité. Pour l'instant, il n'y a pas de rapports publics vérifiés indiquant que l'explosion a été utilisée dans des attaques réelles.

Estimations et points encore incertains: On ne sait pas combien d'utilisateurs maintiennent le support Java activé dans ces suites dans les environnements de bureau et quelle fraction des déploiements dans les entreprises pourrait être vulnérable par configuration. Il n'y a pas non plus de preuves publiques de campagnes de masse qui profitent de cette voie; la disponibilité d'un PoC augmente la probabilité d'exploitations ciblées, mais la transition du PoC à l'exploitation réelle dépend de facteurs opérationnels (par exemple, que la victime ouvre un tableur peu fiable et que Java soit activé).

Qui cela affecte - t - il? Principalement des utilisateurs et des organisations utilisant LibreOffice ou Apache OpenOffice avec le support Java activé et ouvrant des tableurs d'origines non vérifiées. Les environnements où les fichiers ODF/Ods sont acceptés par des fournisseurs externes, du matériel de financement, de la gestion ou tout flux qui traite les feuilles de calcul reçues par courrier sont particulièrement pertinents, car un fichier qui à première vue est un tableur peut contenir la référence ODB qui déclenche le téléchargement et le chargement du JAR malveillant.

Conséquences réelles possibles : exécution de code à distance dans le contexte du processus de suite bureautique, qui peut entraîner le vol de données locales, décharge de charge supplémentaire, mouvement latéral dans les réseaux internes ou l'établissement de persistance si l'attaquant a des privilèges suffisants. Puisque l'exécution se produit dans le processus utilisateur, les autorisations disponibles seront celles de l'utilisateur qui a ouvert le document.

Mesures spécifiques à prendre par le lecteur en ce moment:

1) Mettre à jour si vous utilisez LibreOffice. Installez les versions corrigées indiquées par le projet (mentionnées par la fondation elle-même) ou la dernière version stable disponible sur le site officiel: https: / / www.liberoffice.org. C'est la défense ultime pour les installations qui ne peuvent pas faire sans le support Java.

2) Si vous utilisez Apache OpenOffice et ne pouvez pas encore mettre à jour, désactiver Java. Ouvrez les options du programme et masquez l'utilisation d'un environnement d'exécution Java (JRE). Cela empêche Calc de télécharger et de démarrer des pilotes JDBC externes et bloque ce vecteur d'attaque. La configuration Java est exposée à l'interface des options des deux suites; si vous n'êtes pas sûr, contactez votre équipe informatique.

(3) N'ouvrez pas de tableurs d'origine inconnue ou inattendue. Essayez avec prudence les fichiers reçus par la poste, même s'ils proviennent de contacts légitimes dont les systèmes auraient pu être compromis. Lorsque vous avez besoin d'analyser un fichier suspect, faites-le sur une machine isolée ou sur un bac à sable / VM sans avoir accès aux identifiants d'entreprise.

4) Réduire l'exposition au réseau et au processus. Dans les environnements ministériels, limiter la capacité de la suite bureautique d'établir des connexions sortantes par pare-feu ou par procuration, et envisager des politiques qui empêchent les processus bureautiques de télécharger du code exécutable. Des applications comme AppArmor ou SELinux peuvent aider à limiter ce que le binaire LibreOffice / OpenOffice peut charger ou exécuter.

5) Pour les administrateurs : mettre à jour l'inventaire, appliquer les mesures d'atténuation et de surveillance. Identifier les équipements avec Java activés dans LibreOffice / OpenOffice et prioriser les mises à jour ou la désactivation Java. Ajouter une détection de trafic inhabituelle aux serveurs distants d'hébergement ODB / JAR et examiner les paramètres des enregistrements pour les processus qui ouvrent les connexions HTTP (S) après l'ouverture des documents de bureau.

Afin de mieux comprendre le composant JDBC qui permet cet abus, veuillez consulter la documentation technique d'Oracle sur JDBC: https: / / docs.oracle.com / javase / 8 / docs / techniques / guides / jdbc /. Pour obtenir des renseignements officiels et télécharger les suites touchées, utilisez les pages du projet : Bureau libre et Apache OpenOffice.

Bref, la vulnérabilité n'est pas un échec d'une seule fonction, mais le résultat de l'orchestration de mécanismes légitimes qui, combinés, permettent d'exécuter le code sans demander la confirmation requise des macros. Mettre à jour LibreOffice ou désactiver Java dans OpenOffice, ainsi que les bonnes pratiques de gestion de documents et les contrôles réseau, sont les défenses les plus efficaces jusqu'à ce qu'Apache publie sa correction. Nous conserverons la couverture lorsque les projets publieront des avis et des correctifs supplémentaires.