Jackson Databindの型検証回避を修正｜更新後は型引数と配列も試験

JavaのWebサービスでJackson Databindを利用している場合、JSONから復元するクラスを検証していても、ジェネリック型の引数や配列の要素型が検証をすり抜ける脆弱性に注意が必要です。CVE-2026-110879は、外側の型を許可したことが内側の型の許可へ波及する問題です。対象版の更新と、実際の読み取り設定を使った回帰試験を優先してください。

本記事は2026年10月28日に公式勧告と修正内容を確認した脆弱性解説です。勧告は10月20日公開で、本日の新規公表という意味ではありません。以下の確認手順は本サイトの提案であり、実環境で攻撃を実行した結果や動作保証ではありません。

外側のクラスを許可しても内側まで安全とは限らない

Jacksonの多態的デシリアライズは、入力に含まれる型の情報に基づき、復元する具体的なクラスを選ぶ仕組みです。今回の問題では、クラス名を使う型IDについて、外側のクラスが検証されても、その内部に指定された型引数や配列要素型に対する検証が不十分でした。公式の修正PR #6287は、この検証の経路を修正しています。

たとえば、アプリが許した入れ物の型に、許可していない中身の型を組み合わせる場面を考えます。入れ物が承認済みであることと、その中で復元される全クラスが承認済みであることは別です。直接の型IDとして拒否されるクラスでも、入れ子になったときに同じ検査が届かなければ、検証の境界が崩れます。これは仕組みを説明する仮想例です。

開発元は、利用可能なクラスや入力経路によって、任意のクラスのインスタンス化からコード実行などにつながると説明しています。CVSS v3.1は9.8、深刻度はCriticalです。この値はCVE-2026-110879の評価であり、Jacksonを含む全アプリが無条件で侵害可能という判定ではありません。実際の悪用確認と、再現可能な攻撃条件の説明も区別します。

対象となる構成と修正版を照合する

対象はクラス名に基づく多態的な読み取りです。公式勧告は、Jackson 3.xの標準的なJsonMapperを使う注釈ベースの経路、2.xと3.xでdefault typingを設定した経路、それを公開する統合機能を挙げています。カスタムのPolymorphicTypeValidatorを書いていないから対象外、とは判断できません。版と条件はFasterXMLの公式セキュリティ勧告で照合してください。

系列と影響版	勧告記載の修正版
2.10.0〜2.18.11	2.18.12
2.19.0〜2.21.7	2.21.8
2.22.0〜2.22.3	2.22.4
3.0.0〜3.1.7	3.1.8
3.2.0〜3.2.3	3.2.4

2.xのMaven座標はcom.fasterxml.jackson.core:jackson-databind、3.xはtools.jackson.core:jackson-databindです。同じartifact名だけを見て系列を取り違えないようにします。表は今回の勧告に対応する範囲と修正版で、表より古い版の利用を推奨するものではありません。

2.xの公式リリースノートでは2.21.8と2.22.4が10月17日付で掲載されています。公開前の次版を修正版として選ばず、利用するフレームワークや依存関係管理が対応する、実際に提供済みの版へ更新します。大きな系列変更が必要かと、現在の系列で修正を取り込めるかを分けて検討してください。

宣言した依存関係ではなく実行時に選ばれる版を調べる

最初に、アプリ本体、バッチ、キューワーカーなど、同じデータを読む実行単位ごとに依存関係を確認します。自分のビルドファイルにJacksonを直接書いていなくても、フレームワークやシリアライザー経由で導入されている場合があります。更新したモジュールと、再配備するサービスを対応付けます。

mvn dependency:tree \
  -Dincludes=com.fasterxml.jackson.core:jackson-databind,tools.jackson.core:jackson-databind

この例はMaven Dependency Pluginの公式な絞り込み方法を使っています。出力から、どの依存経路で入るかと採用版を確認します。マルチモジュール構成では対象モジュールでも実施し、親の依存管理、BOM、個別指定のどこで版が決まるかを記録してください。

./gradlew dependencyInsight \
  --dependency jackson-databind \
  --configuration runtimeClasspath

GradleのdependencyInsight公式資料は、選択された版と選択理由を確認する方法を説明しています。上の例はJava系プロジェクトのruntimeClasspathを想定したものです。構成名が違うプロジェクトでは実際の実行用構成を指定し、開発用・テスト用の結果だけで本番も更新済みと判定しないでください。

依存関係の解決結果に加え、配布用JAR、コンテナイメージ、実際に起動する成果物を結び付けます。再ビルドしても旧イメージを配備していたり、一部のワーカーが古いままだったりすれば、入口は残ります。ビルド番号、イメージの識別子、配備先を更新記録へ添える方法が有効です。

