Un tableur malveillant peut amener LibreOffice Calc ou Apache OpenOffice à charger et à exécuter du code Java contrôlé par un attaquant à l’ouverture du fichier, selon une preuve de concept publiée récemment.
Cette technique exploite la prise en charge des sources de bases de données externes et des pilotes Java Database Connectivity par les suites bureautiques. Elle ne repose pas sur une macro classique et, d’après les chercheurs, le scénario d’exécution testé ne déclenchait pas l’avertissement relatif à la confiance accordée aux macros auquel les utilisateurs pourraient s’attendre.
La prise en charge de Java doit être activée pour que l’attaque fonctionne. Les chercheurs ont démontré la technique sous Windows et Linux : l’exposition ne se limite donc pas à un seul système d’exploitation.
Deux vulnérabilités sont en cause : CVE-2026-63277 dans LibreOffice Calc et CVE-2026-59265 dans Apache OpenOffice. Des mises à jour de LibreOffice sont disponibles, tandis que la version corrigée d’OpenOffice est encore en phase de test, selon les informations publiées.
Des liens vers des bases de données externes ouvrent la voie à l’exécution de code
La chaîne d’attaque combine des fonctionnalités légitimes d’intégration entre les tableurs, les bases de données et Java.
Les documents Calc peuvent contenir des plages de bases de données qui importent des informations depuis une source externe. Le lien est enregistré dans le tableur, ce qui permet à l’application de récupérer et d’actualiser les données liées à l’ouverture du document.
Dans le scénario des chercheurs, le tableur désigne une base de données externe au format OpenDocument Database (ODB) à l’aide d’une adresse web. Une fois le fichier récupéré, la suite bureautique traite sa configuration de base de données.
L’ODB peut spécifier un pilote JDBC ainsi qu’un emplacement depuis lequel charger les classes Java de ce pilote. Cet emplacement peut pointer vers un fichier JAR hébergé à distance. L’application récupère alors le pilote et le lance, ce qui exécute son code Java dans le processus de la suite bureautique.
Cette séquence permet à un attaquant de passer d’un document piégé à l’exécution de code Java arbitraire :
- L’utilisateur ouvre un tableur malveillant.
- Le document actualise une plage de base de données intégrée.
- L’application récupère un fichier ODB référencé dans le tableur.
- L’ODB indique un pilote JDBC et l’emplacement de son code.
- L’application charge le pilote et exécute son code Java.
Pour leur démonstration sans danger, les chercheurs ont utilisé cette capacité d’exécution de code pour ouvrir l’application Calculatrice. Par commodité, les fichiers de preuve de concept étaient stockés localement, mais les chercheurs précisent qu’un attaquant pourrait héberger le fichier de base de données et la charge utile Java sur une infrastructure sous son contrôle.
L’action déterminante de l’utilisateur consiste à ouvrir le document. Selon le scénario décrit, il n’est pas nécessaire que la victime approuve une macro via l’avertissement évoqué dans le rapport d’origine.
LibreOffice corrige CVE-2026-63277 dans deux branches de version
Selon l’article, la vulnérabilité de LibreOffice touche les versions antérieures à 26.2.5 ou à 26.8.0. Il est conseillé aux utilisateurs de passer à la version 26.2.5 ou 26.8.0, selon la branche installée.
Le rapport indique que les mises à jour contenant le correctif sont sorties le 5 octobre, sans préciser l’année. Les informations fournies ne donnent pas de date distincte pour la découverte ou la divulgation publique de la vulnérabilité.
La description de CVE-2026-63277 par la NVD porte sur la possibilité, pour une plage de cellules Calc, de rester liée à une source de données externe dans le document. Un fichier malveillant peut exploiter ce lien pour désigner un pilote de base de données Java dont le code est hébergé à distance.
Le correctif restreint les entrées du chemin de classes Java. Dans les versions corrigées de LibreOffice, ces entrées doivent utiliser une URL de fichier, ce qui empêche le chargement à distance au cœur de l’attaque démontrée.
CVE-2026-63277 est classée CWE-829, qui concerne les fonctionnalités importées depuis un environnement extérieur au périmètre de contrôle prévu sans mesures de protection suffisantes.
La vulnérabilité de LibreOffice a été signalée indépendamment par Rick de Jager, de l’équipe de sécurité V12, et par Thomas Rinsma et Edoardo Geraci, de Codean Labs. Caolán McNamara, de Collabora Productivity, a développé le correctif pour LibreOffice.
Les utilisateurs d’Apache OpenOffice attendent la version 4.1.17
Apache OpenOffice 4.1.16 et les versions antérieures sont touchés par CVE-2026-59265. La NVD décrit une faille liée à l’intégration de Java, par laquelle un document non fiable peut provoquer l’exécution de code arbitraire — y compris du code récupéré à distance — à son ouverture par l’utilisateur.
Le correctif est prévu dans Apache OpenOffice 4.1.17. Toutefois, les informations disponibles indiquent que cette version est encore en phase de version candidate et ne précisent pas qu’elle a fait l’objet d’une publication définitive.
En attendant la disponibilité de la version 4.1.17, la NVD conseille aux utilisateurs de désactiver Java runtime integration dans la boîte de dialogue des préférences. Selon la description de la vulnérabilité, cette mesure empêche l’attaque.
Si l’intégration de Java ne peut pas être désactivée, ou par précaution supplémentaire, les utilisateurs devraient éviter d’ouvrir des fichiers provenant de sources non fiables. Dès que la version finale 4.1.17 sera disponible, les installations concernées devront être mises à niveau.
CVE-2026-59265 est classée CWE-426, qui concerne les chemins de recherche non fiables. Codean Labs est crédité du signalement de la vulnérabilité d’OpenOffice, tandis que l’équipe V12 a publié une preuve de concept couvrant les deux suites bureautiques.
Java est nécessaire à l’exploitation, mais pas l’approbation d’une macro
La conséquence immédiate est l’exécution de code dans le contexte de l’application bureautique. Un attaquant pourrait choisir un code Java différent de la charge utile inoffensive qui ouvre la Calculatrice dans la démonstration.
Cette technique est soumise à plusieurs conditions. La cible doit recevoir et ouvrir le document piégé, et la prise en charge de Java doit être activée dans la suite bureautique concernée. L’application doit ensuite traiter les références à la base de données externe et au pilote intégrées à la chaîne d’attaque.
L’absence de l’avertissement décrit concernant la confiance accordée aux macros modifie les réflexes de défense face aux tableurs suspects. Un utilisateur qui s’attend à ce qu’un contenu potentiellement exécutable déclenche un avertissement classique relatif aux macros pourrait ne pas recevoir ce signal avec cette méthode.
La preuve de concept a été testée sous Windows et Linux. Ce résultat démontre la faisabilité multiplateforme dans les environnements de test des chercheurs, mais ne prouve pas que toutes les configurations de ces systèmes d’exploitation sont touchées de la même manière.
Selon les informations publiées, aucune attaque exploitant ces vulnérabilités n’a été recensée dans la nature. Il s’agit d’une déclaration issue des travaux publiés, et non d’une confirmation indépendante qu’aucune exploitation n’a jamais eu lieu.
Les extraits disponibles de la NVD ne fournissent aucun score ni vecteur CVSS pour ces vulnérabilités. Ils ne mentionnent pas non plus de statut dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA ni de délai de remédiation. Ces omissions ne doivent pas être interprétées comme la preuve que les CVE ne figurent pas dans le catalogue KEV.
Mesures à prendre pour les administrateurs et les utilisateurs
Les administrateurs de LibreOffice devraient vérifier précisément la branche installée et mettre à niveau les systèmes qui exécutent une version vulnérable vers 26.2.5 ou 26.8.0. Le correctif modifie le traitement du chemin de classes Java et impose que les entrées concernées soient des URL de fichier.
OpenOffice pose un problème opérationnel différent, puisque 4.1.17 est encore présentée comme une version candidate. Pour les installations qui restent en 4.1.16 ou dans une version antérieure, la désactivation de Java runtime integration constitue la mesure provisoire recommandée par la NVD.
Les organisations qui ont besoin des fonctionnalités Java devraient renforcer les contrôles de traitement des documents jusqu’à la publication de la version corrigée d’OpenOffice. En particulier, les utilisateurs ne devraient pas ouvrir de tableurs ou de documents inattendus provenant de sources qu’ils ne peuvent pas vérifier.
Les équipes de sécurité peuvent également vérifier si l’intégration de Java est nécessaire dans les suites bureautiques gérées. Supprimer une dépendance à l’environnement d’exécution lorsqu’elle est superflue réduit l’exposition à cette chaîne d’attaque, mais ne remplace pas l’installation du logiciel corrigé lorsqu’un correctif est déjà disponible.
La distinction est simple : d’après les informations publiées, les utilisateurs de LibreOffice disposent déjà de versions corrigées, tandis que ceux d’OpenOffice doivent appliquer la mesure d’atténuation indiquée en attendant la publication définitive de 4.1.17.
