Apache Traffic Server、物差しを替えると順位が逆転 CVE-2026-58155

2026年7月29日、Apache Traffic Serverの脆弱性が一括で公表されました。修正版は前日7月28日に公開された9.2.15と10.1.4の2つです。公表分のうち、危険度が最も高い層にはCVSS 3.1で満点の10.0が3件並んでいます。

ところが、その同じ3件を新しい評価方式であるCVSS 4.0で見ると、7.7 / 7.0 / 7.8です。3ポイント以上の開きがあります。しかもどちらの数字も、採番元であるApache自身が付けた公式値です。片方だけを拾えば過大にも過小にも見える——この食い違いの正体と、バージョンの選び方でつまずきやすい点を順に見ていきます。

【追記 2026年7月29日】同じバッチから5件が加わり、順位が入れ替わりました

本稿の公開後、同じ38件バッチのうち5件（CVE-2026-58155 / CVE-2026-58154 / CVE-2026-58153 / CVE-2026-58151 / CVE-2026-65324）がNVDに登録されました。修正版は先の6件と同じ9.2.15と10.1.4です。そして先に書いておくべきことがあります。CVSS 4.0という物差しで見ると、この5件のうち2件が、本稿で「最重要」として軸に据えた3件より重いのです。

数字を並べると明快です。CVE-2026-58155とCVE-2026-58154はCVSS 4.0で9.2——4.0の区分ではCritical（緊急）に入ります。一方、本稿が軸にした3件は、CVSS 3.1では満点の10.0でも、4.0ではCVE-2026-58150が7.8、CVE-2026-33267が7.7、CVE-2026-57834が7.0で、いずれもHigh（重要）どまりです。11件を4.0で並べたときCriticalに入るのは、後から出てきたこの2件だけになります。

本稿が6件を選んだ基準はCVSS 3.1の高い順でした。その基準では、3.1で9.3のCVE-2026-58155も、8.9のCVE-2026-58154も軸から外れます。本稿は「数字で優先順位を決めると順序が入れ替わる」と書きましたが、その実例が、公開直後に本稿自身の選び方へ返ってきた形です。スコア1つで並べ替えた選択は、物差しを替えると崩れる——当サイトの記事がその見本になりました。逆向きの入れ替わりも起きています。CVE-2026-58153は3.1で8.3ある一方、4.0では6.3まで下がります。

11件を、2つの物差しで並べ直す

先の6件と追記分の5件を合わせた11件を、CVSS 3.1の高い順に並べ、右端に4.0での順位の動きを添えます。同順位は上位の順位を共有させています。

11件のうち順位が動かないものは1つもありません。最大の動きはCVE-2026-58154の6位から1位、次いでCVE-2026-58151の9位から3位、そして下がる側ではCVE-2026-58153の7位から11位です。3.1で満点だった3件は、4.0では5位・6位・7位に落ちます。

なぜこう動くのかは、ベクトルの中身を見ると説明が付きます。CVE-2026-58155の4.0ベクトルは AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N で、AT:N——成立に必要な前提条件がないと評価されています。本稿で扱ったCVE-2026-57834のAT:P（前提条件あり）と、ここが正反対です。加えて、完全性への影響がTraffic Server自身（VI:H）と後段（SI:H）の両方で「高」です。CVE-2026-58154のほうは AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N——メモリ破壊なのでTraffic Server自身の機密性・完全性・可用性が3つとも「高」に振れます。3.1側で8.9にとどまったのは AC:H（攻撃条件が複雑）が乗っているためで、4.0はその複雑さをAT:Pという別項目に移したぶん、基本値が下がりにくくなっています。

可用性だけの2件（CVE-2026-58151とCVE-2026-65324）が4.0で上がるのも、同じ設計の裏返しです。3.1はA:H単独だと7.5で頭打ちになりますが、4.0はVA:H単独でも8点台に届きます。「4.0は3.1より低く出る」は一般則ではありません。スマグリング系のように後段まで連鎖する欠陥では下がり、サーバー自身が壊れる欠陥では上がる——向きは種類によって逆になります。

HTTP/2を有効にしているかどうかで、当たり判定が変わる

追記分5件のうち3件（CVE-2026-58153・CVE-2026-58151・CVE-2026-65324）は、HTTP/2の処理経路そのものが舞台です。CVE-2026-65324はHTTP/3も対象に含みます。残る2件のCVE-2026-58155とCVE-2026-58154はヘッダの扱いに関する欠陥で、HTTP/1.1でもHTTP/2でも通る道です。先の6件と合わせると、11件のうちHTTP/2が絡むのは4件になります。

