Apache MINAに乗っ取りの脆弱性 CVE-2026-47065、ログイン無しで悪用
多くのJava製ネットワークアプリの土台で動くApache MINAに、ログイン無しでサーバーを乗っ取られる脆弱性CVE-2026-47065(CVSS9.8)が見つかりました。過去の修正をすり抜ける3度目の穴で、対象は2.2.8・2.1.13・2.0.29への即更新が必要です。

堀川 慎
Backend Engineer / AWS / Django / Go
多くのJava製ネットワークアプリの土台で動くApache MINAに、ログイン無しでサーバーを乗っ取られる脆弱性CVE-2026-47065(CVSS9.8)が見つかりました。過去の修正をすり抜ける3度目の穴で、対象は2.2.8・2.1.13・2.0.29への即更新が必要です。
多くの企業向けJavaシステムの土台で動いている通信部品「Apache MINA」に、ログインせずに遠隔からサーバーを乗っ取れる脆弱性が見つかりました。CVE-2026-47065として公開され、深刻度は10点満点中9.8(緊急)です。
問題が厄介なのは、これが初めて見つかった穴ではない点です。Apache MINAは同じ種類の脆弱性を2024年から繰り返し修正してきましたが、そのたびに修正をすり抜ける新しい抜け道が見つかってきました。今回は3度目の取りこぼしにあたります。開発元のApache Software Foundationは2026年6月2日、修正版となるApache MINA 2.2.8 / 2.1.13 / 2.0.29を公開し、利用しているシステムへの即時更新を呼びかけています。
そもそもApache MINAとは何か
Apache MINAは、ネットワーク通信を行うアプリを作るための部品(フレームワーク)です。Apache Software Foundationという、世界中のオープンソースソフトを取りまとめている非営利団体が開発しています。チャットサーバー、業務システム、機器同士の通信など、「データをネットワーク越しにやり取りする」処理を効率よく書くための土台として、長年、多くのJava製アプリに組み込まれてきました。
普段、利用者がApache MINAの名前を目にすることはまずありません。アプリの内部で黙々と通信を処理している、いわば部品メーカーのような存在だからです。だからこそ影響範囲が見えにくく、「自社のシステムにApache MINAが含まれているかどうか、すぐには分からない」という企業も少なくありません。MINA本体(mina-core)は単独で使われることもあれば、別のソフトの部品として間接的に取り込まれていることもあります。
今回の問題は、その通信部品が「受け取ったデータを元の形に戻す」ときに起きます。この「データを元に戻す」処理は専門的にはデシリアライゼーションと呼ばれ、Javaの世界では昔から事故の多い、危険な処理として知られてきました。同じ仕組みが原因の事故は、Oracle WebLogic Serverの大型脆弱性やOracle製品の月例パッチでも繰り返し登場しています。
CVE-2026-47065で何が起きるのか
攻撃者は、細工したデータをApache MINAを使うサーバーに送りつけるだけで、サーバー上で好きなプログラムを動かせます。これは遠隔からの任意コード実行(RCE)と呼ばれ、サーバー乗っ取りに直結する、脆弱性の中でも最も重いタイプです。しかも攻撃にログインは不要で、ネットワークから届く相手なら誰でも狙えます。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-47065 |
| 深刻度 | CVSS 9.8 / 10.0(緊急) |
| 種別 | 安全でないデシリアライゼーション (CWE-502) |
| 攻撃条件 | ネットワーク経由・ログイン不要 |
| 影響 | 遠隔から任意コード実行 (サーバー乗っ取り) |
| 対象 | Apache MINA(mina-core) 2.0系 / 2.1系 / 2.2系 |
| 発動の前提 | アプリが getObject() で 受信データを復元している場合 |
| 修正版 | 2.2.8 / 2.1.13 / 2.0.29 (2026年6月2日公開) |
| KEV登録 | なし(2026年6月3日時点) |
| 実証コード | 公開は確認されず |
なお、米国の政府機関が「悪用が確認された脆弱性」をまとめるCISA KEVカタログには、本稿執筆時点でCVE-2026-47065は登録されていません。実際に攻撃へ使われた報告も、攻撃を再現する実証コードの公開も、現時点では確認されていない状況です。とはいえ深刻度の高さと過去の経緯を踏まえれば、後追いで悪用が始まる前に手を打っておく価値は十分にあります。
修正済みのはずの鍵穴に、また合鍵が回るとき
この穴を一番うまみのある標的として狙うのは、ログインも盗む手間もいらず、サーバーに細工データを一通送るだけで全権を握れる「安さ」に群がる連中です。具体的には、企業のサーバーを暗号化して身代金を要求するランサムウェア集団、侵入経路だけを作って他の犯罪者に転売する初期アクセスブローカー、機密を狙う国家ぐるみのスパイ部隊、他人のサーバーを勝手に借りて仮想通貨を掘る自動化ボットの運用者です。彼らが持ち去るのは、そのサーバーで動く業務アプリの管理者権限、社内データベースに入った顧客名簿や取引記録、外部サービスにつながるAPIキーや認証トークンといった、その会社の中枢そのものです。受信データを元に戻すMINAのこの一行が踏まれた瞬間、攻撃者が書いたプログラムがサーバー上でそのまま走り出し、アプリの載ったサーバーは丸ごと他人の操作盤に変わってしまいます。
乗っ取りは一台では終わりません。最初の一台を踏み台に、攻撃者は同じ社内ネットワークにつながる別のサーバーへと横歩きで侵入範囲を広げ、業務データベースを丸ごと暗号化して操業を止め、復旧と引き換えに身代金を突きつけます。並行して抜き取った顧客情報はダークウェブで売られ、そこで得たメールアドレスや認証情報を使って取引先や顧客になりすました次の侵入が仕掛けられます。一社の通信部品の穴が、取引先や顧客を巻き込む連鎖被害の入口になるのが、この種の乗っ取りの本当の怖さです。
そして請求書は、最後に運用側へ返ってきます。顧客情報が漏れれば、運営企業は個人情報保護委員会への報告と本人への通知義務を負い、問い合わせ対応、損害賠償、取引先への説明、そして一度失った信用の回復という、長く続くコストを抱え込みます。CVSS 9.8という数字が映すのは技術的な深刻度の最大値にすぎず、システムを預かる企業にとっての本当の損失は、止まった業務と離れた顧客の側にあります。いま自社のApache MINAを点検して更新できるかどうかが、その分かれ目を左右します。
影響を受けるのはどんなシステムか
重要なのは、Apache MINAを使っていれば無条件で危ない、というわけではない点です。今回の脆弱性が発動するのは、アプリが受信したデータをそのままJavaのオブジェクトに復元している場合に限られます。技術的にはMINAの公式説明にある通り、AbstractIoBuffer.getObject()やObjectSerializationDecoderを通じて、信頼できない相手から届いたデータを復元している構成が対象になります。逆に、独自の形式でデータをやり取りしている場合は、この経路を踏みません。
とはいえ「自社のアプリがどの経路でデータを受けているか」を即答できる現場は多くありません。まずは利用しているmina-coreのバージョンを確認し、下の早見表で自分の系列の修正版に上げるのが確実です。攻撃条件が無認証である以上、「たぶん大丈夫」で放置するより、バージョンを上げて穴そのものを塞ぐほうが速くて安全です。
| 系列 | 影響を受けるバージョン | 修正版 | 適用優先度 |
|---|---|---|---|
| 2.2系 | 2.2.0 〜 2.2.7 | 2.2.8 | 最優先 |
| 2.1系 | 2.1.0 〜 2.1.12 | 2.1.13 | 最優先 |
| 2.0系 | 2.0.0 〜 2.0.28 | 2.0.29 | 高 |
自社で使っているソフトのどれがオープンソース部品を取り込んでいるかを洗い出すのは、それ自体が手間のかかる作業です。依存関係をまとめて棚卸しする考え方は、オープンソース部品の供給網を点検する仕組みの回でも整理しています。
技術的に何が起きているのか
Apache MINAは過去の事故を受けて、「復元してよいクラスだけを許可リスト(acceptMatchers)に登録し、それ以外は弾く」という防御をかけていました。今回の脆弱性は、その許可リストのチェックを横からすり抜ける2つの抜け道です。Apache公式の通知では、それぞれ「ZDRES-232」「ZDRES-233」という番号で説明されています。
CVE-2026-47065:Proxyクラスで許可リストをすり抜ける(ZDRES-232)
1つ目は、Javaの「Proxy(プロキシ)」という仕組みを悪用するものです。送られてくるデータの中に、Proxyクラスを表す印(TC_PROXYCLASSDESC)が含まれていると、Javaの標準処理が呼び出され、許可リストの確認を経ずにそのクラスを組み立ててしまいます。Apacheの説明を引くと、JDK標準のresolveProxyClassがそれぞれのインターフェイス名についてClass.forNameを実行し、「許可されたクラスの一覧を回避してプロキシクラスを構築する」と明記されています。つまり、せっかくの許可リストが、この経路では効かないということです。
ZDRES-233:許可したクラスでも「初期化」だけは走ってしまう
2つ目は、許可リストに載っている安全なはずのクラスでも、データに名前が出てきた段階で、そのクラスの静的初期化子(static initializer)が動いてしまうという問題です。静的初期化子はクラスが最初に読み込まれるときに一度だけ走る処理で、本来は無害でも、副作用のある処理が仕込まれていれば、インスタンスが作られる前に意図しない動作が起きる余地があります。Apacheはこの2点をいずれも「完全に対処済み(Fully addressed)」としています。
無認証で重いコード実行に至る構図は、最近だとダッソー製品の無認証RCEやSambaのリモートコード実行でも見られました。攻撃の入口は違っても、「外から届いたデータを信用して処理してしまう」という根っこは共通しています。
「修正、回避、再修正、また回避」の繰り返し
今回の脆弱性をより不安にさせるのは、それが一連の取りこぼしの最新版だという点です。Apache MINAのデシリアライゼーション問題は2024年末から続いており、修正のたびに「その修正をすり抜ける新しい抜け道」が見つかってきました。下の年表で経緯を追えます。
← スワイプで移動
CVE-2024-52046:最高評価10点が付いた原典
一連の起点になったのが、2024年末に公開されたCVE-2024-52046です。MINAのObjectSerializationDecoderに安全でないデシリアライゼーションがあり、深刻度はめったに付かない満点の10.0でした。このとき2.0.27 / 2.1.10 / 2.2.4で修正が入りましたが、これが長い追いかけっこの始まりでした。
CVE-2026-42778 / CVE-2026-42779:前回の取りこぼし
2026年4月30日には、CVE-2026-42778とCVE-2026-42779が公開され、2.2.7 / 2.1.12が出ました。いずれも過去の修正が不完全だったための追加修正で、この2件は「getObject()メソッドを使うアプリだけが影響を受ける」と整理されています。ベルギーの政府系セキュリティ機関も「直ちにパッチを」と注意喚起していました。今回のCVE-2026-47065は、その後さらに見つかった3度目の抜け道にあたります。
同時に修正されたもう一つの脆弱性 CVE-2026-47321
CVE-2026-47321:圧縮データでメモリを食い潰すDoS
2026年6月2日のリリースでは、もう一つCVE-2026-47321も同時に修正されました。こちらはMINAの圧縮処理(CompressionFilter)に、展開後のデータサイズの上限がなかったというものです。攻撃者が1,000対1を超えるような極端に圧縮率の高いデータを送りつけると、展開時にメモリを食い潰し、サービスを停止させられます。いわゆる「サービス妨害(DoS)」型の脆弱性で、修正版では展開後のサイズと圧縮率に上限を設けられるようになりました。乗っ取りに直結するCVE-2026-47065ほどの緊急度ではありませんが、同じ更新で一緒に塞がるため、まとめて2.2.8系へ上げるのが合理的です。
今すぐやるべき対策
対策はシンプルで、利用しているmina-coreを修正版に上げることに尽きます。2.2系なら2.2.8、2.1系なら2.1.13、2.0系なら2.0.29です。すぐにアプリ全体を更新できない事情がある場合は、Apacheが案内している通り、受け入れてよいクラスをacceptMatchersで明示的に限定し、信頼できないネットワークから届くデータを安易にデシリアライズしない構成に寄せるのが当面の防御になります。
自社製品の内部にApache MINAが組み込まれていないかどうかは、依存関係を一覧にして洗い出すのが確実です。エンタープライズの認証基盤やクラウド基盤でも同種の更新対応は続いており、社内ログイン基盤authentikの脆弱性やCloud Foundryの認証コンポーネントの脆弱性と同様、「土台に使っている部品が静かに脆弱性を抱える」パターンの典型と言えます。国内企業向けの脆弱性対応の動きはJVNまとめでも継続的に追っています。
よくある質問
Q. CVE-2026-47065はどれくらい危険ですか?
深刻度はCVSSで9.8(10点満点)と非常に高く、ログインなしで遠隔からサーバーを乗っ取れます。ただし発動するのは、アプリがAbstractIoBuffer.getObject()などで受信データをそのまま復元している構成に限られます。該当する場合は最優先で更新が必要です。
Q. 自分のシステムが影響を受けるか確認するには?
まず利用しているmina-coreのバージョンを確認します。2.2.8 / 2.1.13 / 2.0.29より前であれば対象です。加えて、信頼できない相手からのデータをObjectSerializationDecoderやgetObject()で復元していないかを点検してください。
Q. すぐに更新できない場合の回避策は?
受け入れてよいクラスをacceptMatchersで明示的に限定し、信頼できないネットワークからのデシリアライズを止めるのが当面の緩和策です。ただし過去に許可リストの回避が繰り返されている経緯を踏まえると、根本的には修正版への更新が必要です。
Q. なぜ同じ脆弱性が何度も出るのですか?
Javaのデシリアライゼーションは仕組み自体が攻撃に使われやすく、「危険なクラスだけ弾く」許可リスト方式でも、想定外の経路が次々に見つかるためです。今回のProxyクラス経由の回避も、その一例です。
参照元
- ▸NVD - CVE-2026-47065 Detail
- ▸NVD - CVE-2026-47321 Detail
- ▸Apache MINA Security Advisory(lists.apache.org)
- ▸Apache MINA - News / Releases(2026年6月2日)
- ▸NVD - CVE-2024-52046 Detail
- ▸SecurityWeek - Critical, High-Severity Vulnerabilities Patched in Apache MINA
- ▸BleepingComputer - Apache warns of critical flaws in MINA, HugeGraph, Traffic Control
- ▸CCB Belgium - Warning: Critical RCE in Apache MINA
- ▸oss-security - ZDRES-059 / CVE-2026-41635
- ▸Wikipedia - Apache MINA