GitHub Advisory Databaseに、sanitize-htmlの脆弱性「CVE-2026-113650」が掲載されています。対象の版では、標準設定でも細工したHTML入力によって処理を続けられなくなる例外が発生するため、利用中の版と設定の確認が必要です。
標準設定でも再帰処理が重なり、例外が発生
掲載情報によると、影響対象はsanitize-html 2.18.0と、同情報の執筆時点のmainブランチです。mainブランチは開発中のコードを指します。資料では公開日を確認できません。
原因は、許可しないiframeの内容を、自分自身を呼び出す「再帰処理」で扱う実装にあります。許可しないタグの処理方法を指定するdisallowedTagsModeがdiscardの場合に問題が生じます。iframeを許可せず、discardで処理する組み合わせは標準設定に該当します。独自の設定変更をしていないことだけでは、対象外と判断できません。
この再帰処理には回数の上限がなく、呼び出すたびに状態が初期化されます。その結果、小さなHTML入力でも、処理中の呼び出し情報を保持する領域を使い切る「スタック超過」の例外を誘発できます。
再現試験では、閉じていないiframeタグ2,000個、16,000文字の入力により、標準設定でRangeErrorが発生しました。試験環境はNode.js v26.7.0です。呼び出し元ですでに処理が深く重なっている場合は、さらに小さな入力でも例外が生じるとされています。このため、16,000文字未満なら安全という判断はできません。
入れ子の上限だけでは防げず、関連リリースの確認も必要
HTMLの入れ子の深さを制限するnestingLimitにも注意が必要です。破棄対象のiframeを挟むと、この制限を回避できるとされています。掲載情報では、nestingLimitを3にしても、bタグが150段になる例が確認されています。上限を設定済みという理由だけで、対応済みにはできません。
一方、2.17.7と2.17.4では、同じ入力による影響がないことが確認されています。ただし、これは特定の入力での確認結果です。両版の安全性全般や、版を戻す運用まで保証する内容ではありません。
資料本文では修正済みの版は明示されていませんが、参考リンクにはsanitize-html@2.18.1のリリースが挙げられています。修正内容や適用可否はリンク先で確認してください。この参照だけで、2.18.1が本脆弱性の修正版だとは断定できません。
また、本文では再帰回数の制限と、処理の深さを次の呼び出しへ引き継ぐことが対策の方向性として示されています。ただし、この説明はパッチではないと明記されています。
日本での提供は発表には書かれていません。国内での利用有無は、自社システムや委託先の構成を確認してください。
影響する会社・しない会社
- 影響する: sanitize-html 2.18.0、または掲載情報の執筆時点のmainブランチを使い、iframeを許可せず、disallowedTagsModeをdiscardにしている会社です。標準設定もこの条件に含まれます。
- 影響する: 上記の条件で、nestingLimitによる入れ子の制限を対策としている会社です。その制限を回避する例も確認されています。
- 影響しない: 2.17.7または2.17.4では、掲載情報と同じ入力による影響はないことが確認されています。ただし、ほかの入力や版、設定での影響範囲は資料に書かれていません。