Traffic ServerでHTTP/2を受けているかは、records.configの proxy.config.http.server_ports の proto 指定で決まります。ポート単位の設定で、TLSポートの既定値は「利用可能なすべてのプロトコル」——つまりHTTPSを受けている時点で、明示的に絞っていなければHTTP/2は有効です。HTTP/3はQUICポートを別に開いている場合に限られます。自組織の設定を確認する起点はここです。

誤解のないよう補足します。Apacheはこの5件について、HTTP/2の無効化を回避策として案内していません。公式アナウンスの各エントリに書かれている対処は、9.2.15または10.1.4への更新の一択です。上の表は「更新までの間、どこから優先的に見るか」を決めるための地図であって、HTTP/2を切れば済むという話ではありません。プロトコルを切れば当然、性能面の代償も付いてきます。

CVE-2026-58155: 長すぎるヘッダ名を切り詰めて別物にしてしまう

HTTPヘッダの名前が想定した長さを超えたとき、Traffic Serverはリクエストを拒否せず名前を途中で切り詰めていました。切り詰めれば、本来は別物だったヘッダが同じ名前に化けます。これがエイリアシングで、前段と後段が「どのヘッダの値を採用するか」で食い違う土台になります。Apacheの説明は「header aliasing、リクエストスマグリング、ポリシー回避を許す」で、分類はCWE-444。CVSS 3.1は9.3、4.0は9.2、Apacheのラベルはimportantです。対象はNVDの記載で8.0.0〜8.1.9 / 9.0.0〜9.2.14 / 10.0.0〜10.1.3、修正版は9.2.15と10.1.4。11件のうち4.0で最も高い値が付いた1件であり、報告者はOmkhar Arasaratnam氏です。

CVE-2026-58154: ヘッダ解析中の境界外書き込みと整数オーバーフロー

MIMEおよびHTTPヘッダを解析する処理で、確保した領域の外へ書き込む、あるいは整数の計算があふれるという欠陥です。分類はCWE-787（境界外書き込み）。他の10件がプロトコル解釈のズレやポリシー回避なのに対し、これだけはメモリ破壊の系統で、成立すればプロセスのクラッシュや、条件次第でそれ以上に至ります。CVSS 3.1は8.9、4.0は9.2、ラベルはimportant。対象は8.0.0〜8.1.9 / 9.0.0〜9.2.14 / 10.0.0〜10.1.3で、修正版は9.2.15と10.1.4です。報告者はMichael Bommarito氏、Omkhar Arasaratnam氏ほか。

CVE-2026-58153: HTTP/2のトレーラーをチャンク形式に整えず転送する

トレーラーとは、本文の後ろに付けるヘッダのことです。HTTP/1でこれを送るにはチャンク転送の枠組みに載せる必要があるのですが、HTTP/2で受けたオリジンからのトレーラーを、その形に整えないままHTTP/1のクライアントへ流していました。受け手はそれを本文の続きとして読むため、応答の区切りの解釈が狂います。分類はCWE-444、ラベルはmoderate。CVSS 3.1は8.3、4.0は6.3で、11件の中で順位が最も下がる1件です。対象は10.0.0〜10.1.3だけで9系や8系は含まれず、修正版は10.1.4です。CVE記録の推奨欄には他の37件と同じ「9.2.15または10.1.4へ」という定型文が入っていますが、公式アナウンスのこのエントリには「10.x users should upgrade to 10.1.4 or later versions」の一行しかありません。9系にこの欠陥はないと読むのが筋です。

CVE-2026-58151: HTTP/2のフレーミングとフロー制御を悪用される

HTTP/2は1本の接続に多数のやり取りを相乗りさせる仕組みで、その割り振りをフレーム分割とフロー制御で管理します。ここに乱暴な組み合わせを送り込まれると、Traffic Serverがクラッシュするか、資源を食い尽くして応答しなくなります。分類はCWE-400（資源枯渇の制御不全）。CVSS 3.1は7.5、4.0は8.7で、3.1では11件中9位、4.0では3位という最も分かりやすい入れ替わりです。ラベルはimportant、対象は8.0.0〜8.1.9 / 9.0.0〜9.2.14 / 10.0.0〜10.1.3、修正版は9.2.15と10.1.4。手前に立つ機械が止まれば背後の全サイトが止まるという位置関係を考えると、4.0側の評価のほうが実感に近いという見方もできます。

CVE-2026-65324: デチャンク時にストリームごとのバッファ上限が外れる

HTTP/2やHTTP/3の応答を扱う際、チャンク形式を解いて整える処理（デチャンク）で、ストリーム1本あたりのバッファ上限が効かなくなっていました。上限が外れると、受け取りの遅いクライアントがぶら下がった分だけサーバー側にデータが溜まり続けます。攻撃側は帯域も権限も要らず、ゆっくり受け取るだけでメモリを枯渇させられます。分類はCWE-400、CVSS 3.1は7.5、4.0は8.2、ラベルはimportant。対象は8.0.0〜8.1.9 / 9.0.0〜9.2.14 / 10.0.0〜10.1.3で、修正版は9.2.15と10.1.4です。

