2026.10.04 セキュリティ

デジタル庁GSSの不正アクセスと約24.6万件｜CVSS中のVPN脆弱性を何で優先するか

デジタル庁は2026年9月11日、同庁が運用するガバメントソリューションサービス（GSS）が外部から不正アクセスを受け、職員などの個人情報約24.6万件が漏えいした可能性があると公表しました。侵入口はVPN機器の脆弱性で、翌12日に更新されたQ&Aでは、その脆弱性の評価がCVSSで「中（Medium）」だったこと、修正プログラムを当てる前に悪用されたことが明かされています。本記事で読み解くのは、公式発表に基づく経過と件数、そしてCVSSの深刻度だけで対応順を決めると何が漏れるのかという問題です。後半では、悪用の実績と確率で優先度を決めるKEV・EPSS・SSVCの使い方を、そのまま動くPythonスクリプトで示します。

まとめ：デジタル庁GSSの不正アクセスで公表された事実と運用側が今やること

確定しているのは、2026年6月25日に保守運用担当者のアカウントによる大量のファイルアクセスを検知し、7月9日にVPN機器の脆弱性を突いた第三者の侵入と判明して、同日にアカウント停止と通信遮断を行ったことです。漏えいした可能性があるのは約24.6万件で、氏名・メールアドレス・電話番号・住所などが含まれます。マイナンバー、金融機関口座情報、年金番号は含まれていません。VPN機器の製品名と脆弱性の識別番号は公表されていません。

開発・運用の側が受け取るべき教訓は一つに絞れます。CVSSの深刻度が中の脆弱性でも、社外に公開した機器なら修正前に狙われるという点です。自社のVPN機器やリモート接続の入口について、悪用の実績（KEV）と悪用の確率（EPSS）を毎日確かめ、深刻度とは別の軸で修正の順番を決める運用に切り替えてください。

項目	公表されている内容
検知	2026年6月25日
侵入経路の判明・遮断	2026年7月9日
個人情報保護委員会へ報告	2026年7月15日
公表	2026年9月11日
件数	約24.6万件
侵入口	VPN機器の脆弱性
脆弱性の評価	CVSSで中（Medium）
製品名・CVE	未公表

公表内容を時系列で確認する｜6月25日の検知から9月11日の公表まで

6月25日の大量アクセス検知から7月9日の侵入経路判明までの14日間

デジタル庁の公表（2026年9月11日）によると、令和8年6月25日、保守運用担当者のアカウントを利用してサーバ上の大量のファイルへのアクセスが行われたことを検知し、調査を始めました。7月9日、第三者がネットワーク接続機器（VPN）の脆弱性を利用してシステムに侵入していたことが判明します。同日、当該アカウントを停止し、侵害された機器と外部との通信を遮断しました。

検知から侵入経路の特定までは14日かかっています。検知のきっかけは正規の保守運用アカウントによる操作だったため、外部からの侵入かどうかの切り分けから調べる必要がありました。アカウントの停止と通信の遮断は、侵入経路が判明した7月9日に行われています。

7月15日の個人情報保護委員会への報告から9月11日の公表までの約2か月

本事案に関するQ&Aは9月12日の追記で、個人情報保護委員会へ7月15日に報告したと明らかにしました。その後も対象者の範囲と漏えいした可能性のある情報の内容を調べ、9月11日の公表に至っています。公表まで時間がかかった理由について、Q&Aは侵入経路の分析や対象者の確認に相当の時間を要したと説明しています。

民間事業者の場合、委員会への速報は発覚から3〜5日以内、確報は30日以内（不正の目的によるものは60日以内）が目安です。本人への通知や公表の時期をどう決めるかは別の判断になります。手順の全体は個人情報保護委員会への報告義務で整理しています。

漏えいした可能性がある約24.6万件の内訳と含まれていない情報

約24.6万件の内訳は、GSS利用機関の職員と業務に携わった公務員等（独立行政法人の職員を含む）が約18.9万件、業務に携わった事業者と個人が約5.7万件です。項目別では重複を含めて次のとおりです。

