ModSecurityは、攻撃者がリクエスト検査ルールを回避したり、ファイルアップロード保護をすり抜けたり、サービス拒否（DoS）状態を引き起こしたりできる複数の脆弱性を公表しました。脆弱な環境では、コード実行に至る可能性もあります。
9月30日に公開されたセキュリティアドバイザリには、マルチパートリクエストの解析と、ModSecurity v3のXMLリクエストボディ処理に影響する重要度の高い問題が含まれています。
ModSecurityをOWASP Core Rule Setと併用している組織は、設定を早急に見直し、利用可能なパッケージを更新する必要があります。パッチが未提供の場合は、補完的な対策も講じるべきです。
WAF回避につながる最も深刻な問題はGHSA-5pww-8rfg-9crfとして追跡されており、ModSecurityのマルチパートパーサーがRFC 2231のパラメータ拡張に対応していないことが原因です。
この脆弱性はModSecurity 3.0.0以降のバージョンに影響します。公表時点では、修正済みバージョンはアドバイザリに記載されていません。CVSSスコアは8.6です。
問題の中心は、マルチパートのContent-Dispositionヘッダーで使われるfilename*パラメータです。ModSecurityと関連するOWASP Core Rule Setのルールは通常のfilename=の値を検査します。一方、RFCに準拠したアプリケーションフレームワークは、RFC 2231でエンコードされたfilename*=の値を優先する場合があります。
攻撃者はこの差を悪用し、WAFには無害に見えるファイル名を見せながら、バックエンドのアプリケーションには危険な拡張子のファイルを処理させるアップロードリクエストを送信できます。
たとえば、ModSecurityにはsafe.jpgと見えていても、Go、Python、Node.js、Javaのバックエンドではshell.phpというファイル名として解釈されることがあります。この食い違いにより、CRSのルール920120、922100、922110などのファイル拡張子ルールを回避できる可能性があります。
アプリケーションがアップロードされたファイルをWebからアクセス可能なディレクトリに保存し、サーバーサイドスクリプトの実行を許可している場合、この回避はリモートコード実行につながるおそれがあります。
PHPのネイティブなマルチパート処理はfilename*を同じ方法ではデコードしません。しかし、アドバイザリでは、Go、Flask/Werkzeug、FastAPI/Starlette、Node.js、Java環境で一般的なパーサーが影響を受けるとされています。
これとは別に、重要度の高い脆弱性CVE-2026-73857が、3.0.17より前のlibmodsecurity3のXMLリクエストボディ処理に影響します。原因は、XMLをARGSに展開するSAXの終了要素コールバックにおける、未初期化ポインターの参照です。
認証不要のリモートの攻撃者が、細工したHTTPリクエストを1件送るだけでこの問題を悪用できます。その結果、ModSecurityで保護されたWebサーバーのワーカーが、攻撃者の指定したアドレスに定数値を書き込む可能性があります。
アドバイザリは、これを制限付きの「write-what-where」プリミティブと説明しています。影響はサービス拒否やメモリ内容の漏えいにとどまらず、実行フローの乗っ取り、さらにはリモートコード実行にまで及ぶ可能性があります。
脆弱なコードパスに到達できるのは、SecParseXmlIntoArgsがOnまたはOnlyArgsに設定されている場合に限られます。この設定はデフォルトでは無効です。影響を受けるのはModSecurity v3.0.15とv3.0.16で、修正版はバージョン3.0.17です。
今回公開されたアドバイザリは、不正なBase64の処理、隣接するコメントの除去失敗、PCRE2正規表現のマッチ制限エラー、レスポンスボディ検査の回避にも及んでいます。
これらの脆弱性は、単独でもModSecurityの変換処理やマッチングロジックに不完全または誤った検査結果をもたらします。その結果、攻撃を検知するはずのルールを、悪意のあるペイロードがすり抜けてしまいます。
こうした不具合が重大なのは、WAFによる保護がファイアウォールとバックエンドのアプリケーションが同じリクエストを同じように解釈することを前提としているためです。パーサーの解釈の食い違い、変換処理の誤り、検査失敗時に通過させる（フェイルオープン）マッチング動作は、いずれも回避の余地を生みます。
管理者は、可能な環境ではlibmodsecurity3を3.0.17にアップグレードし、ModSecurityのルールセットを最新に保つ必要があります。XMLの脆弱性については、運用上の必要性が文書化されていない限り、SecParseXmlIntoArgsをOffのままにしておくべきです。
アプリケーション側でも、対策が求められます。具体的には、ファイル名を独自に正規化する、実行可能な拡張子を拒否する、許可リストに登録した形式でファイル内容を検証する、ファイル名をサーバー側で生成する、アップロードファイルをWebからアクセスできないパスに保存する、といった対応です。
これらの対策により、RFC 2231に起因するファイル名の食い違いが、Webシェルの設置やコード実行に直結するリスクを低減できます。
16,000以上のSOCチームがANY.RUNを導入し、脅威調査を効率化して手作業を削減しています。チーム向けの詳細を見る
翻訳元: https://cyberpress.org/modsecurity-flaws/