自分の環境で、どう優先順位を付けるか

スコアの高い順に並べる作業は、物差しを替えれば結果が変わります。自分の構成という物差しを先に当てたほうが、答えは動きません。上から順に当てはめてください。

• ▸8系を使い続けているなら、優先順位付けの問題ですらありません。追記分のうち4件（58155・58154・58151・65324）はCVE記録上8.0.0〜8.1.9も対象に含み、8系向けの修正版はありません。どちらのスコアで並べても答えは移行です。
• ▸HTTPSを受けている（＝HTTP/2が既定で有効）なら、58151と65324が加わります。この2つは可用性への影響で、3.1では7.5と目立ちませんが4.0では8.7と8.2です。スキャナの並び順では下のほうに沈む位置にあります。
• ▸10系を使っているなら、58153が上乗せされます。9系にはない1件です。逆に9系なら、追記分は4件になります。
• ▸プロトコルの構成にかかわらず、58155と58154は全員に当たります。4.0でCriticalに入る2件がこれです。ヘッダ処理はHTTP/1.1でもHTTP/2でも通る道だからです。
• ▸後段に別のサーバーがいる構成なら、スマグリング系（57834・58150・24033・58155・58153）の成立条件は後段の実装との組み合わせで決まります。前段だけを見て判断できません。

どの道を通っても、着地点は9.2.15または10.1.4への更新で同じです。優先順位を付ける意味があるのは、更新までに時間がかかる場合に、その間どこを見張るかを決めるときだけです。なお本稿が触れたのは38件のうち11件で、残る27件は扱っていません。公式アナウンスには38件すべてが対象範囲つきで並んでいます。

Apache Traffic Serverはどこで動いているのか

Apache Traffic Serverは、Webサイトの前に立って通信を中継し、よく使われるデータを手元に貯めておくリバースプロキシ兼キャッシュサーバーです。利用者のブラウザとWebサイト本体の間に挟まり、同じ画像やページのリクエストが来たら本体に問い合わせずに自分の控えを返します。これを世界中に配置したものがCDN（コンテンツ配信網）で、Traffic Serverはその土台部品として使われています。

出自ははっきりしています。もとはInktomi社の商用製品で、同社を2003年に買収したYahoo!が社内で使い続け、2009年8月にソースコードをApacheソフトウェア財団へ寄贈しました。翌2010年にApacheのトップレベルプロジェクトへ昇格しています（経緯の概説はWikipediaにもまとまっています）。

誰が使っているかは、プロジェクトが公式の利用者一覧を公開しています。そこに名前が挙がっているのは、Comcast、Yahoo!、LinkedIn、Go Daddy、Akamai、そしてYahoo! Japanです。公式サイト自身も「世界の主要なCDNとコンテンツ事業者を支えている」と説明しています。つまり、脆弱性が刺さる位置は個々のWebサイトではなく、その手前にある通り道です。1台の背後に数百・数千のサイトがぶら下がっていることも珍しくありません。

日本との接点も薄くありません。今回のアドバイザリで報告者としてクレジットされている中には、LY Corporation（LINEヤフー）所属のKatsutoshi Ikenoya氏、Haruki Oyama氏、Rajat Raghav氏の名前があります。日本の事業者側の技術者が見つけて報告した欠陥が、そのまま世界中の配信基盤の修正になった格好です。

公表されたのは6件ではなく38件

最初に規模を正確に押さえておきます。Apache Traffic Server PMCのMasakazu Kitajo氏が投じた公式アナウンス（[SECURITY] Multiple vulnerabilities fixed in Apache Traffic Server 9.2.15 and 10.1.4）は、冒頭で「38件の脆弱性が9.2.15と10.1.4で修正された」と述べ、CVE番号を38個列挙しています。HTTP/2の資源枯渇、HPACKデコードの整数処理、ESIプラグインのSSRF、Criptsフレームワークのパストラバーサル——本体からプラグイン群まで、広い範囲に及ぶ棚卸しです。

その中から、CVSS 3.1が10.0に振り切った3件を含む6件を軸に見ていきます。スキャナのアラートやニュース見出しに最初に出てくるのは、この層だからです。

表の右2列を続けて眺めると、順位そのものが入れ替わっているのが分かります。CVSS 3.1で満点のCVE-2026-57834に、Apacheはmoderate（中）のラベルを付けています。逆にCVSS 3.1では8.2どまりのCVE-2026-22068にはimportant（重要）です。数字とラベルは、そもそも別のことを測っています。

