Wazuhを入れたら脆弱性が3,247件検出された話【RasPi 5 自宅ラボ セキュリティ実録 #2】

最終確認: 2026年2月

BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→でRaspberry Pi 5へのWazuhインストールを終え、Vulnerability Detectionダッシュボードを開いた瞬間のことを正直に言います。

Critical   203件
High       927件
Medium   1,877件
Low        ~240件
合計     3,247件

二度見した。「やばい、うちのサーバー穴だらけじゃないか」とはならなかったけれど、「この数字はなんだ」とはなった。20年以上ハードウェア関係の仕事をしていて、職場でもセキュリティ絡みの話は普通に出てくる。でも自分のサーバーにこれだけ具体的な数字を叩きつけられたのは初めてだった。

結論を先に言うと、3,247件のほとんどは「見せ方」の問題で、実害リスクは最初から高くなかった。ただそれを理解するまでに少し時間がかかった。その過程を記録しておく。

この記事でわかること 対象: Wazuhを初めて導入して脆弱性の数字に圧倒されている方

• Wazuhの脆弱性検出「3,247件」という数字の正体
• Linuxカーネル CVEが大量に出る理由と削減方法
• CVSSスコアより重要な「攻撃面」の考え方
• サーバーにメールクライアントが混入していた話（実体験）

• Wazuhの脆弱性検出は「カルテ」であって「診断書」ではない
• 数字の正体：犯人は3つ
  • 犯人1：旧カーネルイメージが複数残っていた
  • 犯人2：サーバーにメールクライアントが入っていた
  • 犯人3：ffmpeg関連（49件）
• Top5 CVEを実際に調べた結果
  • CVE-2023-3326（32件、CVSS 9.8 Critical）
  • CVE-2025-25467（24件、HIGH）
  • CVE-2022-3219（22件、CVSS 3.1 LOW）
  • CVE-2025-68972（22件、MEDIUM）
  • CVE-2022-3964（21件、CVSS 4.3 MEDIUM）
• 実際に実施した対処
• Wazuhの数字を正しく読む3つのポイント
  • 1. カーネルCVEは「多くて当然」
  • 2. CVSSスコアより「自分のシステムで使われているか」を見る
  • 3. 「Pending Evaluation」は気にしない
• まとめ
• 後日談：High・Medium・Low、全部消えた
• よくある質問
• この記事を書いた人
• 関連記事

WazuhのVulnerability Detectionは、インストール済みパッケージのバージョンをNVD（米国 National Vulnerability Database）やUbuntu Security Noticesと照合して、既知のCVE（Common Vulnerabilities and Exposures：脆弱性の国際識別番号）一覧を作る仕組みです。

検出 ≠ 攻撃を受けている、という点を最初に理解しないとこの数字に飲まれます。

「このバージョンのソフトウェアには、理論上この脆弱性が存在する」という状態を記録しているだけ。実際に誰かが攻撃してきているわけではない。

医療で言えば「潜在リスクのカルテ」であって、「今すぐ手術が必要な診断書」ではない。ただ、カルテを見慣れていない人間に「あなたのリスク要因は3,247件です」と言えば、そりゃ驚く。

分解してみると、3,247件の大半は3つの要因から来ていました。

犯人1：旧カーネルイメージが複数残っていた

linux-image-6.17.0-14-generic   2,450件
linux-image-6.14.0-27-generic   1,225件
linux-image-6.14.0-37-generic   1,225件

Linuxカーネルは年間5,000件以上のCVEが報告されます（NVD統計参照）。2025年だけで約5,530件が登録されたというデータもある。カーネルのコード規模（数百万行）を考えれば、この数は「異常」ではなく「構造上の正常」です。

問題は、Ubuntuのapt upgradeがカーネルを更新しても古いイメージを自動削除しないという点。気づかないうちに複数のカーネルイメージが溜まり、それぞれにCVEがカウントされて合計が膨らんでいた。

古いカーネル（6.14.0-27）を削除したら、1,225件が一気に消えた。

⚠️ 注意: 削除前に必ず uname -r で現在動作中のカーネルを確認してください。動作中のカーネルを誤って削除すると起動不能になります。

# 動作中のカーネル確認
uname -r
# → 6.17.0-14-generic

# 不要なカーネルイメージを削除
sudo apt remove --purge linux-image-6.14.0-27-generic
sudo apt autoremove --purge
# → 162MB回収

これだけで1,000件以上消える。インパクトのある数字を見せておいて、「削除して」と言うだけで解決するくだりが、少し面白い。

犯人2：サーバーにメールクライアントが入っていた