Mapperの生成箇所から読み取りの入口を追う

コードレビューでは、ObjectMapperやJsonMapperの生成と注入、default typingの有効化、JsonTypeInfoでId.CLASSやId.MINIMAL_CLASSを使う箇所を探します。文字列検索は候補発見に使い、検索結果がないだけで安全と断定しません。設定を別モジュールや自動構成が与える場合があるためです。

各Mapperについて、HTTP本文、メッセージ、キャッシュ、セッションのどこを読むかを対応付けます。特にキャッシュは、読むサービスと書くサービスが違うことがあります。攻撃者がその値や型情報を変更できる経路があるか、どの資格情報で書けるかを確認し、内部の保存先という名称だけで信頼しないようにします。

一方、型が固定された単純なJSONの読み取りだけを行い、クラス名から復元先を選ぶ経路がない場合は、今回の条件との距離があります。ただし、公開APIのMapperだけを調べて、共通ライブラリー内の読み戻しまで確認したことにはできません。調査対象と未確認の処理を一覧へ残します。

更新後の試験はジェネリック型と多次元配列を含める

修正は外側の型だけで検証を終えないようにするものです。さらに配列型を扱う追加修正PR #6289は、同じ深さの配列を広く許す規則に関係する要素型の検証を扱っています。単一のクラス名を拒否する試験だけでは、この修正点を確認したことになりません。

本サイトの提案は、業務用の許可クラスと、副作用のない試験専用の拒否クラスを用意し、本番と同じMapper設定で試す方法です。外部通信、ファイル操作、プロセス起動を行うクラスは使わず、型が受理されたかと復元処理へ到達したかを観測できる小さな試験にします。

試験ケースは、許可した通常の型、拒否すべき直接の型、許可した外側の型と拒否すべき型引数の組み合わせ、拒否すべき要素型を持つ配列、同じ条件の多次元配列を分けます。正常なケースだけ成功し、禁止した内側の型は復元前に拒否されることを合格条件にしてください。

試験結果には、使用したJacksonの版、Mapperの作成方法、validatorの規則、入力形式、期待した結果を残します。例外が出たという一行だけでは、期待した検証が働いたのか、別の解析エラーなのか判別しにくくなります。アプリが返すHTTPエラーだけでなく、型の拒否理由も確認できるようにします。

既存データが読めなくなったときの切り分け

更新後にキャッシュや保存済みJSONの読み取りが失敗した場合、すぐにvalidatorを全許可へ戻さないでください。まず、拒否されたのが外側の型、型引数、配列要素型のどれかを整理し、業務上必要な型かを判断します。修正で従来の過剰な許可が閉じた可能性もあります。

通常の型まで失敗するなら、依存版の不整合、想定と異なるMapper、保存時と読取時の型の違いを順に比較します。設定変更が必要な場合は、業務で必要な具体的なクラスと入力元を根拠に許可範囲を決めます。広いパッケージや全配列の許可を足してエラーを消す方法では、今回点検した境界が再び曖昧になります。

過去のキャッシュを作り直せるなら、対象を限定して再生成する案を検討します。再生成できない業務データは、バックアップと件数照合を伴う移行として扱います。失敗した値を調査用の別ツールで無制限に復元する例外も避け、運用者が同じ危険な読み取りを再開しない手順を用意してください。

更新待ちの防御と公開後の確認を決める

すぐ更新できない場合は、信頼できない入力でクラス名ベースの多態的読み取りを停止できるかを優先して検討します。必要な復元先を限定し、キャッシュやセッションの書き込み権限も縮めます。不要な依存関係の削減や実行権限の制限は被害抑制に役立ちますが、対象版の修正を不要にする保証ではありません。

運用では、型IDの拒否や読み取りエラーの増加を、配備時刻と入口ごとに確認します。生のJSONを一律にログへ残すと個人情報や秘密が含まれるため、経路、発生件数、相関ID、必要な拒否理由を中心に記録します。エラーがないことだけで過去の悪用がなかったとは判定できません。

完了条件は、修正版が本番の全実行単位へ届き、実際の設定を使った正常・拒否双方の試験が通り、旧版の処理や調査用の迂回経路が残っていないことです。今回の対応では、バージョンの確認と、外側から内側まで型の検証が届くことの確認を、一つの変更としてレビューしてください。

関連記事

デシリアライズの入口を減らす｜外部データをオブジェクトへ戻す前の点検では、保存形式や信頼境界を見直す一般的な移行手順を扱っています。