CVE-2026-33267: 中継用ヘッダを剥がさず素通しする

HTTPには「この区間だけで有効で、次の中継先へは渡してはいけない」というヘッダ（hop-by-hopヘッダ）があります。プロキシの基本作法は、外から来たそれを境界で必ず剥がすことです。アナウンスの記述は「信頼できない相手から来たhop-by-hopヘッダと内部用ヘッダが剥がされない」というもので、分類はCWE-20（不適切な入力検証）です。内部でしか使わないはずのヘッダを外部から注入できると、後段のサーバーがそれを「Traffic Serverが付けた印」と誤読する余地が生まれます。NVDの登録ではCVSS 3.1が10.0、4.0が7.7、Apacheのラベルはimportantです。

CVE-2026-58150: HTTP/2のTransfer-Encodingを拒否しない

HTTP/2の仕様では、本文の長さを伝えるTransfer-Encodingヘッダは使いません。にもかかわらずTraffic Serverはこれを拒否せず、後段へHTTP/1.1に落として転送する際にそのまま持ち込んでいました。結果としてダウングレード型のリクエスト・スマグリングが成立します。分類はCWE-444（HTTPリクエストの解釈の不一致）。CVSS 3.1は10.0、4.0は7.8で、6件中4.0のスコアが最も高いのはこれです。

CVE-2026-57834: 不正なチャンク本文でスマグリングが成立する

HTTPで本文の長さがあらかじめ決まらないとき、データを小分けにして「次は何バイト」と宣言しながら送るチャンク転送という方式が使われます。この宣言が仕様どおりでない壊れた形で届いたときの扱いが甘く、リクエストの切れ目の解釈を狂わせられる、というのが本件です。CVSS 3.1で10.0という満点が付きながら、Apache自身のラベルはmoderateです。報告者はHaruki Oyama氏とKatsutoshi Ikenoya氏（LY Corporation）ほか。

CVE-2026-41920: SNIとHostの比較が片側の長さしか見ていない

TLS接続の開始時に「どのドメインに繋ぎたいか」を告げるSNIと、HTTPリクエスト内のHostヘッダ。この2つが一致しているかを照合する処理で、片方の長さだけを基準に比べていたため、前方が一致していれば通ってしまう状態でした。Apacheの表現は「host-SNIポリシーのバイパスを許す」。分類はCWE-284（不適切なアクセス制御）で、CVSS 3.1は9.3、4.0は7.0、ラベルはmoderateです。この1件だけ公表されたバージョン情報に食い違いがあり、後段で詳しく扱います。

CVE-2026-22068: アンカーのない正規表現でACLを抜けられる

アクセス制御リスト（ACL）や振り分けルールの照合に使っていた正規表現に、文字列の先頭と末尾を固定するアンカーが付いていませんでした。分類はCWE-777（アンカーのない正規表現）。CVSS 3.1は8.2、4.0は6.9と6件中では控えめですが、Apacheのラベルはimportantです。設定で守っているつもりの境界がすり抜けられる以上、実務上の効き目は数字より大きいという判断でしょう。この欠陥の性質は後段で改めて掘ります。

CVE-2026-24033: チャンク拡張の引用文字列の解析

チャンク転送には、各チャンクに補足情報を付けられる「チャンク拡張」という仕組みがあり、そこに引用符でくくった値を書けます。その引用文字列の読み取り方が甘く、ここでもリクエストの区切りの解釈を狂わせられます。分類はCWE-444、CVSS 3.1は7.2、4.0は6.9、ラベルはmoderate。報告者はRajat Raghav氏とKatsutoshi Ikenoya氏（LY Corporation）です。

リクエスト・スマグリングとは何か

6件のうち3件（57834・58150・24033）が同じ種類です。仕組みはこう考えると分かりやすくなります。Webの通信は、前段のプロキシと後段の本体サーバーという2台以上のリレーで運ばれます。リクエストは「ここからここまでが1件」という区切りをヘッダで宣言して流れるのですが、その区切りの読み方が前段と後段でズレることがあります。前段が「1件」と数えたものを後段が「2件」と読んだ場合、後半のかけらは宙に浮き、後段の受信箱の先頭に居座ります。そこへ次にやってきたまったく別の利用者のリクエストが繋がると、二つが合体して1件になる——攻撃者が仕込んだ断片が、他人のリクエストの頭にくっついて送られるわけです。これが密輸（smuggling）と呼ばれる理由で、PortSwiggerの解説が図解つきで詳しく扱っています。