これは本当に「え？」となった。

thunderbird  122件

Ubuntu ServerにThunderbirdが入っていた。

なぜ入ったか調べると、thunderbird: 2:1snap1-0ubuntu3というdeb移行パッケージが、Ubuntu 24.04のインストール過程で何かのタイミングで混入していたようです。

サーバーにメールクライアントは不要どころか、攻撃面を無意味に広げるリスクしかない。これはWazuhを入れなければ気づかなかった可能性が高い。

# deb移行パッケージを削除
sudo apt remove --purge thunderbird thunderbird-locale-ja

# snap本体を削除
sudo snap remove thunderbird

# スナップショットも削除
sudo snap forget 1

122件のリスクが「不要なソフトを消しただけ」で消える。

この体験が、Wazuhを入れる意義をいちばん直感的に示していると思う。「脆弱性をゼロにするため」ではなく、「知らないリスクを可視化するため」に入れる。それが本来の使い方だと感じた。

犯人3：ffmpeg関連（49件）

libavcodec60  49件（CVE-2022-3964など）

CVE-2022-3964はFFmpegのRPZAエンコーダにおける範囲外読み取り（CVSS 4.3/MEDIUM）。外部から受け取った動画ファイルを処理しない限り、実害リスクは低い。apt upgradeで最新版に更新して対処しました。

WazuhがTop5として報告してきたCVEを1件ずつ調べました。CVEは脆弱性の国際識別番号、CVSS（Common Vulnerability Scoring System）は深刻度を0〜10で評価するスコアで、10に近いほど理論上の深刻度が高くなります。

CVE-2023-3326（32件、CVSS 9.8 Critical）

PAMのKerberosモジュール（pam_krb5）における認証バイパスの脆弱性。CVSSスコアは最高水準の9.8ですが、Kerberosを使っていなければゼロリスク。自宅ラボではまず使わない。スコアが高くても攻撃経路が存在しなければ意味がない。

CVE-2025-25467（24件、HIGH）

libx264のAAC音声処理におけるメモリリーク。動画エンコード処理をしていなければ実害なし。

CVE-2022-3219（22件、CVSS 3.1 LOW）

GnuPGへのDoS攻撃（圧縮パケットの悪用）。RCE（リモートコード実行）ではなく、サービス一時停止レベルのリスクのみ。

CVE-2025-68972（22件、MEDIUM）

GnuPGの署名検証バイパス。2026年2月時点でパッチ未公開。修正リリースを待つしかない。

CVE-2022-3964（21件、CVSS 4.3 MEDIUM）

前述のFFmpeg案件。apt upgradeで対処済み。

# 実行したコマンド一覧
sudo apt update && sudo apt upgrade -y
sudo apt remove --purge linux-image-6.14.0-27-generic -y
sudo apt autoremove --purge -y

ゼロにする必要はなく、「意味のあるリスクを潰す」のが目的です。

1. カーネルCVEは「多くて当然」

Linuxカーネルに2,000件超のCVEが紐付くのは異常ではありません。コードの規模と登録件数の組み合わせで起きる構造上の問題です。まず古いカーネルイメージを削除して数を減らすところから始めると全体像がつかみやすくなります。

2. CVSSスコアより「自分のシステムで使われているか」を見る

CVE-2023-3326はCVSS 9.8のCriticalですが、Kerberosを使っていなければゼロリスクです。一方で、サーバーにThunderbirdが入っていることのほうが実害リスクとして高い場合がある。

スコアは「理論上の深刻度」であり、「あなたのシステムの危険度」ではない。自分のシステムでその攻撃経路が実際に使われるかを考えることが重要です。

3. 「Pending Evaluation」は気にしない

Wazuhのダッシュボードに「Pending - Evaluation: ○○件」という表示が出る場合があります。これはまだスキャン・分類が完了していないパッケージを指します。時間が経つとEvaluatedに移行するため、この数字は自然に変わります。

Wazuhを導入して最初に見る数字は、圧倒的です。ただ冷静に分解すると：

• カーネルの宿命的な数字が大半 — 古いイメージを削除するだけで一気に減る
• 不審なパッケージが見つかることがある — Thunderbirdがサーバーに入っていた（今回の一番の収穫）
• CVSSスコアより攻撃面で判断 — Kerberos未使用ならCVSS 9.8でも自宅ラボではゼロリスク

Wazuhを開いてから、自分のサーバーを見る目が変わりました。「動いているからOK」ではなく、「今日はどこに見落としがあるか」という目で見るようになった。

それが良いことかどうかは、まだわかりません。

