CVE-2019-1068 SQL Server RCE｜KEV 追加と影響確認

はじめに

2026 年 8 月 26 日、CISA は Known Exploited Vulnerabilities（KEV）Catalog へ CVE-2019-1068 を追加しました。Microsoft SQL Server のリモートコード実行の脆弱性で、修正自体は 2019 年 7 月 9 日のセキュリティ更新として提供済みのものです。

CISA が公開しているのは、実際の悪用が確認されたという事実と、KEV への追加日までです。どのような環境が狙われているかは公表されていません。ただし修正が 7 年前に提供済みである以上、運用側で確認すべき点は「当時の更新が自環境に適用されているか」に絞り込めます。対象は SQL Server 2014 / 2016 / 2017 であり、2026 年時点では延長サポート終了済み、ESU 利用中、延長サポート期間中の環境が混在しています。この記事では、担当者が自環境の状態を切り分けられるところまでを整理します。

結論から示します。CVE-2019-1068 は 2019 年 7 月 9 日に公開された 10 本のセキュリティ更新で修正済みであり、その後にリリースされた更新にも修正は取り込まれています。判断の要点は、自インスタンスが GDR 系列と CU 系列のどちらに乗っているかを特定したうえで、その系列の修正ビルドと比較することです。系列をまたいでビルド番号を単純に大小比較すると、未修正の環境を修正済みと誤判定します。

CVE-2019-1068 とは

まず、脆弱性そのものの性質と、2026 年に KEV へ追加された背景を整理します。

2019 年に修正された脆弱性が 2026 年に KEV へ追加

CVE-2019-1068 は Microsoft を CNA として 2019 年 7 月 15 日に公開された CVE です。SQL Server が内部関数の処理を適切に扱わないことに起因し、悪用に成功した攻撃者は SQL Server Database Engine サービスアカウントのコンテキストでコードを実行できるとされています。CISA-ADP は CWE-20（Improper Input Validation）を付与しています。

参考: CVE Record（CVE-2019-1068）
“execute code in the context of the SQL Server Database Engine service account”
（SQL Server Database Engine サービスアカウントのコンテキストでコードを実行する）
https://www.cve.org/CVERecord?id=CVE-2019-1068

CISA は 2026 年 8 月 26 日、実際の悪用を根拠として本 CVE を KEV Catalog へ追加しました。同日のアラートでは、本 CVE を含む 6 件が追加されています。同日付で CISA-ADP が付与した SSVC の判定は次のとおりです。

Exploitation: active

実際の悪用が確認されている状態を示す判定です。具体的な攻撃キャンペーン名、初期侵入経路、IOC は、本記事執筆時点の一次情報では公開されていません。

Automatable: no

偵察から悪用までの一連の工程を攻撃者が自動化できるとは判定されなかった、という意味です。SSVC の判定はここまでで、攻撃者の狙いや標的の選び方までは示していません。

Technical Impact: total

悪用に成功した場合、対象コンポーネントの制御を全面的に奪われるという判定です。SQL Server のサービスアカウント権限が、そのまま攻撃者の権限になります。

KEV エントリーの対応期限は 2026 年 8 月 29 日、ランサムウェアキャンペーンでの利用は Unknown と記載されています。この期限は BOD 26-04 に基づく米国連邦政府機関（FCEB）向けの要件であり、日本の一般企業に同じ法的期限が課されるものではありません。とはいえ、実悪用が確認された脆弱性であることに変わりはないため、優先度の判断材料として扱う価値はあります。

CVSS と攻撃成立条件

CVSS の評価は出典によって記載が分かれます。現在の値を整理すると次のとおりです。

NVD のレコードは KEV 追加と同じ 2026 年 8 月 26 日に再解析されており、現在の CVSS 3.x は 3.1 として公開されています。それ以前の NVD レコードでは同じスコアが CVSS 3.0 として付与されていたため、再解析前のデータを取り込んだ脆弱性管理ツールやミラーサイトでは 3.0 と表示される場合があります。スコアとベクターの内容は変わらないため、バージョン表記の差で判断が変わることはありません。

ここで注意したいのが Privileges Required（PR）です。PR:L であるため、攻撃者には何らかの権限を持った状態が前提として必要であり、「認証不要のリモートコード実行」ではありません。この点は CVSS 2.0 のベクターでも裏付けられます。Authentication が Au:S、つまり 1 回の認証を要すると評価されているためです。Attack Vector が Network である点だけを取り出して、インターネットに公開しているだけで無条件に侵害されると説明するのは、一次情報が示す範囲を超えます。