被害が重く見られるのは、ここから先が三方向に伸びるからです。第一にキャッシュ汚染。Traffic Serverはレスポンスを貯めて他の利用者に配り直す装置なので、細工した応答を正規URLの控えとして貯めさせれば、以後そこへアクセスした全員に攻撃者の用意した中身が配られます。第二にアクセス制御の回避。前段で止めるはずの管理用パスへのリクエストを、通過が許された別リクエストの陰に隠して後段へ届けられます。第三に他人の通信の乗っ取り。合体先が正規利用者のリクエストである以上、その人のCookieや認証情報を伴った状態で攻撃者の指定した処理が走ったり、その人への応答が攻撃者側へ流れたりする経路が生まれます。

誰かのパスワードを破る必要はありません。破るのは「1件のリクエストはどこで終わるか」という合意だけです。だからCDNやリバースプロキシのように、多数の利用者の通信を1台で束ねる位置にある製品では、この種の欠陥が重く扱われます。

同じApacheが付けた数字が、なぜ3ポイント以上ずれるのか

本題です。CVE-2026-57834には、CVSS 3.1で10.0、CVSS 4.0で7.0という2つの公式スコアが並んでいます。どちらもApacheがCNA（採番機関）として自ら登録した値で、片方が誤りというわけではありません。CVSSを策定しているFIRSTが定めた、別々の計算式の出力です。

実際のベクトル（計算の内訳）を並べると、差の出どころが見えます。CVSS 3.1側は AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L。ネットワーク越し・低い難易度・権限不要・利用者の操作不要という条件が揃ったうえで、S:C（スコープ変更）——影響が製品の境界を越えて他へ及ぶ——が乗り、機密性と完全性が「高」になった時点で10.0に振り切ります。3.1のスコープ変更は、乗った瞬間に上限へ押し上げる強い重みを持っています。

CVSS 4.0側は AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L です。注目したいのは2点あります。ひとつは影響の記述が二重になったこと。VC/VI/VA（脆弱なシステム自身への影響）が3つとも「なし」で、SC/SI/SA（その先のシステムへの影響）が「高・高・低」です。スマグリングはTraffic Server自体を壊すのではなく、その先や周囲にいる別の利用者に効く攻撃なので、この配置になります。3.1では両者が1つの箱に混ざり、スコープ変更というフラグ1つで表現されていました。もうひとつはAT:P（攻撃要件あり）で、4.0は「攻撃者の努力とは別に、成立に必要な前提条件が存在するか」を独立した項目として持つようになりました。

ここから言えるのは、CVSS 4.0は「その脆弱性単体で、どこまで自力で到達できるか」をより細かく分けて記述する設計になっているということです。後段サーバーの構成や別の条件が噛み合って初めて成立するタイプ——連鎖の前提が要るもの——は、その前提が項目として明示されるぶん、3.1より下がりやすくなります。ただし、この差がすべての事例で同じ向き・同じ幅で出るとは限りません。4.0は基本値のほかに脅威情報や環境情報を足して使う前提の指標でもあり、「4.0が低いから安全」と読み替えるのは誤りです。7.0や7.8は、4.0の区分ではHigh（重要）に相当します。

実務上の含意ははっきりしています。スキャナやニュースが3.1の10.0だけを拾えば「全システム停止級」に見え、4.0だけを見れば「そこそこ」に見える。どちらも同じ脆弱性の別の断面です。判断材料に使うなら、2つのスコアに加えて、Apacheが付けたimportant／moderateというラベル、そして実際に攻撃されているかどうかを並べて見る必要があります。

同じApacheの製品で、これと鏡像の関係にある事例を7月に扱っています。Apache Tomcatの2件（CVE-2026-59083・CVE-2026-59084）では、スキャナが9.1（Critical）と表示する一方、開発元Apacheの評価は「低」でした。あちらは外部のデータベースが機械的に補完した高い数字と、開発元の低い評価の食い違い。こちらは同じ開発元が、2つの方式で2つの数字を自分で出している——外部と内部のズレではなく、内部の中でのズレです。前者は「採番元の評価を見に行けば解決する」問題でしたが、後者はそう単純にいきません。どちらの数字も正しく、どちらも公式で、見るべきは数字の背後にあるベクトルの中身のほうだからです。同じApache関連では、AIが発見したHTTP/2の停止攻撃やログイン不要で悪用されるApache MINAの脆弱性のように、実際の緊急度は案件ごとに大きく違います。

アンカーのない正規表現が、同じ日に2度出てきた

CVE-2026-22068の中身に戻ります。正規表現は「文字列がこの形をしているか」を判定するための書き方で、アクセス制御ルールの照合によく使われます。ここで抜けていたのがアンカー——文字列の先頭（^）と末尾（$）を固定する指定です。これを忘れると、判定が「一致するか」ではなく「どこかに含まれているか」に変わります。admin を弾くつもりのルールが not-admin-page にも反応する、あるいは許可判定なら、許可したい文字列を途中に紛れ込ませた別のパスまで通ってしまう。設定した本人には、ルールが効いているようにしか見えません。