項目	件数
氏名	約23.6万件
メールアドレス	約23.1万件
電話番号	約9.4万件
住所	約0.1万件

Q&Aによると、これらは利用者登録の申請書に書かれた情報で、電話番号や住所の大半は府省庁の庁舎所在地や公務用の連絡先です。一般の国民の個人情報は含まれません。ただし事業者側には、省庁の業務に携わった企業の従業員や個人事業主、省庁のWeb会議に参加した人の氏名と業務用の連絡先が含まれます。

対象となる職員・事業者への個別連絡の方法となりすまし連絡への備え

デジタル庁は対象者を特定したうえで、順次個別に連絡するとしています。現時点で二次被害は確認されていません。一方で、漏えいした可能性のある情報が、なりすましメールやフィッシングに使われるおそれがあると注意を促しています。デジタル庁が認証情報やクレジットカード情報をメールや電話で尋ねることはありません。

氏名と業務用メールアドレスの組み合わせは、取引先や省庁の担当者を装う標的型メールの材料になります。省庁の案件に関わった企業は、従業員に向けて「デジタル庁や関係機関を名乗る連絡のリンクを開かない」と周知しておくと安全です。問い合わせ窓口は専用フリーダイヤル0120-360-036です。

CVSS評価が中のVPN脆弱性が悪用された構図｜修正プログラム適用前の空白

Q&Aが明かした「中（Medium）」評価と攻撃前に公表済みだった二つの事実

Q&Aは、悪用された脆弱性が当初公表されていた評価ではCVSSで中（Medium）だったこと、攻撃が確認される前に公表済みだったことを認めています。具体的な内容は、今後のセキュリティ確保に支障を及ぼすおそれがあるとして答えていません。

対応の速さについても書かれています。デジタル庁は、公表時の深刻度評価に応じた一般的な対応よりも早く対処を進めていたものの、修正プログラムの適用前に悪用されたという説明です。松本大臣の記者会見でも、緊急度が高いものではないという深刻度評価に応じて順番にパッチを当てる作業の間にハッキングされた、という理解が示されました。

CVSSが答えるのは深刻度で、悪用されるかどうかは答えない理由

CVSSは、脆弱性が悪用されたときの影響の大きさを0.0〜10.0で表す指標です。FIRSTのCVSS v4.0仕様でも、基本値は脆弱性そのものの性質を表し、攻撃が実際に起きているかは脅威の指標として別に扱う構成になっています。基本値だけで並べれば、悪用の有無は順番に入りません。

この差は数字にも表れます。FIRSTのUsing EPSSによると、直近12か月に公開されたCVEは約6.1万件で、CVSSでCriticalになったのは1割強です。一方、悪用の活動が観測されているのは公開済み脆弱性の1.5〜3%にとどまります。深刻度の高い順に当てていく方法では、実際に狙われている少数の脆弱性への対応が後回しになるおそれがあるのです。評価の読み方の基礎はCVSSとはで解説しています。

ゼロトラスト採用下でもVPN機器が入口になった境界の手前という論点

Q&Aは、GSSがゼロトラストアーキテクチャを採用していたことを認めたうえで、結果として不正アクセスを許したことを重く受け止めるとしています。構成の詳細は攻撃者を利するとして明かしていません。

NIST SP 800-207が描くゼロトラストは、ネットワーク上の位置で信頼せず、要求ごとに認証と認可を行う考え方です。それでもVPN機器のようにインターネットへ直接口を開けた装置が残っていれば、そこが認証の手前で破られる余地になります。公表から確認できるのは、VPN機器の脆弱性を突かれたことと、保守運用担当者のアカウントが使われたことまでです。運用者が入る経路は、利用者向けの入口と同じ厳しさで守る対象になります。VPNとZTNAの違いはゼロトラストネットワーク（ZTNA）とはで比べています。

CVSSだけで並べない優先度判定｜KEV・EPSS・SSVCを組み合わせる手順

