パッチを1,449本すべて当てても、この攻撃は防げなかった

2026年7月下旬、Oracleが1,449本ものセキュリティ修正（パッチ）をまとめて出しました。データベースを預かる担当者にとっては、一日で当てるにはあまりに多い、記録的な量です。ところが、セキュリティ企業Huntress（ハントレス）が記録したある侵入は、その1,449本を全部当てていても防げませんでした。

理由がはっきりしています。攻撃に使われたのは、修正すべき「欠陥」ではなかったからです。Oracleにもともと備わっている、正しく動く機能そのものが使われました。

パッチをすべて当てても防げなかった侵入

この件を最初に報じたのはHuntressの調査ブログ（2026年8月5日公開）で、テクノロジー系メディアのThe Registerが8月25日に取り上げて広く知られるようになりました。攻撃が検知されたのは7月27日、Windowsサーバー上で動くOracleのデータベースが対象でした。

入口は、インターネットに公開されていた業務用のウェブアプリケーションでした。そこに空いていたのがSQLインジェクション（エスキューエル・インジェクション）——入力欄に本来はデータであるはずの命令文を紛れ込ませ、データベースに直接実行させてしまう、古典的な攻撃手法です。何十年も前から知られていて、入力のチェックをきちんとしていれば防げる、いわば基本の対策で塞げる穴です。ここまでは、正直めずらしくもない話でした。

調査担当者が眉をひそめた手口

問題はその先です。Huntressの調査担当者が「思わず眉をひそめた」と書いているのが、侵入後の動きでした。

攻撃者は、盗んだ足がかりを使って、侵入後に使う道具一式（Huntressは「khunt」と名づけています）をOracleのデータベースのなかにJavaのコードとして直接送り込みました。ファイルとしてサーバーに置くのではなく、データベースの内部にプログラムとして住みつかせたのです。手口自体は昔から理屈としては語られてきたものの、実際の攻撃で使われた記録はほとんどない、と同社は説明しています。

ここでカギになるのが、Oracleのデータベースに組み込まれているJVM（ジャバ仮想マシン＝Javaのプログラムを動かす仕組み）です。Oracleには、Javaのソースコードを受け取ってデータベース内のオブジェクト（部品）として保存し、その場でコンパイル（実行できる形に変換）する機能が正式に用意されています。開発者が便利に使うための、まっとうな機能です。

攻撃者は、この機能をそのまま使いました。ウェブアプリを経由してデータベースにつながる通り道から、Javaのソースを送り込む命令を流し込み、悪意あるコードをデータベースの中でコンパイルさせたのです。そこから最終的にはサーバーそのものを操れる状態に達し、パソコンのログイン情報が保管されている領域のコピーを盗み出そうとしていました。

穴ではなく、開いていたドア

つまり、この攻撃はどこかのバグを突いたのではありません。製品が正しく持っている機能を、有効になっていたからそのまま利用した——ここがこの一件のいちばんの読みどころです。

Oracleの第三者サポート事業を手がけるSpinnaker Support（スピネーカー・サポート）でサイバーセキュリティを統括するCraig Savage氏は、The Registerの取材にこう答えています。完全にパッチを当てて、すべてが正常に動いていたとしても、この侵入は起きていた、と。いくら鍵を増やしても、勝手口が開いたままなら意味がない、という話です。

Savage氏は、では何をすべきだったのかも述べています。データベースの中でJavaを動かせる機能は、本番稼働中のサーバーでは無効にしておくべきで、使うとしても開発や保守の作業中だけ、それも管理者権限を持つ限られた利用者に限定すべきだった——もしそうしていれば、送り込まれたJavaコードはコンパイルされず、攻撃は成立しなかった、という指摘です。氏はこれを「Oracleの欠陥ではなく、設定が不適切だっただけ」と表現しています。

発言の背景と、この報告の限界

ただし、この件を読むときに押さえておきたい点がいくつかあります。

まず、The Registerの記事にOracle自身のコメントはありません。「設定が悪かった」という見方は、あくまで取材に答えたSavage氏のものです。そしてそのSavage氏が所属するSpinnaker Supportは、OracleのサポートをOracle以外の立場で請け負う事業者で、Oracleと競合しうる関係にあります。発言そのものは技術的に筋が通っていますが、どういう立場の人の見立てなのかは知っておいたほうが公平でしょう。「Oracleの設定を任せる相手として自社をどう見せるか」という利害から完全に切り離せるわけではないからです。

「便利な機能を有効にしていたのが甘かった」と見ることもできますし、「初期状態でそれほど強力な機能が動く設計そのものにも議論の余地がある」と見ることもできます。どちらか一方だけが正しい、という話ではありません。

もう一つ、これはHuntressが確認した単一の事例の報告で、同じ手口が広く流行しているというデータは示されていません。被害を受けた組織の名前も、件数も、被害額も、記事には出てきません。「明日にもあなたが狙われる」という類の話ではないことは、正直に書いておきます。

変わりつつある「攻撃の探し方」

それでもこの一件が示唆に富むのは、Savage氏が指摘する大きな流れのほうです。サイバー犯罪者は、製品の壊し方（バグの探し方）だけでなく、有効になっていれば悪用できる正規機能が何なのかも把握しはじめている——氏はそう述べています。

組織はパッチを当てることに神経を集中しがちですが、それだけでは足りない、というのがこの話の持ち帰りどころです。使っていない機能は切っておく、権限は必要な人だけに絞る、入力のチェックを怠らない——どれも地味で、新しいパッチのように「当てた」実感の乏しい作業です。けれど、開いたままの勝手口を閉めておく効果は、鍵を1,449個増やすことに引けを取りません。

この攻撃が今後どれくらい広がるのかは、まだ分かりません。Huntressの一例が特殊なケースにとどまるのか、それとも同じ発想の侵入が続くのか。そこは今後の観測を待つ必要があります。