この記事を公開してしばらく後、Wazuhのダッシュボードを確認したら、状況が変わっていた。

High・Medium・Low・Pendingが全て0になっていた。

残った93件のCriticalは内訳を確認したが、ローカル環境限定の問題か、まだパッチが出ていないCVEがほとんどで、自宅ラボの構成上・今すぐ対処が必要なものはなかった。

この変化が何を示しているか。

「気になる数字は、ちゃんと追えば減る」——それだけだと思う。最初に3,247件という数字を見たとき「うわっ」となった。分解したら犯人は3つで、対処は思ったより単純だった。その後もapt upgradeを定期的に当てていれば、High・Medium・Lowは自然に落ちていく。

放置している古いアプリケーション、更新を後回しにしているパッケージ——それが積み重なってリスクになる。 Wazuhはそれを可視化してくれるツールだ。「脆弱性をゼロにするため」ではなく、「見えていないリスクに気づくため」に入れる。その本来の使い方が、きちんと機能していると確認できた。

目標は「ゼロにすること」ではなく「管理できている状態を維持すること」だ、と改めて確認した。

📝 情報の誤りや古い記述にお気づきの際は、お問い合わせからお知らせいただけると助かります。

パスワード管理など手元のセキュリティ強化に興味がある方は、Blogパスワード管理に困っていない？Bitwardenで始めるセキュアなパスワード管理全部同じパスワードを使い回していませんか？Bitwardenを使えば無料で安全にパスワード管理ができます。おすすめ設定・注意事項・デメリットまで正直に解説します。→やBlog1Passwordは本当におすすめ？プロが教える正直レビューと使いこなし術有料パスワードマネージャーの代表格1Password。料金に見合う価値はあるのか？UI/UX・セキュリティ・家族プランのメリットとデメリットを正直に解説します。→も参考にしてください。SSH鍵をファイルから保管庫管理へ移す手順はBlogパスワードも SSH 鍵も、自宅に置いておく——Vaultwarden + Bitwarden SSH Agent で作る個人セキュリティ基盤クラウドパスワードマネージャーへの不安と ~/.ssh/ ファイル管理の煩雑さを、Vaultwarden（RasPi 5 Docker）と Bitwarden SSH Agent の組み合わせで解決した実録。GNOME Keyring の競合解消・毎回確認ダイアログによるプロンプトインジェクション対策・snap バージョン非依存のソケット設定まで解説。→で書いています。

Q. WazuhのVulnerabilityスキャンはどのくらいの頻度で実行されますか？ デフォルトでは定期的に自動実行されます。スキャン間隔はWazuhマネージャーの設定ファイル（ossec.conf）で変更可能です。

Q. Critical判定の脆弱性は全て即対処が必要ですか？ いいえ。CVSSスコアは「理論上の深刻度」であり、あなたのシステムでその攻撃経路が実際に使われる可能性を示すものではありません。使用していないサービスや機能に関するCVEは、スコアが高くても優先度を下げて構いません。

Q. apt upgradeだけで十分ですか？ apt upgradeでパッケージを最新化するのは基本的な対処として有効です。ただし、パッチが公開されていないCVE（Pending状態）や不要ソフトの削除など、apt upgradeだけでは解消できないケースもあります。

Q. WazuhはRaspberry Pi 5で安定して動きますか？ BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→で詳しく触れていますが、Docker版はRasPi 5（ARM64）環境で不安定になりやすく、debパッケージによる直接インストールを推奨しています。使用したハードウェア構成はHomelab構成ページも参照してください。下の画像はWazuhで3台のエージェントを管理している様子です。

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です！エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします！

• BlogWazuhとClaude Codeを繋いだら、CVE調査と修正提案が自動化できた【自宅ラボ セキュリティ実録 #3】Wazuh REST APIでCVEリストを取得し、Claude Codeに渡したら調査と修正コマンド生成が自動化できた。93件のCriticalを手動で追っていた状態からの脱出実録。→
• BlogRasPi 5にWazuhを入れたら、Dockerが死んだ話——自宅セキュリティ監視の実録RasPi 5（ARM64）にWazuhをDocker Composeで構築しようとしたらIndexerが落ちて失敗。直接インストールに切り替えた実録。3台を監視したらCritical脆弱性が203件出てきた話。→
• BlogLinux向け無料EDRは実質Wazuh一択だった — 自宅RasPi 5で4.5ヶ月運用した本音と実測個人のLinuxで無料EDR的監視はWazuhが現実的。RasPi 5で4台を4.5ヶ月運用した実測と、商用EDRとの違いを整理します。→