CISAのKEVカタログで悪用済みかを確かめる・VPN関連の登録39件

最初に見るべきなのは、その脆弱性がすでに悪用されているかどうかです。米CISAのKnown Exploited Vulnerabilities（KEV）カタログは、実際の悪用が確認された脆弱性の一覧で、JSONでも配布されています。2026年10月4日に取得した版（catalogVersion 2026.10.02）は1,733件でした。

このうち、製品名・脆弱性名・説明文のいずれかにVPNを含む登録は39件あり、ベンダー別ではCisco 12件、Fortinet 6件、Citrix 5件が上位です。2026年に追加された分だけでもPalo Alto NetworksのPAN-OS、Check Point、CitrixのNetScalerが並びます。自社のVPN機器のベンダーがこの一覧に何度も出てくるなら、その機器の新しい脆弱性は深刻度にかかわらず先に当てる、と決めておくのが現実的です。FortiGateを使っている場合はFortinetの脆弱性まとめも確認してください。

EPSSの30日以内悪用確率とCVSSの深刻度を並べたときの差

KEVに載るのは悪用が確認された後です。その手前の兆しを数字で見るのがEPSSで、FIRSTが公開する、今後30日以内に悪用される確率の推定値です。Using EPSSは、CVSSでCriticalだけを対象にするのと同じ作業量なら、EPSSでは90パーセンタイル（0.04以上）が目安になると示しています。

EPSSは無料のAPIで引けます。CVEを指定すると、確率（epss）と全CVE中の順位（percentile）が返ります。

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-21887,CVE-2023-46805"

2026年10月4日の実行では、Ivanti Connect Secureの2件がいずれも0.999台でした。CVSSの点数と見比べると、点数の高低と悪用の確率が揃わない例がすぐ見つかります。

BOD 26-04が是正期限を決める4つの変数と3日以内の最短区分

米連邦機関向けの指令も、深刻度だけで期限を決める方式から離れています。2026年6月10日に出たBOD 26-04は、KEVの期日内是正を求めていたBOD 22-01とBOD 19-02を失効させ、次の4つの変数で期限を決める方式に置き換えました。

Asset Exposure：脆弱な資産がインターネットに公開されているか
KEV Status：KEVカタログに載っているか
Exploit Automation：攻撃の手順をすべて自動化できるか
Technical Impact：攻撃者が得るのが部分的な制御か完全な制御か

公開資産・KEV掲載・自動化可能・完全な制御がそろうと、期限は3日以内で、侵害の有無を調べるforensic triageも求められます。反対の組み合わせであれば、対応時期は次回の定期アップグレードでよいという区分です。後ろの2つの判定値は、CISAがVulnrichmentでCVEごとにSSVCの形式で公開しています。社外公開のVPN機器は1つ目の変数が常に「公開」なので、この枠組みでは最も厳しい側に寄ります。

KEV・EPSS・SSVCを一度に引くPythonスクリプト｜VPN機器のCVE優先順

標準ライブラリだけで動くトリアージスクリプトの全体とVPN機器の実行例

ベンダーの勧告に並んだCVEを渡すと、KEV掲載の有無、EPSS、VulnrichmentのSSVC判定値を1行ずつ出すスクリプトです。Python 3の標準ライブラリだけで動き、APIキーは要りません。triage.pyとして保存します。

import json, sys, urllib.request

KEV = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json"
EPSS = "https://api.first.org/data/v1/epss?cve="
VR = "https://raw.githubusercontent.com/cisagov/vulnrichment/develop/{y}/{d}xxx/{c}.json"

def get(url):
    req = urllib.request.Request(url, headers={"User-Agent": "vuln-triage"})
    with urllib.request.urlopen(req, timeout=30) as r:
        return json.load(r)

