Cassandra公式イメージに初期パスワード残存 CVE-2026-47846、即更新を
大量データを分散保管する人気データベースCassandraを手軽に動かせる公式コンテナイメージ（Bitnami版）に、初期パスワードがそのまま残る不具合が見つかりました。CVE-2026-47846、危険度は10点満点中9.8。独自の管理者を設定したつもりでも、誰でも知る初期アカウントで外部から侵入され全データを読み書きされる恐れがあります。対象の4.0/4.1/5.0系は修正版へ即更新を。
堀川 慎
Backend Engineer / AWS / Django / Go
大量データを分散保管する人気データベースCassandraを手軽に動かせる公式コンテナイメージ（Bitnami版）に、初期パスワードがそのまま残る不具合が見つかりました。CVE-2026-47846、危険度は10点満点中9.8。独自の管理者を設定したつもりでも、誰でも知る初期アカウントで外部から侵入され全データを読み書きされる恐れがあります。対象の4.0/4.1/5.0系は修正版へ即更新を。
大量のデータを複数のサーバーに分散して保管する人気のデータベース「Apache Cassandra」を手軽に動かせる公式コンテナイメージに、誰でも知っている初期パスワードがそのまま残ってしまう不具合が見つかりました。2026年6月18日に公開された「CVE-2026-47846」で、危険度は10点満点中9.8（緊急）と、ほぼ最高レベルに評価されています。
問題があるのは、コンテナの配布で広く使われる「Bitnami」版のCassandraイメージです。管理者が独自の利用者を設定したつもりでも、初期アカウント「cassandra」がこっそり生き残り、外部から誰でもそのアカウントで侵入してデータベースを丸ごと読み書きできてしまう恐れがあります。開発元のセキュリティ情報で公開され、修正版が出ています。
Cassandraとは何か、Bitnamiのイメージはなぜ広く使われているのか
Apache Cassandraは、大量のデータを1台のサーバーに収めきれないときに、複数のサーバーへ分けて保管・処理する「分散型データベース」です。SNSの投稿履歴、IoT機器が送ってくる大量の記録、アクセスログのように、絶え間なく増え続けるデータをさばく用途で世界中の企業が使っています。データはCQL（Cassandra用の問い合わせ言語）という命令でやり取りし、外部とは通信ポート「9042番」でつながります。
そのCassandraを「すぐ動かせる状態」に箱詰めしたのが、今回問題になったコンテナイメージです。コンテナとは、アプリと必要な部品をまとめて持ち運べる小さな箱のような仕組みで、Docker（ドッカー）やKubernetes（クバネティス、大量のコンテナを束ねて動かす基盤）と組み合わせて使われます。Bitnamiは、このコンテナイメージを数多く無料で配布してきた有名な提供元で、いまはBroadcom傘下のVMwareが運営しています。ダウンロード回数が極めて多く、社内のテスト環境から本番環境まで幅広く使われているため、たった1つのイメージの不具合でも影響範囲が大きくなります。
こうした「便利な公式部品そのものに穴が見つかる」事例は最近相次いでいます。当サイトでも、コンテナの隔離を破って外へ抜け出す脆弱性が実際に悪用された事例や、移行ツールから管理者情報やKubernetesの鍵が漏れる脆弱性を取り上げてきました。土台となる部品が広く使われているほど、その1か所のミスが多くの現場に波及します。
この初期アカウントで入ってくるのは誰で、何を持っていくのか
「初期パスワードが残っているだけ」と聞くと小さな見落としに思えるかもしれません。ですが今回のCVE-2026-47846は、攻撃する側からすると鍵のかかっていない裏口がそのまま開いている状態です。誰がその裏口を試しに来るのかを、技術用語を外して具体的に思い描いておくと、放置できない理由が見えてきます。
入ってくるのは、インターネット上を機械的に巡回して「cassandra」「admin」「root」といった定番のIDとパスワードを片っ端から試して回る攻撃者、企業のデータを盗んで売りさばく窃盗グループ、データを暗号化して身代金を要求するランサムウェアの実行犯、そして競合や取引先のふりをして社内に紛れ込む者たちです。彼らが手に入れるのは、Cassandraにためた利用者の氏名やメールアドレス、注文や決済の履歴、機器が送ってくるセンサーの記録、アクセスログに残った行動の履歴、そしてデータベース全体を作り替えたり消したりできる管理者の権限そのものです。初期アカウントが残ったまま9042番ポートが外に開いていれば、相手は何の細工もいらず、知られた合言葉を打ち込むだけで、この情報の山の前に立てます。
技術的に見ると、攻撃者はインターネット全体を走査するツールで9042番ポートが開いているサーバーを探し当て、誰もが知る初期の組み合わせ「cassandra / cassandra」でログインを試みます。今回の不具合があるイメージでは、管理者が新しい利用者を作って初期アカウントを消したつもりでも、その初期アカウントが生き残っているため、ログインが通ってしまいます。一度入られれば、相手はすべてのデータの読み取りと書き換えに加え、別のデータをこっそり仕込んで踏み台にしたり、保管されたデータを暗号化して使えなくしたりと、攻撃を次の段階へ広げられます。
「危険度9.8」という数字は、技術的な深刻さを示す目盛りにすぎません。Cassandraに事業のデータを預けている人にとって本当に失われるのは、顧客から預かった個人情報の塊と、それが漏れたときに支払う信頼と賠償です。事前の難しい準備もいらず、知られた合言葉ひとつで届いてしまう点に、この脆弱性の怖さがあります。
CVE-2026-47846で実際に何が起きるのか
脆弱性の正体は「初期アカウントの消し忘れ」です。専門的にはハードコードされた初期資格情報（CWE-798、あらかじめ製品に埋め込まれた決め打ちのID・パスワードが残る問題）に分類されます。Cassandraは初期状態で「cassandra」という管理者アカウントを持ち、パスワードも「cassandra」です。これは世界中の人が知っている値なので、本番運用では必ず別のアカウントに置き換えるのが鉄則です。
Bitnamiのイメージでは、起動時に環境変数CASSANDRA_USERへ独自の利用者名を指定すると、初期化スクリプトが新しい管理者アカウントを作るしくみになっています。ところが開発元のアドバイザリによると、特定の条件下では、新しいアカウントを作ったあとも初期の「cassandra」アカウントを削除しそびれていました。管理者は独自アカウントへ置き換えたつもりでも、初期の合言葉が裏口として残り続けるわけです。
この裏口が突かれると、9042番ポートに通信できる攻撃者が初期の「cassandra / cassandra」で認証を通し、すべてのキースペース（データのまとまり）とテーブルに対する完全な読み書き権限を持つ管理者として振る舞えます。NVD（米国政府の脆弱性データベース）の評価は、事前の権限も利用者の操作もいらず、ネットワーク越しに機密性・完全性・可用性のすべてを失わせうるとして、危険度を最高クラスの9.8（緊急）としています。
同じ「データベースが不正に操作される」系統では、当サイトでもログインなしでデータベースを操作されるSpring AIの脆弱性や、AIが書いたSQLでデータベースを乗っ取られるLangroidの事例を扱ってきました。今回はアプリの作りではなく、配布されたイメージの初期設定の取り扱いに穴があった点が特徴です。報告時点で、実際に悪用されたという報告は確認されていません。
自分は影響を受けるのか、どのバージョンが危ないのか
影響を受けるのは、BitnamiのCassandraコンテナイメージを使っていて、なおかつ古いバージョンのままの場合です。下の表で、自分の使っているバージョンを確認してください。
| 系統 | 影響を受けるバージョン | 修正バージョン |
|---|---|---|
| 4.0系 | 4.0.20-photon-5-r7 より前 | 4.0.20-photon-5-r7 以降 |
| 4.1系 | 4.1.11-photon-5-r7 より前 | 4.1.11-photon-5-r7 以降 |
| 5.0系 | 5.0.8-photon-5-r4 / 5.0.8-debian-12-r3 より前 | 5.0.8-photon-5-r4 / 5.0.8-debian-12-r3 以降 |
| 項目 | 内容 |
|---|---|
| 対象 | BitnamiのCassandra コンテナイメージ |
| 脆弱性の種類 | 初期アカウントの 消し忘れ（CWE-798） |
| 危険度 | CVSS 9.8（緊急） |
| 悪用の前提 | 9042番ポートへ 通信できること |
| 公開日 | 2026年6月18日 |
なお、これは「Bitnamiが配布するイメージ」固有の問題で、Apache Cassandra本体そのもののバグではありません。自分でCassandraを一から構築している場合は対象外ですが、その場合も初期アカウントを消し忘れていないかは別途確認しておくと安心です。
どう対処すればいいのか
対処の基本は、BitnamiのCassandraイメージを修正版へ更新することです。上の表にある各系統の修正バージョン（4.0.20-photon-5-r7、4.1.11-photon-5-r7、5.0.8-photon-5-r4 または 5.0.8-debian-12-r3）以降へ入れ替えてください。手順は公式リポジトリとセキュリティアドバイザリGHSA-8q3j-37vg-8fc2で確認できます。
すぐに更新できない場合の応急策として、アドバイザリは2つの手当てを挙げています。1つは、CQLでDROP USER 'cassandra'; を実行して、残ってしまった初期アカウントを手作業で削除すること。もう1つは、ファイアウォールやKubernetesのNetworkPolicy（通信を許可する相手を絞る設定）で、9042番ポートへ外部から触れないように制限することです。どちらも一時しのぎであり、根本対応はあくまで修正版への更新です。
自社でどのコンテナイメージのどのバージョンを使っているか把握しきれていない場合は、OSS脆弱性スキャナーのように、使っている部品の一覧から危険なバージョンを自動で洗い出すしくみを使うと見落としを防げます。Bitnamiは脆弱性情報を専用のデータベースでも公開しているので、運用しているイメージの最新状況を定期的に確認しておくとよいでしょう。
なぜ「初期パスワード残り」がここまで危ないのか
初期パスワードの問題が怖いのは、攻撃者が事前に何も調べる必要がないからです。製品の初期アカウントとパスワードは公開情報なので、攻撃者はそれを総当たりのリストに入れて、世界中のサーバーへ機械的に試すだけで侵入できます。穴を見つける手間も、利用者をだます手間もいりません。だからこそ、こうした初期値の残存は危険度が最高クラスに振れがちです。
便利なコンテナイメージは「動かせばすぐ使える」状態を売りにしている分、初期設定の取り扱いがそのまま安全性に直結します。今回のように、利用者が正しく独自アカウントを設定していても裏口が残ってしまうケースは、利用者側の落ち度ではなく配布物側の不具合です。土台の部品を使うときは、提供元のセキュリティ情報を購読し、修正が出たら速やかに取り込む運用を習慣づけることが、いちばんの守りになります。
✓ 確認済みの事実
- ✓CVE-2026-47846は2026年6月18日に公開（NVD）
- ✓BitnamiのCassandraイメージで初期アカウント「cassandra」が消し忘れられる問題、危険度9.8（緊急）
- ✓9042番ポートに到達できれば「cassandra / cassandra」で管理者として侵入されうる
- ✓各系統の修正版（4.0.20 / 4.1.11 / 5.0.8 系）が公開済み（GHSA-8q3j-37vg-8fc2）
? 現時点で未確認の点
- ?実際の攻撃や悪用の報告 ― 公開時点では確認されていない
- ?初期アカウントが残る「特定の条件」の細かな範囲 ― アドバイザリでは詳細まで明示されていない
よくある質問
Q. 独自のアカウントをちゃんと設定していれば安全ですか？
A. いいえ。今回の不具合は、独自アカウントを設定しても初期の「cassandra」アカウントが消し忘れられる点にあります。設定したつもりでも裏口が残っている可能性があるため、修正版への更新か、初期アカウントの手動削除が必要です。
Q. Apache Cassandra本体を使っていれば関係ないですか？
A. 今回の脆弱性はBitnamiが配布するコンテナイメージ固有の問題です。ただしCassandraは初期状態で「cassandra / cassandra」という管理者アカウントを持つため、本体を自前で構築している場合も、この初期アカウントを残していないか確認しておくと安心です。
Q. すぐに更新できないときは何をすればいいですか？
A. CQLで初期アカウントを削除する（DROP USER 'cassandra';）か、9042番ポートへ外部から触れないようファイアウォールやNetworkPolicyで制限してください。いずれも応急策で、最終的には修正版への更新が必要です。
まとめ
CVE-2026-47846は、分散データベースApache Cassandraを手軽に動かせるBitnami版コンテナイメージで、初期アカウント「cassandra」が消し忘れられてしまう脆弱性です。危険度は9.8（緊急）と高く、9042番ポートに到達できる攻撃者が、誰もが知る初期の合言葉だけでデータベース全体を管理者として読み書きできてしまう恐れがあります。
対象は4.0系・4.1系・5.0系の古いイメージで、それぞれ修正版が公開されています。すぐに更新できない場合は、初期アカウントの手動削除と9042番ポートのアクセス制限が応急策になります。便利な公式部品ほど初期設定の扱いが安全性を左右します。提供元のセキュリティ情報を購読し、修正が出たら速やかに取り込む習慣が、いちばんの備えになります。