この欠陥は、当サイトが本日午前に公開した記事と正面から重なります。日本の個人サイト・同人サイトで広く使われている投稿ツール「てがろぐ」のCVE-2026-64940（ログイン不要で管理画面に入られる）は、分類こそCWE-625（制限が不十分な正規表現）と別番号ですが、原因は同じ「文字列の先頭と末尾を固定し忘れたために、本来はじくべき入力が通る」です。

並べてみると示唆的です。片や、個人が自分のサイトに設置するPerl製CGI。片や、ComcastやAkamaiの配信基盤で動き、毎秒テラビット級の通信を捌くC++製プロキシ。開発規模も利用者数もレビュー体制も何もかも違う2つのソフトウェアで、2026年7月29日という同じ日に、同じ種類の書き忘れが公表されました。正規表現のアンカー漏れは、コードの品質や組織の大きさで自動的に防がれる類の欠陥ではありません。文法上は完全に正しく、テストも通り、意図した入力に対しては正しく動くからです。露見するのは、誰かが意図しない入力を持ち込んだときだけです。

攻撃者像と狙い

この製品が置かれている場所を考えると、関心を持つ側の顔ぶれは自然に絞られます。目当ての通り道に立っているのは大手CDN・ISP・大規模メディアの配信基盤を継続的に観測している、資金と時間のある攻撃グループです。個人サイトを機械的に刈り取る自動巡回とは動きが違い、対象を選び、構成を調べ、前段と後段の組み合わせごとに挙動の違いを試します。リクエスト・スマグリングの成立条件は「前段と後段の解釈のズレ」なので、相手の構成が分からなければ何も起きない——裏返せば、調べる手間をかけられる相手ほど有利な攻撃です。

狙いを定めたあと最初に手を出すのは、キャッシュへの書き込みと、認証の前で止まっているはずのパスへの到達の2つです。前者は、細工したレスポンスを正規URLの控えとして貯めさせる操作。トップページや共通のJavaScriptファイルの控えを差し替えられれば、以後そこへ来た全員に攻撃者の中身が配られます。後者は、本来なら前段で門前払いされる管理系のパスを、通過が許された別のリクエストに紛れ込ませて後段へ届ける操作です。CVE-2026-22068のACL回避やCVE-2026-41920のhost-SNI回避は、この2つ目の入口を直接広げるものです。

末端で起きることは、運用側の想定と噛み合いません。改ざんされたのは配信の途中にある控えなので、Webサイト本体のファイルには何の痕跡も残りません。サイトの管理者が自分のサーバーを何度確認しても異常は出ず、利用者側だけが偽のページを見ている、という状態が起こりえます。同時に、他人のリクエストに合体する性質上、ログに残る発信元は攻撃者ではなく、巻き込まれた正規利用者のIPアドレスになります。1台のプロキシの背後に多数のサイトが同居していれば、影響範囲はその全体に及びます。事故と気づくまでの時間が長くなりやすい——ここが、この種の脆弱性が実務で嫌われる本当の理由です。

バージョンの罠: 「9.1.15」は存在しない

ここが最も実害の出やすい落とし穴です。CVE-2026-41920だけ、公開されている情報の間で対象範囲と修正版が食い違っています。突き合わせた結果は次の通りです。

Apache自身が投じた公式アナウンスでは、CVE-2026-41920を含む全件について対象が「ATS 9.0.0 to 9.2.14」「ATS 10.0.0 to 10.1.3」、対処は「9.x利用者は9.2.15以降へ」「10.x利用者は10.1.4以降へ」と書かれています。本文中に「9.1.15」という文字列は一度も現れません。一方でCVE記録（採番元はApache自身）には「from 9.0.0 through 9.1.14」「upgrade to version 9.1.15 or 10.1.4」と書かれており、NVDもこれを転記しています。

決め手は配布物です。Apacheの公式配布サーバーを確認すると、2026年7月28日付で trafficserver-9.2.15.tar.bz2 と trafficserver-10.1.4.tar.bz2 が置かれている一方、9.1.15というファイルはどこにもありません。そもそも9.1系は9.1.4を最後に配布サーバー上で更新が止まっており、9系のLTSは9.2系に移っています。公式のダウンロードページも、現行として10.1.4（Current v10.x Release）と9.2.15（Long Term Support v9.x Release）の2つだけを案内しています。

