LibreOfficeとOpenOfficeに脆弱性、悪意あるスプレッドシートがマクロ警告なしでコードを実行

LibreOfficeはJavaコード実行の脆弱性を修正しました。一方、Apache OpenOfficeは未修正のままです。研究者らは、悪意あるスプレッドシートがマクロのセキュリティ警告を回避できることを実証しています。

悪意あるスプレッドシートを使うと、LibreOffice CalcとApache OpenOffice Calcで、通常のマクロ警告を表示させずにJavaコードを実行できます。

この脆弱性はCVE-2026-63277とCVE-2026-59265として管理されています。Java連携が有効な環境で、細工したドキュメントを開くと、攻撃者が用意したコードが実行されます。LibreOfficeは修正版をリリースしましたが、Apache OpenOfficeはバージョン4.1.16まで脆弱なままです。

研究者らは手法を公開して実証しています。ただし、実環境での悪用は確認されていません。この攻撃は、ユーザーにマクロ実行の承認を求める方法ではなく、スプレッドシートのデータベース接続を悪用します。

悪意あるスプレッドシートがJavaコードを実行する仕組み

The Document Foundationは10月5日のセキュリティアドバイザリで、LibreOffice Calcが外部スプレッドシートのデータ接続を通じて、リモートの場所からJavaデータベースドライバーを読み込める問題を公表しました。

細工したスプレッドシートは、リモートのOpenDocument Database（ODB）ファイルを参照できます。このファイルには、攻撃者が管理するJavaアーカイブからJava Database Connectivity（JDBC）ドライバーを読み込むよう設定されています。ドキュメントを開くと、マクロのセキュリティ警告が表示されないまま、Javaコードが実行される恐れがあります。

この脆弱性は、V12 SecurityのRick de Jager氏と、Codean LabsのThomas Rinsma氏およびEdoardo Geraci氏がそれぞれ独立して報告しました。公開された概念実証（PoC）では、無害なペイロードとして電卓アプリを起動し、コード実行を示しています。

この攻撃が成立するには、Java連携が有効になっている必要があります。タイの Computer Emergency Response Teamも10月7日にこの脆弱性に関する情報を公開しました。WindowsとLinuxの両方でPoCの検証に成功したと報告しています。

今回の問題は、信頼できないファイルが脆弱なソフトウェアに到達することへの懸念をさらに強めるものです。最近では、業務文書を装ったフィッシングの誘いや、ファイル処理ソフトウェアを狙った悪意あるHEIFファイルのアップロードといった事例がありました。攻撃手法こそ異なりますが、信頼できないコンテンツがもたらすリスクを同様に浮き彫りにしています。

LibreOfficeは修正済み、OpenOfficeの修正は未提供

LibreOfficeは、バージョン26.2.5と26.8.0でCVE-2026-63277を修正しました。このアップデートでは、JavaのクラスパスをファイルURLのみに制限し、リモートからドライバーを読み込む仕組みを遮断しています。

Apache OpenOfficeはセキュリティアドバイザリで、CVE-2026-59265の深刻度を「重大（critical）」と評価し、バージョン4.1.16以前が影響を受けるとしています。バージョン4.1.17は、2026年10月8日時点でリリース候補の段階にあります。

Apacheは、ツール > オプション > OpenOffice > JavaからJava連携を無効にし、Javaランタイム環境を使用するの選択を外すよう推奨しています。Javaを無効にできない組織は、信頼できないドキュメントを開かないようにしてください。

なお、別件のWordPressのリモートコード実行の脆弱性でも、エクスプロイトが公開されています。この例からも、公表された脆弱性は攻撃者に悪用される前に対処することが重要だとわかります。

組織は次の対策も講じるべきです。

• 影響を受けるアプリケーションにパッチを適用：修正版のLibreOfficeを展開し、インストール状況を確認したうえで、OpenOffice 4.1.17の公開を追跡する。
• 不要なJava機能を無効化：業務上の要件が許す範囲で、Java連携をオフにし、使っていないランタイムを削除する。
• 信頼できないドキュメントとネットワークアクセスを制限：不審な添付ファイルをフィルタリングし、外部のスプレッドシートを隔離したうえで、外向きの接続を制限する。
• 最小権限のアクセスを徹底：権限を制限し、対応環境ではアプリケーションのホワイトリスト制御を適用する。ドキュメントを自動処理するワークロードも隔離する。
• 不審な動きを監視：オフィスアプリケーションに関連する、想定外のJava実行や外向きのネットワーク接続を調査する。
• インシデント対応計画をテスト：ドキュメントを介した攻撃に備え、エンドポイントの隔離、証拠の保全、復旧の手順を訓練する。

Apacheが修正版を公開するまでは、Java連携の無効化が、この攻撃経路に対する最も直接的な防御策です。そのほかの対策で被害のリスクは抑えられますが、パッチ適用の代わりにはなりません。

関連記事：悪意あるChatGPTのGPTsを使ったClickFixキャンペーンでは、ソフトウェアの脆弱性を突かなくても、ユーザーをだましてマルウェアを実行させられることがわかります。