Webアプリケーションファイアウォール（WAF）としてModSecurity（libmodsecurity）を使っている人は、まず次を確かめてください。
- 動いているライブラリが3.0.17未満（v3系）なら、3.0.17以降へ更新する。Apache向けのv2系なら2.9.15以降（multipartの件）
- CVE-2026-73857向けに、
SecParseXmlIntoArgsがOnやOnlyArgsになっていないかを見る（既定はOff） - ディストリビューションのパッケージがまだ直っていない場合は、公式アドバイザリーの回避策を取りつつ、修正パッケージの公開を追う
OWASP ModSecurityには、ファイル名検査をすり抜けるおそれのある脆弱性CVE-2026-104269と、XML処理まわりの脆弱性CVE-2026-73857があります。どちらもlibmodsecurity 3.0.17（2026年9月29日公開）で直っています。v2系のmultipartの件は 2.9.15 でも直っています。GitHubのアドバイザリーには、multipartの件について検証用の例も載っています。攻撃の手順は書きません。
11月10日8時0分〜8時28分（日本時間）時点の、GitHub Security Advisory、OWASP ModSecurityのブログ／リリース、Debian・Ubuntu・Red HatのCVE案内にもとづく内容です。
結論：3.0.17（v2系は2.9.15）へ更新する
| 項目 | CVE-2026-104269 | CVE-2026-73857 |
|---|---|---|
| 内容（要約） | multipartの filename*（RFC 2231）をWAFが見落とし、バックエンドだけが本物のファイル名を使う |
XMLリクエスト処理で未初期化ポインタを参照しうる（サービスが止まるおそれから、最悪の場合は実行の流れを乗っ取られるおそれまで） |
| 深刻度（GitHub） | High（CVSS 8.6） | High（CVSS 7.5） |
| 対象（公式） | v3は 3.0.16 以下、v2は 2.9.14 以下 | 3.0.15〜3.0.16（この経路は3.0.15で入った。それより前のv3やv2系は対象外） |
| 修正 | 3.0.17／2.9.15 | 3.0.17 |
| すぐできる回避 | 同等の設定回避はなし（公式）。更新が本筋 | SecParseXmlIntoArgs を Off のままにする（既定も Off） |
サーバーを管理するパソコンのウイルス対策も見直すなら、セキュリティソフトの比較で、更新料と使える台数を確かめられます。
CVE-2026-104269：アップロードファイル名の食い違い
公式アドバイザリー（GHSA-5pww-8rfg-9crf）によると、multipartの Content-Disposition には、ふつうの filename と、RFC 2231の filename*（文字コード付き）の両方を付けられます。Go・Python・Node.js・Javaなどの一般的なパーサは filename* を優先します。一方、直る前のModSecurityのmultipartパーサは filename しか見ていませんでした。
その結果、OWASP CRSなどファイル名を見るルール（例：920120、922100、922110）は無害な名前だけを見て通り、アプリ側は別の名前で保存や拡張子判定をする、という食い違いが起きうると説明されています。PHPの標準のmultipartは filename のみで、この食い違いの対象外、とも書かれています。
直ったバージョンでは filename* を扱うようになり、関連する変数も増えています。アップグレード前に、公式ブログが挙げる挙動の変化（MULTIPART_FILENAME の中身や、ルールのマッチ回数など）を確認してください。
CVE-2026-73857：XML処理と SecParseXmlIntoArgs
公式アドバイザリー（GHSA-jx3r-phvx-2jmj）とOWASPの解説によると、認証なしのリモートから細工したHTTPリクエスト1本で、ModSecurityを動かしているワーカーが未初期化ポインタを参照しうる問題です。影響はサービス停止から、メモリの露出や実行の流れのずれ（リモートコード実行につながりうる、という説明）まで幅があります。
届く条件は、SecParseXmlIntoArgs が On または OnlyArgs のときだけです。既定は Off です。対象はlibmodsecurity3の 3.0.15 と 3.0.16 で、それより前のv3やModSecurity v2系はこの欠陥の対象外、とあります（v2には防御のための同様のガードも入った、とも書かれています）。
いまのバージョンの確かめ方
Debian／Ubuntu系でパッケージ利用なら、次で入っているバージョンを見ます。
dpkg -l 'libmodsecurity*' 'modsecurity*'または次でも確かめられます。
apt-cache policy libmodsecurity3 libmodsecurity3t64表示されたバージョンが 3.0.17 未満なら、multipartの件（104269）の修正には足りません。CVE-2026-73857 だけを見るなら、公式どおり 3.0.15 と 3.0.16 が対象です。
SecParseXmlIntoArgs の設定は、設定ファイルを検索して確認します（パスは環境により異なります）。
grep -R SecParseXmlIntoArgs /etc/nginx /etc/apache2 /etc/httpd /etc/modsecurity 2>/dev/null何も出ない、または Off なら、公式どおりこの欠陥には当たりません（届くのは On または OnlyArgs のときだけ）。ソースから入れている場合は、使っているタグ／コミットが v3.0.17 以降かをリポジトリ側で確かめてください。
更新する
上流の修正は、GitHubのリリースタグ v3.0.17（libmodsecurity3）と v2.9.15（mod_security2）です。パッケージ経由なら、ディストリビューションのセキュリティ更新を入れてください。自前ビルドなら、公式リポジトリの該当タグへ更新して入れ直します。
git fetch --tags
git checkout v3.0.17（v2系のApacheモジュールなら v2.9.15。ビルドと入れ直しは、いま使っているコネクタ／Webサーバーの公式手順に従ってください。）
nginxやApacheのコネクタ、CRSのバージョンも環境によって別管理です。ライブラリだけ上げたあと、Webサーバーの再読み込みや再起動が必要かは、自分の入れ方の手順で確認してください。
すぐ更新できないあいだ
- CVE-2026-73857：
SecParseXmlIntoArgsをOn／OnlyArgsにしない（公式の回避策）。既定のOffを維持する - CVE-2026-104269：公式は同等の設定回避はない、とし、更新をすすめています。
filename*を含むリクエストをすべて落とすとバイパスは止められますが、正当なアップロードも拒む、とも書かれています - アプリ側でも、保存名や拡張子の判定をWAFだけに頼らない（アドバイザリーの影響説明の範囲）
主なディストリビューションの状況（取得時点）
上流は直っていても、OSパッケージが追いついていないことがあります。次は2026年11月10日8時台（日本時間）に確かめた案内です。
- Debian（security-tracker）：CVE-2026-104269／CVE-2026-73857とも、modsecurity（および104269ではmodsecurity-apache）は unstable でも未修正（unfixed）。bookworm／trixie／sid などに入っているバージョン例は 3.0.9〜3.0.16 台。Debianの追跡ページでは「vulnerable（影響あり）」と出ますが、73857 の公式対象は 3.0.15〜3.0.16 だけなので、自分のパッケージのバージョンと照合してください
- Ubuntu：両CVEとも modsecurity（104269は modsecurity-apache も）が Needs evaluation
- Red Hat：CVE-2026-104269 は Important 相当の説明あり（調査・修正方針はページのステータスを見る）。CVE-2026-73857 は、確かめた時点ではRed Hatの案内ページがありませんでした
パッケージが出たら、いつものセキュリティ更新で入れてください。
sudo apt update
sudo apt upgrade（RHEL系なら sudo dnf update など、そのOSの手順。）
よくある質問
PoCは公開されていますか？
CVE-2026-104269 のGitHubアドバイザリーには、検証用の例が含まれています。ここでは再現手順は書きません。自分の環境が対象かと、更新・回避が先です。
CRSだけ更新すれば足りますか？
multipartの件の本体は、ModSecurity側のファイル名の取り方です。公式はライブラリを直ったバージョンへ更新するよう案内しています。CRSのルール番号は影響の説明に出てきますが、エンジン側の修正が本筋です。
SecParseXmlIntoArgs を使っていなければ73857は無視してよいですか？
既定の Off なら、公式どおりこの欠陥には当たりません。それでも 104269 など他の修正も含む 3.0.17 への更新は進めた方がよいです。
コメント