以上から、CVE記録側の「9.1.14 / 9.1.15」という表記は、9.2.14 / 9.2.15 の誤記である可能性が高いと判断できます。ただしこれはApacheが訂正を出したわけではなく、公式アナウンスと配布物からの推定です。実務上の結論だけは明快で、9系を使っているなら上げ先は9.2.15一択。9.1.15を探しても見つからないので、探して時間を使う必要はありません。9.2.15はアナウンスに挙がった38件すべての修正を含む版であり、41920もそこに含まれます。

8系を使っている場合、修正版はない

CVE-2026-57834とCVE-2026-58150は、CVE記録上「8.0.0 through 8.1.9」も対象と明記されています。追記分でも4件（CVE-2026-58155・CVE-2026-58154・CVE-2026-58151・CVE-2026-65324）が同じ範囲を含み、8系を対象に挙げるエントリは計6件になりました。にもかかわらず、案内されている修正版は9.2.15と10.1.4だけです。8系はどうなるのか——確認した結果は次の通りです。

• ▸Apacheの公式アナウンス本文に、8.x系への言及は一切ありません。対象として挙がっているのは9.0.0〜9.2.14と10.0.0〜10.1.3の2系統のみです。
• ▸配布サーバー上の8系の最終リリースは 8.1.11（2024年7月25日）。今回の公表に合わせた8系のリリースは行われていません。
• ▸プロジェクトの公式ロードマップは、8.xのサポートを2023年3月までと記載しています。同時に「常に2つのメジャーバージョンをサポートする」との方針も示されており、現在その2つは9.2系と10.1系です。
• ▸CVE記録の対象範囲が「8.1.9まで」で切れている点については、8.1.10・8.1.11が影響しないのか、単に対象記載が最後の検証版で止まっているだけなのか、Apacheの公開情報からは判断できませんでした。

したがって8系利用者への答えは、「8系向けの修正版は提供されない。9.2.15または10.1.4へ移行するしかない」です。8系は2年間リリースが出ておらず、サポート期限も過ぎています。仮に8.1.11が上の6件の対象外だったとしても、アナウンスに並んだ残り32件のうち何が8系に残っているかを確認する手段がありません。8系を本番で使い続けること自体が、個別のCVEより大きなリスクという位置づけになります。

実際に攻撃されているのか、日本での扱いは

悪用状況を確認した結果を先に書きます。6件について、実際の攻撃に使われた報告も、攻撃を再現する実証コード（PoC）の公開も、公開情報上は見つかりませんでした。米国CISAが運用するKEVカタログ（実際に悪用が確認された脆弱性の一覧）にも6件とも登録されていません。KEVの見方については実際に攻撃されている脆弱性のリストの読み方にまとめています。

ただし、公表からまだ日が浅い点は割り引いて読む必要があります。CVE記録の公開時刻は日本時間の7月29日午後で、修正版のリリースはその前日です。差分から攻撃手法を組み立てる動きは、公表直後から始まるのが通例です。「今は悪用が確認されていない」は「これからも安全」ではありません。

日本語での扱いについては、本稿執筆時点でJVNおよびJPCERT/CCに本件の登録は確認できませんでした。国内の技術系メディアによる報道も見当たりません。Apache関連ではTomcatやHTTP Serverの脆弱性がJVNで取り上げられる例が多い一方、Traffic Serverは国内での知名度が高くないぶん、日本語の情報が出るまでに時間差が生じやすい製品です。前述のとおり報告者にはLY Corporationの技術者が複数含まれており、国内の大規模事業者にとっては他人事ではありません。

やるべきこと

更新の前後で見ておきたい点を挙げます。第一に、自組織のTraffic Serverが直接インターネットに面しているかどうか。CDNの内側やロードバランサの背後にある場合でも、スマグリングは「前段と後段のズレ」を突く攻撃なので、前段に別のプロキシがあること自体は防御になりません。第二に、remap設定やACLで正規表現を使っているかどうか。CVE-2026-22068の影響を受けるのはこの部分で、更新と併せてアンカーの有無を見直す価値があります。第三に、プラグインの棚卸し。38件のうち相当数がESI、header_rewrite、regex_remap、ts_lua、url_sigといったプラグイン側の欠陥で、使っていないプラグインを読み込んだままなら、外すこと自体が攻撃面の削減になります。

検知の観点では、リクエスト・スマグリングはアクセスログ上で正規の通信と見分けがつきにくい性質があります。それでも、同一接続で不自然に多いリクエスト、Content-LengthとTransfer-Encodingが同時に付いたリクエスト、HTTP/2でTransfer-Encodingを含むリクエストは、後追いで探せる手がかりです。更新前の期間にこれらが記録されていないかを確認しておくと、事後の判断材料になります。

よくある質問

Q. スキャナが「CVSS 10.0」と出しました。緊急停止すべきですか。

