OpenTelemetry Pythonに脆弱性 長いヘッダーで処理が止まる 1.45.1へ

アプリの動きを見るために入れた観測の仕組みが、サーバーを止める入口になっていました。OpenTelemetryのPython版の部品opentelemetry-apiに、脆弱性CVE-2026-114603が見つかりました。要求に付く「tracestate」というヘッダーを読む処理が、空白を多く含む長い値に対して、とても時間がかかります。深刻度はMedium(CVSS 3.1で5.3)です。

対象は1.45.0以前で、1.45.1で直っています。1.45.1は2026年10月6日に公開され、プロジェクトの勧告は10月12日に、GitHubの勧告のデータベースには10月23日(日本時間)に載りました。

なぜ処理が止まるのか

OpenTelemetryは、サービスをまたいで処理の流れ(トレース)を追うため、要求のヘッダーで情報を引き継ぎます。tracestateは、その引き継ぎに使うW3Cの決まりのヘッダーの1つです。

勧告によると、opentelemetry-apiは、tracestateを区切るための正規表現で、長さを確かめないまま値を分けていました。空白やタブが続いてコンマが来ない値だと、読む時間が値の長さの二乗に比例して増えます。勧告の測り方では、長さが2倍になるたびに時間が約4倍になりました。

認証は要らず、要求を1回送るだけで起きます。非同期(asyncio)で動くサーバーでは、その間ほかの接続もすべて待たされます。形の合わない値は、警告のログにそのまま全部書き出されるため、ログも膨らみます。

どこから届くか

勧告は、既定の設定(環境変数OTEL_PROPAGATORSの既定はtracecontext,baggage)で、要求を受けるサーバー側の計測が引き継ぎの情報を読むときに届くとしています。例として、ASGIのアプリの計測(opentelemetry-instrumentation-asgi)を挙げています。同じ作りは、2021年3月の1.0.0からありました。

前に置くWebサーバーがヘッダーの大きさを制限していれば、届く前に断られます。勧告の試験の結果は次のとおりです。

8KiBのヘッダーでも約0.07秒、16KiBで約0.25秒かかるため、上限が16KiBでも、繰り返し送られれば負荷になります。

1.45.1は、読み方を直したうえで、8192文字を超えるtracestateを捨てるようにしています。同じ部品の別の引き継ぎの仕組み(baggage)には、もともと8192バイトの上限がありました。

影響する会社・しない会社

• 影響する: PythonのWebのアプリやAPIで、OpenTelemetryのサーバー側の計測を入れ、opentelemetry-apiの1.45.0以前を使っている会社。とくに、uvicorn[standard]で動かすFastAPIなどのASGIのアプリ
• 確かめる: 社外から要求を受けるサービスで、前にリバースプロキシやロードバランサーを置いている会社。そこでヘッダーの大きさに上限があるかで、届くかどうかが変わります
• 影響しない: OpenTelemetryを入れていない会社、Python以外の言語の版だけを使っている会社。今回の勧告はPython版のopentelemetry-apiが対象です

情シスが今日やること

1. 入っている版を調べます。 PythonのWebのアプリの環境で pip show opentelemetry-api などを実行し、版を一覧にします。計測の自動化の道具が、意図せず入れていることもあります。
2. 1.45.1以降に上げます。 opentelemetry-apiを1.45.1以降にし、アプリを再起動します。opentelemetry-sdkや計測の部品も、同じ系列にそろえます。
3. ヘッダーの上限を確かめます。 前に置くリバースプロキシ、ロードバランサー、WAFで、要求のヘッダーの大きさに上限があるかを確かめます。上げるまでの間の守りになります(当社の見立て)。
4. ログの量を見ます。 形の合わないtracestateは警告のログに全部書かれます。警告のログが急に増えていないか、ログの保存の容量に余裕があるかを見ます。