脆弱性とは、ソフトウェアやシステムの安全を損なう弱点です。 読み方は「ぜいじゃくせい」。悪用されると、情報を盗まれたり、意図しない操作をされたりする原因になります。
ただし、「脆弱性が見つかった」は「もうウイルスに感染した」と同じ意味ではありません。弱点があること、誰かがそこを攻撃したこと、実際に被害が出たことを分けると、ニュースを読み違えにくくなります。
この記事では、「弱点がある」と「被害が出た」を読み分け、更新のお知らせで何を確かめればよいかを説明します。個別の製品で必要な操作は、提供元の公式案内で確認できます。
脆弱性とは、安全を損なう弱点のこと
窓の留め具に不具合があり、閉めたつもりでも外から開けられるとします。この「安全に閉まらない状態」が、脆弱性を考える手がかりになります。
侵入者がまだ来ていなくても、弱点は存在します。一方、弱点があっても、必ずその日に侵入されるわけではありません。だからこそ、被害の発生を待たず、弱点を直すことに意味があります。
コンピューターでは、弱点は目に見える穴とは限りません。送られた情報を十分に確かめず扱う処理、本来は見せてはいけないデータを見られる設定など、さまざまな形があります。米国NISTの用語集でも、システムや運用などにある、悪用や誘発によって安全を損なう弱点として説明されています。
窓のたとえで分かるのは、「弱点」と「侵入」は別だという点です。現実のシステムでは、どこから届く情報が、どの処理を通るかも関係するため、見た目だけで安全性は判断できません。
脆弱性とバグ・ウイルスの違い
似たニュースに登場する言葉でも、指しているものが違います。
| 言葉 | 意味 | 例 |
|---|---|---|
| バグ | プログラムの不具合 | 計算結果が違う、画面の並びがおかしい |
| 脆弱性 | 安全を損なう弱点 | 他人の情報を権限なしで読めてしまう |
| ウイルス | 他のファイルなどへ入り込んで増える、悪意あるプログラムの一種 | 感染したファイルを介して広がる |
| 攻撃 | 害を与えたり、不正に利用したりする行為 | 弱点を狙って特殊な情報を送り込む |
すべてのバグが脆弱性とは限りません。文字の位置が少しずれる不具合と、他人の情報を読める不具合では、安全への影響が違います。また、プログラム自体に不具合がなくても、公開設定などが原因で弱点ができる場合があります。
ウイルスと脆弱性は、「攻撃に使われ得るもの」と「利用される弱点」という違いがあります。悪意あるソフトウェアの総称はマルウェアです。日常会話では全部をウイルスと呼びがちですが、専門的にはウイルスはその一種です。
ユイ
弱点があるというお知らせを見ただけで、感染したと決めなくていいんですね。
マコト
そうだね。ただ、感染していないと決める材料でもない。修正が必要かと、被害が確認されたかを分けて読もう。
脆弱性の発見と情報漏えいは同じ？
同じではありません。ニュースには、次のように異なる状態が書かれています。
悪用され得る問題の存在が分かった。
問題を悪用しようとする動きが見えた。
情報の流出や改変などが調査で分かった。
必ずこの順で発覚するわけではありません。弱点の存在だけでは、個別の被害までは分かりません。
**「脆弱性を発見した」**は、悪用され得る弱点が分かったという話です。開発者や研究者が、被害が起きる前に見つける場合もあります。
**「攻撃を観測した」**は、攻撃の試みなどを確認したという話です。観測された試みが成功したか、どの利用者に影響したかは、別に確認が必要です。
**「情報漏えいを確認した」**は、外へ出てはいけない情報が漏れたという、被害についての話です。漏れた情報の種類、対象、期間などを読む必要があります。
この三つは、必ずこの順番で発覚するわけではありません。被害の調査中に、それまで知られていなかった弱点が見つかることもあります。「発見された日」が「弱点ができた日」や「最初に攻撃された日」と同じとは限らないのです。
サービスの停止も、それだけでは侵入の証拠になりません。修正のために止める、被害を広げないために切り離す、負荷で止まるなど、停止には複数の理由があります。
「悪用されるおそれ」と「悪用を確認」は一緒に書かれることもある
「情報を操作されるおそれがあります」と読むと、まだ何も起きていないように感じるかもしれません。けれども、その一文が説明しているのは、弱点を悪用すると何が起こり得るかです。攻撃が起きたかどうかまでは答えていません。
たとえば、イタリアのCSIRT Toscanaが2026年10月16日に掲載した注意喚起は、遠隔サポート製品BeyondTrust Remote Supportについて、概要で実際の悪用が検出されたと伝えています。一方、影響を説明する節では、攻撃者がファイルを操作できる可能性を述べています。ここでは原文の意味を要約しています。
この二つは矛盾しません。「弱点を使って何ができるか」と「実際に何を確認したか」は、別の説明だからです。 提供元のBeyondTrustによる調査報告でも、実際の悪用について説明されています。
ただし、悪用が確認されたからといって、その製品を使う全員に被害が出たとは限りません。自分に関わるかを知るには、対象製品・版・利用環境に加え、提供元や利用サービスからの個別の案内を確かめます。会社の機器なら、管理担当者への確認が必要な場合もあります。
読むときは、「何が起こり得るか」を説明する文と、「どこまで確認できたか」を報告する文を探してみてください。前者だけで安心せず、後者だけで自分の被害を決めつけない。この読み分けは、日本語でも外国語でも同じです。
脆弱性が生まれる理由
プログラムは、想定した手順だけで動くとは限りません。大量のデータが届く、途中でメモリが足りなくなる、処理が失敗するなど、普段とは異なる条件にも対応する必要があります。
たとえば、ラボの貸出記録を保存する途中で処理が止まったとします。途中まで書いた記録を完成済みとして扱えば、その後の確認が食い違います。実際のソフトウェアでも、異常時の後片づけや、情報を次の処理へ渡す部分の誤りが問題になることがあります。
さらに、単体では問題がなくても、設定や他のソフトとの組み合わせで弱点が生まれる場合があります。新しい機能を加えれば、確かめる必要のある組み合わせも変わります。
「長く使われているから弱点はもうない」「有名な製品だから問題が起きない」とは言い切れません。反対に、弱点を公表して修正することは、安全を保つための作業でもあります。発見件数だけで、その製品の安全性全体を順位づけするのは難しいところです。
脆弱性の対策でアップデートが必要な理由
アップデートは、ソフトウェアを新しい版へ更新することです。新機能を増やすものだけでなく、弱点を修正するための更新もあります。
先ほどの窓でいえば、修正は留め具そのものを直す作業です。見張りをつけることにも役割はありますが、留め具の不具合が直るわけではありません。
| 対策 | 主に担う役割 | それだけではできないこと |
|---|---|---|
| 修正版へ更新する | 対象の弱点を修正する | 過去の侵入や情報流出をなかったことにする |
| アクセスを制限する | 弱点に届く経路を減らす | プログラムの不具合そのものを修正する |
| 不審な動作を監視する | 攻撃や異常の手がかりを見つける | すべての攻撃を事前に防ぐ |
| バックアップを用意する | 失った情報や機能を戻す助けにする | 情報の流出自体を防ぐ |
必要な対策は弱点の種類と環境で変わります。パスワード変更も有効な場面がありますが、認証を必要としない処理の弱点まで、それだけで修正できるわけではありません。その違いは認証なしのリモートコード実行で説明しています。
脆弱性のニュースを読むときの確認点
ここで、説明用の架空のお知らせを読んでみます。
予約システムの特定の版に脆弱性が見つかったため、修正版を配布しました。現時点で、利用者情報の漏えいは確認していません。
この文から分かるのは、「対象の版がある」「修正版がある」「確認時点では漏えいを確認していない」ということです。「どの版でも危険」「絶対に漏れていない」「配布されたので自分の環境も更新済み」とまでは読めません。特に、修正版が配られたことと、自分の環境へ入ったことは別々に確かめます。
実際のお知らせでは、まず次の3点を探します。
- 対象：自分の製品、版、利用方法が含まれるか。
- 修正：修正版はあるか。誰が適用し、自分に操作が必要か。
- 被害の情報：確認済みのことは何か。調査中の部分はどこか。
長いCVE番号が載っていたら、別の資料でも同じ問題を指しているか照合するために使えます。CVEとCVSSの読み方を知ると、番号と深刻度も読み分けられます。
ニュースを一つ読み終えたら、自分に関わる製品が対象か、修正の案内はどこにあるかを確かめてみましょう。被害について分からない点は、分からないまま分けておけます。別の具体例で練習したい人は、PHP脆弱性2件の影響と修正版で、対象と修正の読み方を確かめられます。