一方で、Attack Complexity が Low、User Interaction が None であることから、必要な権限さえ得られれば攻撃の再現性は高いと読めます。低権限のアプリケーションアカウントが漏えいしている環境や、複数のシステムでデータベースログインを共用している環境では、影響の見積もりを高めに置くのが妥当です。

影響を受ける SQL Server と 2019 年の修正ビルド

「SQL Server 2014 から 2017 が対象」とまとめてしまうと、実際の判定はできません。CVE Record と Microsoft の更新 KB を突き合わせて、系列単位で整理します。

CVE Record に記載された対象

NVD はこれに加えて、CPE の設定として影響を受けるビルド範囲を公開しています。SQL Server 2016 と 2017 については、系列ごとに下限と上限が示されています。

各範囲の下限が Service Pack や RTM のベースラインになっている点に注目してください。SQL Server 2014 については CPE が Service Pack 単位のみで、ビルド範囲は示されていません。

記載がない構成を「対象外」と読まない

CVE Record の affected にも NVD の CPE 範囲にも、SQL Server 2014 SP1 や SQL Server 2016 RTM は登場しません。ここで誤読しやすいのが、記載がないことを「影響を受けない」と解釈してしまうことです。

これらの構成は 2019 年 7 月の時点ですでにサポート対象から外れており、Microsoft の評価と修正提供の対象になっていません。affected への記載がないことは、その構成が安全であることの証明ではなく、そもそも評価されていないことを意味します。より古い Service Pack のまま運用しているインスタンスがある場合は、対象外として処理せず、サポート対象のベースラインへ引き上げたうえで改めて判定してください。

Linux 版 SQL Server 2017 の扱い

CVE Record の affected は x64 という粒度で記載されており、Windows と Linux の区別はありません。更新プログラム側の公式情報を確認すると、KB4505224 と KB4505225 はいずれも Windows 向けの実行形式パッケージとして公開されており、Microsoft Download Center 上の対応 OS も Windows 系のみが挙げられています。

この点について、Microsoft は Linux 版のリリースノートで、GDR には Windows のみを対象とするものがあり、そうしたリリースは Linux 向けには公開されないと明記しています。したがって Linux 上で SQL Server 2017 を稼働させている場合、2019 年 7 月の GDR パッケージを探すのではなく、CU リポジトリ経由で修正を含む CU ビルド以上へ更新するのが公式の経路になります。判定に使うビルドの基準値（CU 系列は 14.0.3192.2）は Windows と共通です。

GDR 系列と CU 系列の違い

SQL Server の更新には 2 つの系列があり、どちらに乗っているかでビルド番号の体系が変わります。ここを取り違えると判定を誤ります。Microsoft はサービシングベースライン（RTM または Service Pack）配下のブランチとして、これらを次のように説明しています。

参考: Microsoft Learn（Changes to Microsoft Update detection logic）
“A General Distribution Release (GDR) branch that contains only security and other critical fixes.”
（セキュリティ修正とその他の重要な修正のみを含む GDR ブランチ）
https://learn.microsoft.com/ja-jp/troubleshoot/sql/database-engine/install/windows/new-mu-servicing-model

GDR 系列（GDR ブランチ）

セキュリティ修正とその他の重要な修正のみを含む系列です。累積更新に含まれるその他の修正は入りません。CU を一度も適用していないインスタンスはこちらに該当します。

CU 系列（CU ブランチ）

セキュリティ修正と重要な修正に加え、そのベースライン向けの他のすべての修正を含む系列です。一度 CU を適用すると以後は CU 系列として扱われ、セキュリティ修正は「CUn + GDR」という形で提供されます。ビルド番号は GDR 系列より大きな値を取ります。

Microsoft Update の検出ロジックは、ベースライン上または GDR 系列上のインスタンスに対して GDR 系列の更新を提示します。CU 系列へ移った後は、次の Service Pack でベースラインがリセットされるか、CU をすべてアンインストールしない限り GDR 系列へは戻りません。この非可逆性が、判定時に系列を先に確定させる必要がある理由です。

修正ビルドと更新 KB の一覧

2019 年 7 月 9 日に公開された 10 本の更新と、それぞれが到達するビルドは次のとおりです。値は Microsoft の build versions ドキュメントに基づいています。

SQL Server の更新は累積的に提供されるため、2019 年 7 月 9 日より後にリリースされた同系列の更新を適用していれば、CVE-2019-1068 の修正も含まれます。たとえば SQL Server 2016 SP2 CU8（13.0.5426.0、2019 年 7 月 31 日）は CU7 + GDR より後のリリースであり、修正を取り込んだ状態です。

