Microsoftは、YAML形式の文書を読み込む部品の脆弱性「CVE-2026-72923」を公表しています。細工されたOpenAPI文書を解析すると、メモリを過剰に消費し、処理を実行するプロセスが終了する恐れがあります。提供された資料には公表日の記載がありません。
小さな文書でも解析処理が膨らむ
対象は、APIの仕様を記述するOpenAPI文書を、公開されたYAML読込APIで解析する処理です。APIは、ソフトウェアの機能を呼び出すための窓口を指します。今回の問題はDoS、つまりサービスの利用を妨げる脆弱性です。
原因となるのは、YAMLのアンカーと別名参照を入れ子にした文書です。これらは、文書内のデータに名前を付け、別の場所から参照する仕組みです。Microsoftによると、YAMLからJSON形式へ変換するときに参照先が展開され、処理量が指数的に増えます。そのため、元の文書が小さくても、解析時に大量のメモリを消費する恐れがあります。
報告されている影響は、可用性、つまり処理を利用し続けられることへの影響と、プロセスの終了です。Microsoftは、遠隔から任意のコードを実行されることや情報流出、同社が運営するサービスへの影響を主張していません。ただし、これはそれらの被害が報告対象に含まれていないという説明であり、今回の問題を情報漏えいとして扱う根拠はありません。
使用中の系列ごとに更新先を確認
対象となるパッケージと修正版は、次のとおりです。
- Microsoft.OpenApi.YamlReaderの2.X系：2.0.0-preview.11以上、2.12.0未満が対象です。2.12.0以降で修正済みです。
- Microsoft.OpenApi.YamlReaderの3.X系：3.0.0以上、3.10.0未満が対象です。3.10.0以降で修正済みです。
- Microsoft.OpenApi.Readersの1.X系：1.6.30未満が対象です。1.6.30以降で修正済みです。
Microsoftは、利用中のメジャーバージョンに応じた修正版への更新を推奨しています。すべてを同じ系列へ移すのではなく、現在使っているパッケージ名と系列を先に確認する必要があります。
修正版は、YAMLからJSONへの変換処理に上限を設けます。既定のノード数上限は5,000,000、入れ子の深度上限は64です。上限を超えると診断エラーを返し、解析済み文書は返しません。更新後は、エラーを受け取る側の処理も確認対象になります。
日本での提供は発表には書かれていません。対象システムの地域による違いも記載されていないため、国内のシステムでも、まずパッケージと版を照合するのが実務上の確認手順です。
影響する会社・しない会社
- 影響する: 対象版の部品を使い、信頼できるか確認できていないOpenAPI文書を、同じプロセス内で解析するアプリやサービスを運用する会社です。
- 影響する: 対象版を使うCLI、つまりコマンドで操作するツールで、未信頼のOpenAPI文書を解析する会社です。Webサービスだけでなく、社内の処理ツールも確認対象になります。
- 影響しない: 使用する系列に対応した修正版以降を利用している会社は、今回公表された対象版には該当しません。
- 影響しない: Microsoft製品を使っているという理由だけで、今回の対象になるわけではありません。同社が運営するサービスへの影響は主張されておらず、個別サービス名による対象一覧は発表には書かれていません。
情シスが今日やること
- 開発担当と委託先に利用状況を照会します。 初動として、脆弱性番号と上記のパッケージ名を送り、依存パッケージ一覧や依存関係の定義ファイルで、名称・系列・版を確認するよう依頼します。具体的な管理画面の指定は発表にはありません。
- 未信頼の文書を読む処理を洗い出します。 アプリ、CLI、サービスの担当者に、OpenAPI文書の入手元と、解析を同じプロセスで実行しているかを確認してもらいます。パッケージを使っているかだけでなく、文書を取り込む経路まで記録します。
- 系列に合う更新先と実施日を決めます。 対象版が見つかったら、開発担当または委託先に修正版への更新を依頼します。業務側の責任者にはプロセス終了の恐れを伝え、更新予定日を共有します。公式な適用期限は資料にはありません。
- 更新後のエラー処理と隔離を確認します。 開発担当に、上限超過時に解析結果が返らない場合の動作を確認してもらいます。Microsoftは、未信頼のOpenAPI文書の解析を、可能なら別プロセスへ隔離することも推奨しています。
対応の順番を決める際は、脆弱性管理の優先順位のつけ方も参考にしてください。