def ssvc(cve):
    _, y, n = cve.split("-")
    try:
        doc = get(VR.format(y=y, d=n[:-3] or "0", c=cve))
    except Exception:
        return {}
    for adp in doc["containers"].get("adp", []):
        for m in adp.get("metrics", []):
            o = m.get("other", {})
            if o.get("type") == "ssvc":
                return {k: v for opt in o["content"]["options"] for k, v in opt.items()}
    return {}

cves = sys.argv[1:]
kev = {v["cveID"]: v for v in get(KEV)["vulnerabilities"]}
epss = {e["cve"]: float(e["epss"]) for e in get(EPSS + ",".join(cves))["data"]}

for c in cves:
    s = ssvc(c)
    print(c, "KEV" if c in kev else "-", f"EPSS={epss.get(c, 0):.3f}",
          s.get("Exploitation", "?"), s.get("Automatable", "?"), s.get("Technical Impact", "?"))

VPN製品のCVEを4件渡した実行結果です（2026年10月4日）。

$ python triage.py CVE-2024-21887 CVE-2023-46805 CVE-2026-0257 CVE-2024-3400
CVE-2024-21887 KEV EPSS=1.000 active no total
CVE-2023-46805 KEV EPSS=1.000 active yes partial
CVE-2026-0257 KEV EPSS=0.964 active no total
CVE-2024-3400 KEV EPSS=1.000 active yes total

出力の読み方と社外公開のVPN機器に当てはめる優先順位の決め方

列は左から、KEV掲載、EPSS、SSVCのExploitation（none／poc／active）、Automatable（yes／no）、Technical Impact（partial／total）です。VulnrichmentはJSONのcontainers.adpの中に、CISA ADPとしてSSVCの判定を格納しています。CISAがまだ判定していないCVEは「?」と表示されます。

社外公開のVPN機器なら、判定は次の順で足ります。KEVに載るか、Exploitationがactiveなら、深刻度にかかわらず当日中に修正か回避策を入れ、侵害の痕跡も調べます。EPSSが0.04以上か、Exploitationがpocなら、その脆弱性は週内の対応計画に入れる対象です。どれにも当たらない場合だけ、CVSSの深刻度に沿った通常の順番に戻します。毎朝このスクリプトを自社機器のCVE一覧で回せば、今回のように中評価の脆弱性が狙われ始めた変化を、KEVやEPSSの更新から拾えます。継続的に露出を測る運用の全体像を確認できるのが、CTEMとはの解説記事です。

侵入された後に気付くための監視｜保守運用アカウントの大量アクセス検知

保守運用担当者アカウントの大量ファイルアクセスが検知の起点になった意味

今回の検知は、VPN機器そのものの警報ではなく、保守運用担当者のアカウントがサーバ上の大量のファイルにアクセスしたことがきっかけでした。入口を破られた後でも、普段と違う量の読み取りを捉えられれば被害の拡大を止められる、という例です。

裏返すと、読み取りの量に基準がなければ気付けません。保守用のアカウントは広い権限を持つ一方、日々のファイルアクセスは少ないことが多く、普段の件数と比べた急増は検知しやすい信号です。どのログで何を見るかは不正アクセスのログ確認・解析方法が参考になります。

VPN経由で入る保守用アカウントに付けておく検知条件と権限の分け方

VPN経由で入る保守用アカウントには、次の条件をまとめて掛けておくと、侵入から検知までの時間を縮められます。

接続元のIPアドレスと時間帯を作業予定に限定し、それ以外の接続を警報にする
1時間あたりのファイル読み取り件数に上限を置き、普段の数倍で通知する
保守用と業務データ閲覧用のアカウントを分け、保守用からは個人情報のファイルを読めなくする
VPN機器の管理画面とログを、VPNを通らない別経路でも見られるようにしておく

なかでも効くのは三つ目です。今回漏えいした可能性があるのは利用者登録の申請書で、保守用アカウントから読める場所にありました。権限を分けておけば、VPNを破られても読める範囲はその分だけ狭くなります。侵入経路が分からない段階で学外向けの事務用VPNと研究用VPNをまとめて止めたと報じられた佐賀大学のランサムウェア被害も、入口と届く範囲を分けて考える材料になります。