ビルド番号の単純比較が誤判定になる例

実務で最も事故が起きやすいのが、自分の系列と別の系列の修正ビルドを比べてしまうケースです。具体例を挙げます。

いずれも数値としては GDR の修正ビルドを上回っていますが、CU 系列としては修正前のビルドです。GDR 系列の値と比較して「修正済み」と判断すると、実際には未修正のまま運用を続けることになります。判定は、必ず自インスタンスと同じ系列の行と比較してください。

自環境が対策済みかを確認する

ここからは、実際に手を動かして判定する手順です。SQL Server 側で取得できる情報から系列とビルドを確定し、build versions と照合します。

SQL Server のバージョンとビルドを確認する

最も簡便なのは SELECT @@VERSION ですが、系列の判定には SERVERPROPERTY 関数のほうが情報量があります。次のクエリを対象インスタンスで実行します。

SELECT
    SERVERPROPERTY('ProductVersion')         AS ProductVersion,
    SERVERPROPERTY('ProductLevel')           AS ProductLevel,
    SERVERPROPERTY('ProductUpdateLevel')     AS ProductUpdateLevel,
    SERVERPROPERTY('ProductBuildType')       AS ProductBuildType,
    SERVERPROPERTY('ProductUpdateReference') AS ProductUpdateReference,
    SERVERPROPERTY('Edition')                AS Edition;

各プロパティの意味は Microsoft の T-SQL リファレンスに定義されています。ProductVersion は major.minor.build.revision 形式のビルド、ProductLevel は RTM または SPn、ProductUpdateLevel は CUn または NULL、ProductUpdateReference はそのリリースの KB 番号を返します。系列の判定に直結するのが ProductBuildType です。

参考: Microsoft Learn（SERVERPROPERTY (Transact-SQL)）
“GDR = General Distribution Release released through Windows Update.”
（GDR は Windows Update を通じて提供される一般配布リリースを示す）
https://learn.microsoft.com/ja-jp/sql/t-sql/functions/serverproperty-transact-sql

これらのプロパティは NULL を返す場合があります。ProductUpdateLevel と ProductBuildType がともに NULL のときは、ProductVersion の値を build versions の表と突き合わせて系列を特定します。

取得した ProductLevel と ProductUpdateLevel の組み合わせで、前章の表のどの行に該当するかが決まります。たとえば ProductLevel が SP2、ProductUpdateLevel が CU7、ProductVersion が 13.0.5337.0 であれば、SQL Server 2016 SP2 の CU 系列であり、比較対象は 13.0.5366.0 になります。

影響確認と対応判断のフロー

ここまでの内容を、運用担当者がそのまま実施できる順序に落とし込みます。

未対応だった場合の対処

照合の結果、修正ビルドに達していなかった場合の考え方を整理します。

2019 年の KB をそのまま適用するとは限らない

2026 年時点で未修正のインスタンスは、2019 年 7 月以降のセキュリティ更新も広範に未適用である可能性が高い状態です。CVE-2019-1068 専用の KB を単体で適用しても、その後 7 年分の修正は残ります。現実的な対応は、対象世代で現在入手できる最新の更新まで一気に引き上げることです。

ここで問題になるのが、どこまで引き上げるかです。各世代の最新ビルドは毎月の Patch Tuesday で変わるため、記事側で固定値を並べても短期間で陳腐化します。実際の作業では、Microsoft が維持している次のページで、対象世代の現在の最新更新を確認してください。

参考: Microsoft Learn（Latest updates and version history for SQL Server）
https://learn.microsoft.com/ja-jp/troubleshoot/sql/releases/download-and-install-latest-updates

一方で、どの系列が更新の提供を終えているかは時点に依存しない情報です。ここを押さえておくと、最新ビルドを調べる前に「そもそも今の Service Pack のままでは更新を受け取れない」というケースを判別できます。

SQL Server 2016 SP1 で止まっているインスタンスは、CVE-2019-1068 の修正が入っていたとしても、それ以降のセキュリティ修正を一切受け取っていない状態です。この場合、本 CVE への対応だけを考えるのではなく、SP3 への引き上げを含めた計画として扱う必要があります。

GDR 系列から CU 系列へ移る変更は、機能修正が一括で入るため後戻りしにくい判断になります。検証環境での動作確認と、適用前のバックアップ取得を先に済ませておくと安全です。

ネットワーク到達性の見直しは CVE 固有の回避策ではない

