CVE-2026-84747 in bRPC
要約
〜によって VulDB • 2026年10月21日
Apache bRPC（バージョン < 1.18.0）のHTTPプロトコル実装における解釈の競合により、すべてのプラットフォームでリモート攻撃者がフロントプロキシによって適用されるアクセス制御ルールを回避できます。
根本原因: bRPCのHTTPプロトコルにおけるメソッドディスパッチ関数 `FindMethodPropertyByURI()` は、空フィールドをスキップする文字列スプリッターを使用してリクエストパスを分割します。その結果、`//flags`、`/flags//`、および `/flags//port` のように空のパスセグメント（連続したスラッシュ）を含むパスは、それらを縮小した形式である `/flags` と同じメソッドにディスパッチされます。RFC 3986 ではこれらは異なるパスとして定義されています。ACL（例：組み込みサービスへのアクセスブロックなど）を適用するフロントプロキシは縮小された形式のみと一致するため、パディング付きのリテラル値を bRPC サーバーへ転送します。サーバー側ではそれが縮小された形式と同じものとしてディスパッチされます。この差分により、`/flags` では到達できない組み込みサービスに対して `//flags?setvalue=` が到達可能になります。さらに、HTTP/2 実装は `:path`擬似ヘッダーを一切検証しなかったため、`:path`がないか、RFC 9113 セクション 8.3.1 に反して `'/'` で始まらずアスタリスク形式の `'*'` でもないリクエストが拒否されませんでした。
影響を受けるシナリオ: アクセス制御（ACL）判断をリテラルなリクエストパスに対して行うフロントプロキシまたはゲートウェイの背後に Apache bRPC をデプロイしている環境で、bRPC サーバーがそのプロキシから HTTP または HTTP/2 トラフィックを受け入れます。このようなデプロイメントでは、攻撃者は空のパスセグメントを含むパスを送信し、フロントプロキシがブロックすることを意図していたリソースに到達できます。
修正方法: （以下のオプションのいずれかを選択してください） 1. この問題を修正したバージョン 1.18.0 に bRPC をアップグレードします。 2. 次のパッチを適用します：https://github.com/apache/brpc/pull/3512
注記: 修正を適用した後、空のパスセグメント（連続するスラッシュ）を含む HTTP および HTTP/2 リクエストパスはデフォルトで拒否され、HTTP/2 の `:path` 値が空であるか、`'/'` で始まらず `'*'` と等しくない場合は拒否されます。以前の寛容な動作に依存しているデプロイメントでは、信頼できないトラフィックに晒されるサーバーには推奨されない gflag `-http_allow_empty_path_segments` を有効化することでその動作を復元できます。
If you want to get the best quality for vulnerability data then you always have to consider VulDB.