KEV連動の即日対応を入れるべき組織と過剰になる組織の判断基準

社外公開のVPN機器を持つ組織でKEV連動の即日対応を採るべき条件

VPN機器やリモートアクセスの装置をインターネットに公開しているなら、KEVとEPSSを毎日確かめる運用は必ず入れてください。公開されている機器は、BOD 26-04の4変数のうち最も重い一つを常に満たしています。修正が出ても深刻度が中だからと翌月の定期作業に回す運用は、今回と同じ空白を作ります。

個人情報を扱うシステムに保守用の経路でつながっている場合は、なおさらです。入口の機器と中のデータが一本の経路でつながっていると、機器の脆弱性一つで個人情報の漏えいまで届きます。2026年10月に届出・報告義務が施行されるサイバー対処能力強化法の対象になる事業者は、報告の段取りも含めて見直す時期です。

公開資産を持たない小規模環境で過剰になる場面と代わりにやること

社外に公開した機器がなく、リモート接続はクラウドの管理サービスに任せている小規模な環境では、毎日スクリプトを回す運用は過剰です。その場合は、使っているサービスのセキュリティ告知を購読し、公開資産が増えたときにだけこの運用へ切り替える、という順序で足ります。

判断に迷うのは、自社にどの機器が公開されているかを把握できていない場合です。外から見える入口と、破られたときに何が読めるかを第三者の目で確かめたいときは、脆弱性診断・セキュリティ診断で、VPN機器から業務システムまでの経路を含めて点検できます。

よくある質問

デジタル庁のGSSへの不正アクセスについて、対象者と開発・運用の担当者から出やすい質問をまとめました。

一般の国民の個人情報は漏えいしていますか？

デジタル庁は、一般の国民の個人情報は含まれないと説明しています。対象はGSSを利用する府省庁等の職員、業務に携わった公務員等、業務に携わった事業者と個人です。事業者側には、省庁のWeb会議に参加した人の氏名や業務用の連絡先も含まれるため、省庁の案件に関わった企業の従業員は対象になりえます。マイナンバー、金融機関口座情報、年金番号は含まれていません。

悪用されたVPN機器の製品名やCVEは公表されていますか？

公表されていません。Q&Aは、当初の評価がCVSSで中（Medium）だったこと、攻撃前に公表済みだったことだけを示し、具体的な内容は今後のセキュリティ確保に支障を及ぼすおそれがあるとして答えていません。公式発表で確認できない以上、特定の製品の利用者だけが対象だと決めつけず、自社で使っているVPN機器すべてを点検の対象にしてください。

CVSSが中の脆弱性はどのくらいの期限で直すべきですか？

深刻度だけで期限を決めないのが答えです。KEVに載っている、またはEPSSが0.04以上なら、深刻度が中でも優先して直します。社外に公開した機器であれば、BOD 26-04の考え方では最も厳しい組み合わせで3日以内が目安になります。どの指標にも当たらない社内向けの機器なら、深刻度に沿った通常の順番で構いません。

ゼロトラストを導入していれば今回のような侵入は防げますか？

GSSはゼロトラストアーキテクチャを採用していましたが、侵入を防げませんでした。ゼロトラストは要求ごとに認証と認可を行う考え方で、インターネットに口を開けたVPN機器が残っていれば、そこは認証の手前で破られる余地になります。VPN機器を減らすか、残すなら修正の速さと保守用アカウントの権限分離を併せて設計する必要があります。

自社のVPN機器について、何から見直せばよいですか？

最初に、インターネットに公開している機器と、その機器から到達できるシステムを一覧にします。次に行うのは、各機器のベンダーの勧告に出ているCVEを本記事のスクリプトでKEV・EPSS・SSVCと突き合わせ、修正の順番を決め直す作業です。最後に、保守用アカウントの接続元制限と読み取り件数の監視を入れ、破られた後に気付ける状態にします。