確認できた一次情報の範囲では、Microsoft は CVE-2019-1068 に対して更新プログラムの適用以外の回避策や緩和策を示していません。したがって、TCP 1433 の遮断やファイアウォールの調整を「この CVE の対策」として位置づけることはできません。

一方で、データベースサーバーの公開範囲を見直すこと自体は一般的な防御として有効です。不要なセグメントからの到達性を絞る、サービスアカウントの権限を必要最小限にする、共用されているデータベースログインを整理するといった対応は、本 CVE に限らず有効に働きます。CVE 固有の対策と一般的なハードニングは、報告や台帳の上でも分けて記録することを推奨します。

適用後の確認

更新適用後は、同じ SERVERPROPERTY クエリを再実行し、ProductVersion が目的の修正ビルド以上になっていることを確認します。あわせて、更新 KB に記載された Analysis Services 側のビルドも一致しているかを確認すると、コンポーネント単位の適用漏れを検出できます。KB4505217 のように、SQL Server と Analysis Services の到達ビルドが KB 内に明記されている更新もあります。

SQL Server 2014 / 2016 / 2017 のサポート状況と ESU

本 CVE への対応と、製品ライフサイクルへの対応は別の論点です。混同しないよう、順に整理します。

参考: Microsoft Learn（Extended Security Updates FAQ – SQL Server）
“ESUs are available until July 17, 2029.”
（ESU は 2029 年 7 月 17 日まで提供される）
https://learn.microsoft.com/ja-jp/sql/sql-server/end-of-support/extended-security-updates-frequently-asked-questions

ESU で受け取れるものと受け取れないもの

ESU は、MSRC が Critical と評価した脆弱性が見つかったときに必要に応じて提供される仕組みであり、毎月の定期更新ではありません。新機能、機能改善、顧客要望による修正は含まれません。SQL Server 2014 については、本記事執筆時点で Microsoft のページ上に発行済みの ESU が掲載されていない状態です。ESU 加入によって毎月のセキュリティ更新が届くと期待すると、運用設計を誤ります。

エディションの条件にも注意が必要です。Microsoft のページでは、SQL Server 2016 の ESU 対象は Enterprise 版と Standard 版であり、Express、Web、Developer 版は対象外と記載されています。ページによってエディションの記載に差異があるため、契約検討時には最新の公式ページで確認することを推奨します。

EOL と CVE-2019-1068 の修正有無は分けて考える

ここが最も誤解されやすい点です。CVE-2019-1068 の修正は 2019 年の通常サポート期間中に提供済みであり、ESU への加入は本 CVE を修正するための条件ではありません。延長サポートが終了した SQL Server 2014 / 2016 であっても、当時の更新、あるいはその後 2024 年や 2026 年までにリリースされた更新を適用していれば、本 CVE については修正済みです。

整理すると、判断は次の 2 軸に分かれます。

• CVE-2019-1068 への対応: 2019 年 7 月 9 日以降の同系列の更新が適用されているかどうか
• 製品サポートへの対応: 今後発見される脆弱性の修正を受け取れる状態にあるかどうか

前者は既存の更新を適用すれば解決します。後者は、サポート対象世代へのアップグレードか Azure SQL への移行、あるいは移行までの期間を埋める ESU 加入という選択になります。今回の KEV 追加を、後者の議論を社内で進める材料として使う形が現実的です。

まとめ

CVE-2019-1068 は 2019 年に修正が提供された SQL Server のリモートコード実行の脆弱性であり、2026 年 8 月 26 日に実悪用を根拠として KEV Catalog へ追加されました。運用担当者にとっての本質は、新しい脅威が生まれたことではなく、7 年前の更新が適用されないまま残っているインスタンスの有無を確認できるかどうかです。系列を取り違えないビルド照合が、そのまま判定の精度になります。

• 2026 年 8 月 26 日に KEV 追加、対応期限 2026 年 8 月 29 日は FCEB 向け
• CVSS は 8.8 だが PR:L、CVSS 2.0 も Au:S で認証を前提とする評価
• 対象は 2014 SP2 / SP3、2016 SP1 / SP2、2017 で、記載外の旧 SP は評価対象外
• 判定は SERVERPROPERTY で系列を特定し、同一系列の修正ビルドと照合する
• 系列をまたいだビルド番号の大小比較は未修正環境の見落としにつながる
• EOL や ESU の加入状況は、本 CVE の修正有無とは別の論点
• 未修正なら 2019 年の KB 単体ではなく、公式ページで現行の最新更新を確認

以上、最後までお読みいただきありがとうございました。