A. 停止までは求められていません。同じ脆弱性にApache自身がCVSS 4.0で7.0という値も付けており、深刻度ラベルはmoderateです。一方で修正版はすでに出ており、悪用の難易度は構成次第で下がります。計画的に、ただし先送りせずに9.2.15または10.1.4へ更新するのが妥当な線です。

Q. 9.1.15が見つかりません。どこにありますか。

A. 存在しません。CVE-2026-41920のCVE記録に9.1.15という記載がありますが、Apacheの公式アナウンスにも配布サーバーにもそのバージョンはなく、9.2.15の誤記と考えられます。9系の上げ先は9.2.15です。

Q. 8.1.11を使っています。対象外では。

A. CVE記録の対象範囲は8.1.9までですが、8系向けの修正版は提供されておらず、8系は2024年7月の8.1.11以降リリースがありません。8系を対象に挙げるエントリは追記分を含めて6件に増えており、残り32件の状況も確認できないため、対象外と判断する根拠はありません。9.2.15または10.1.4への移行を計画してください。

Q. CVSS 3.1と4.0のどちらを社内報告に使うべきですか。

A. 一方だけを使うと必ず誤解を生みます。両方を併記し、Apacheの深刻度ラベルとKEV登録の有無を添えるのが実務的です。数字を1つに絞る運用にしているなら、その運用自体が本件のような案件で機能しないことを、この機会に確認しておく価値があります。

まとめ

Apache Traffic Serverの脆弱性が2026年7月29日に一括公表され、修正版として9.2.15と10.1.4が出ています。公式アナウンスが列挙したCVEは38件で、うちCVSS 3.1が10.0に達したのは3件。ただしその3件のCVSS 4.0は7.7 / 7.0 / 7.8であり、両方ともApacheが付けた公式値です。差は、4.0が「製品自身への影響」と「その先への影響」を分けて記述し、成立に必要な前提条件を独立の項目として持つ設計から生まれています。片方だけを見た判断は、どちらの方向にも外れます。

実務上の要点は3つです。9系の上げ先は9.2.15であり、CVE記録にある9.1.15は存在しないこと。8系には修正版がなく、移行以外の選択肢がないこと。そして実悪用もPoCも公開情報上は見つかっておらず、KEVにも未登録であること。緊急停止を要する局面ではありませんが、公表からの日数が浅いだけとも読めます。数字が外部評価と開発元評価で食い違ったTomcatの件と、開発元自身が2つの数字を出した本件。どちらも、スコア1つで脆弱性を管理する運用の限界を示しています。

その限界は、公開直後に当サイト自身へ返ってきました。同じバッチから5件が加わり、CVSS 4.0で最上位に立つCVE-2026-58155とCVE-2026-58154は、3.1の高い順という基準で6件を選んだ時点で軸から外れていたのです。追記の詳細は冒頭のブロックにまとめました。並べ替えの基準を1つに固定すると、書く側でもこうなります。

参照元

• ▸Apache公式アナウンス - Multiple vulnerabilities fixed in Apache Traffic Server 9.2.15 and 10.1.4
• ▸Apache公式配布サーバー - Traffic Server リリース一覧
• ▸Apache Traffic Server - Downloads（現行版の案内）
• ▸Apache Traffic Server - Users（公式の利用者一覧）
• ▸Apache Traffic Server - ATS Release Roadmap（サポート期間）
• ▸CVE.org - CVE-2026-41920 の登録内容
• ▸NVD - CVE-2026-33267
• ▸NVD - CVE-2026-57834
• ▸NVD - CVE-2026-58150
• ▸NVD - CVE-2026-22068
• ▸NVD - CVE-2026-24033
• ▸NVD - CVE-2026-58155（追記分）
• ▸NVD - CVE-2026-58154（追記分）
• ▸NVD - CVE-2026-58153（追記分）
• ▸NVD - CVE-2026-58151（追記分）
• ▸NVD - CVE-2026-65324（追記分）
• ▸CVE.org - CVE-2026-58153 の登録内容（10系のみ対象）
• ▸Apache Traffic Server - records.config（server_ports の proto 指定）
• ▸FIRST - CVSS v4.0 仕様
• ▸FIRST - CVSS v3.1 仕様書
• ▸MITRE - CWE-444: Inconsistent Interpretation of HTTP Requests
• ▸MITRE - CWE-777: Regular Expression without Anchors
• ▸MITRE - CWE-787: Out-of-bounds Write
• ▸MITRE - CWE-400: Uncontrolled Resource Consumption
• ▸PortSwigger - HTTP request smuggling の解説
• ▸CISA - Known Exploited Vulnerabilities Catalog
• ▸Computerworld - Yahoo donates Traffic Server to Apache（2009年）