ModSecurity WAF の脆弱性 CVE-2025-48866 が FIX：リソース消費に起因するシステム・クラッシュ

New ModSecurity WAF Vulnerability Let Attackers Crash the Syste

2024/06/03 CyberSecurityNews — ModSecurity に深刻なサービス拒否 (DoS) の脆弱性が発見された。Apache／IIS／Nginx Web サーバの保護に使用される ModSecurity は、最も広く導入されている OSS の WAF エンジンの１つである。この脆弱性 CVE-2025-48866 は、ModSecurity のバージョン 2.9.10 以下に影響し、sanitiseArg／sanitizeArg アクションを悪用する攻撃者に対して、システム・クラッシュを引き起こす機会を与えるものだ。

この脆弱性の深刻度は CVSS スコア 7.5 であり、Web アプリケーションの保護に ModSecurity を利用する組織にとって、重大なリスクをもたらされている。

ModSecurity の DoS 脆弱性

この、新たに確認された脆弱性は、ループ内での過剰なプラットフォーム・リソース消費に起因し、CWE-1050 に分類されている。

sanitiseArg／ sanitizeArg アクションを取り込んだルールを、ModSecurity が処理する際に、過剰な数の引数が追加されるという問題が生じ、最終的にはサービス拒否状態にいたるという。

監査ログ内のパスワードなどの機密データをマスクするために設計された、引数サニタイズ機能が、この脆弱性により標的化される。

この脆弱性ベクターは、ユーザー操作や認証などを必要とせずに、ネットワーク経由でリモートから悪用される可能性があるため、攻撃が容易になると懸念されている。

CVSS 3.1 ベクター文字列 “CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H” を解読すると、攻撃者は攻撃の複雑さを低く抑えながら、可用性への強い影響を実現できるようだ。

ただし、この脆弱性を悪用するには、極めて特殊な状況が前提となる。サニタイズ・アクションの引数が、ルールにより明示的に指定されている場合にだけ、この脆弱性のトリガーが可能になる。例として、以下のコンフィグ例を参照してほしい。

技術的なコアは、mod_security2 内での、引数サニタイズ処理の非効率性にある。つまり、ルールが sanitiseArg アクションを利用する場合には、システムは解析済みのすべての引数を検査し、一致する引数名ごとに、サニタイズ関数を繰り返して呼び出すことになる。

指定された条件に一致する引数が数多く存在する場合には、リソースを大量に消費するループが発生し、システム・リソースが過負荷になるだろう。

たとえば、アプリケーションが ARGS 変数を介して 500個の引数を処理し、すべてがサニタイズ条件に一致する場合に、このアクションが 500回も連続して実行される。

さらに、実行されるたびに、一致する引数名がサニタイズリストに追加されるため、累積的なリソース消費が発生し、システム・クラッシュ・レベルにまでエスカレートする可能性がある。

この動作は、以前に公開された脆弱性 CVE-2025-47947 と類似しており、ModSecurity コードベース内には、複数の同様の脆弱性が存在すると想定できる。

重要なことは、この脆弱性は mod_security2 実装のみに影響し、libmodsecurity3 には影響しないことだ。なぜなら、libmodsecurity3 では、問題のある sanitiseArg アクションがサポートされていないからだ。この違いは、セキュリティ対応戦略を計画する組織にとって、きわめて重要な部分である。

Risk FactorsDetails
Affected ProductsModSecurity (mod_security2) versions prior to 2.9.10
ImpactDenial of Service
Exploit Prerequisites1. Rules using sanitiseArg/sanitizeArg with specified arguments
2. Ability to inject excessive matching arguments
CVSS 3.1 Score7.5 (High)
緩和策

いくつかの方法で、即時性のある保護対策の実施が可能である。主な推奨策は、この脆弱性に対する公式パッチが取り込まれる、ModSecurity バージョン 2.9.10 へのアップグレードである。

以前の脆弱性の開示後の、包括的なコードレビュー最中に、ModSecurity の開発チームは、この脆弱性を発見した。つまり、積極的なセキュリティ対策への取り組みが、行われていることになる。

迅速なアップグレードが不可能な環境では、sanitiseArg／sanitizeArg アクションを取り込んだルールを用いないという回避策を実施できる。この一時的な対策により、システム・アップデートの準備をするまでの間の、攻撃ベクターを排除できる。

セキュリティ・チームにとって必要なことは、現在の ModSecurity コンフィグを監査し、脆弱なアクションを利用するルールを特定し、そのリスクを評価することである。さらに、エクスプロイトの試みを示唆する、異常なリソース消費パターンを監視するための、追加監視の実装も検討する必要があるだろう。

一見すると些細な文字列処理のバグですが、サービス停止につながるようです。また、サニタイズ関数を繰り返して呼び出す際の引数が数により、パフォーマンスが劣化するという、根本的な欠陥もあるようです。オープンソースを活用する際は、それに合わせたチェックが必要ですね。よろしければ、ModSecurity で検索も、ご参照ください。