RDK-B WebUIに脆弱性5件、修正未提供で認証回避

ブロードバンドルーターやホームゲートウェイの基盤ソフト「RDK-B」の管理画面（WebUI）に、5件の脆弱性が公表されました。最も深刻なものは、署名が正しくない偽造トークンでも管理者としてログインできてしまう認証回避（CVE-2026-19505）です。CERT/CC が2026年8月19日に公表し、JPCERT/CC も JVNVU#91551881 として注意喚起しています。

そして厄介なのは、本稿執筆時点で修正版が提供されているかどうかが分からないことです。開発元の RDK Central から回答が得られておらず、CERT/CC の勧告でもベンダーステータスは「Unknown」のまま。つまり「アップデートして終わり」にできない類の脆弱性で、当面の対策は「管理画面を外部から触らせない」の一点に絞られます。

この記事でわかること

• RDK-B とは何で、なぜ「うちは使っていない」と即断できないのか
• 公表された5件の脆弱性の内容と、特に危険な認証回避の仕組み
• 自社・自宅の機器が該当しそうか、その場で確認する方法
• 修正版が出ない状況で、情シスが現実的に取れる手

RDK-B とは何者か

RDK-B（Reference Design Kit for Broadband）とは、ブロードバンド回線用のルーターやホームゲートウェイを動かすための、オープンソースの組み込みソフトウェア基盤です。もとは米 Comcast が開発し、現在は業界団体 RDK Central が開発を継続しています。用途は、通信事業者（ISP・ケーブル事業者）が加入者に貸し出す宅内機器の中身を共通化すること。メーカーごとにバラバラだった独自ファームウェアの代わりに載せることで、機種が違っても同じ方法で設定配信・遠隔管理ができるようになります。

ここが重要です。RDK-B は「自分で選んで導入する製品」ではなく、通信事業者から貸与された機器の中に最初から入っているソフトウェアです。RDK Central が2025年9月に公表したプレスリリースによれば、RDK 系ソフトウェアの出荷実績は全世界で累計2億台を超え、採用事業者として Comcast、Charter、Deutsche Telekom、Liberty Global、Orange、Sky、Vodafone、そして日本の J:COM などの名前が挙げられています。

ただし、「採用事業者リストに載っている＝その貸与機器が今回の脆弱性の影響を受ける」とは限りません。問題になったのは RDK-B の中の WebUI という一部コンポーネントで、事業者やメーカーが独自の管理画面に差し替えている場合もあります。個別機器の実装は公表されていないため本稿では断定せず、後述の手順で機器側から見分ける方法を示します。

何が起きたのか：公表された5件の脆弱性

ポーランド・ヴロツワフ科学技術大学のセキュリティチーム（Mikołaj Pisula 氏・Michał Bernacki 氏）が報告し、CERT/CC が VU#874418 として2026年8月19日に公開しました。対象として明記されているバージョンは rdkb-2025q4-kirkstone（NVD の記載では rdkb-2025q4-kirkstone.04.10.26）です。

5件のうち4件が認証不要である点が、この勧告の重さを決めています。管理画面にネットワーク的に到達できさえすれば、ID もパスワードも要りません。

なお、本稿執筆時点（2026年8月22日）で、これら5件に CVSS スコアは付与されていません。NVD 上のステータスは「Received」で、深刻度の数値評価はこれからです。「スコアが出ていないから軽い」ということではないので、数値待ちにせず、影響範囲の判断は自分で行う必要があります。

なぜ偽造トークンでログインできてしまうのか

答えは、OpenSSL の関数の戻り値の判定を間違えているからです。CERT/CC の記述によれば、WebUI の jst_functions.c は JWT（ログイン状態を持ち回るための署名付きトークン）の署名検証に OpenSSL の EVP_VerifyFinal() を使っていますが、署名が正しい場合と正しくない場合の両方を「検証成功」として扱ってしまっています。結果、攻撃者は中身が出鱈目な署名の JWT を作って投げるだけで、管理者としてのセッションを得られます。

これは古典的な落とし穴です。EVP_VerifyFinal() は「検証成功で 1、検証失敗で 0、エラーで負の値」を返します。ここで「0 以外なら OK」あるいは「負でなければ OK」と書くと、検証失敗（0）が成功として素通りします。暗号ライブラリを正しく呼んでいても、戻り値の受け取り方ひとつで認証が丸ごと無効化されるわけです。なお研究チームは、CVE-2026-19508 については AFL++ によるファジングで発見したと報告しています。管理画面という「業務ロジックの塊」に見える部分も、実体は C で書かれたネイティブプロセスだということです。

自社・自宅の機器が該当しそうか確認する方法

資産管理台帳に「RDK-B」と書いてある組織はまずないはずです。機器側から見分けるしかありません。

1. 管理画面の URL に .jst という拡張子が出るか：RDK-B の WebUI は独自の JST テンプレート（JavaScript に変換して Duktape で実行する仕組み）を使っており、今回の勧告でも check.jst、ajaxSet_wireless_network_configuration.jst といったパスが名指しされています。ブラウザの開発者ツールでネットワークタブを開き、ログイン時のリクエスト先に .jst が並んでいれば、RDK-B 系 WebUI の可能性が高いと判断できます。
2. Web サーバーが lighttpd か：研究チームの解析では、WebUI は lighttpd 上で CGI ハンドラ /usr/sbin/jst が動く構成です。レスポンスヘッダの Server: は隠されていることもありますが、手がかりにはなります。
3. WAN 側（インターネット側）から管理画面に到達できるか：これが最重要です。社外のネットワークから、拠点の固定 IP に対して管理画面が開けないかを確認してください。開けるなら、脆弱性の有無に関係なく今すぐ塞ぐべき状態です。
4. 貸与機器なら、契約している通信事業者に問い合わせる：VU#874418 と CVE-2026-19505 を挙げて、「自社に貸与されている機器が該当するか」「該当する場合の対応予定」を確認するのが確実です。

研究チームは Censys の観測データとして、管理インターフェースがインターネットに露出している機器を約3万台（米国 約1.9万台、ペルー 約8千台）確認したと報告しています。日本国内の台数は示されていませんが、「そもそも外部に開いている個体が現に数万台ある」という事実は押さえておくべきでしょう。

想定されるリスク：踏み台と、在宅勤務の足元

ルーターの管理者権限を取られると、DNS の向き先の書き換え、VPN 設定の追加、ポート転送による内部への侵入経路の作成がすべて可能になります。端末側のセキュリティ製品からは、これらは「正規の通信」にしか見えません。加えて近年の攻撃者は、乗っ取った家庭用・小規模拠点用の機器を束ねて攻撃の中継網として使います（ORB化とは 境界機器が攻撃の中継拠点にされる脅威）。被害者であると同時に、他社への攻撃元になるという意味でも無視できません。

そして情シスにとって現実的に厄介なのが在宅勤務です。従業員の自宅にある ISP 貸与ルーターは、会社の資産台帳にもパッチ管理の対象にも入っていません。VPN で社内に繋がる端末の手前に、管理できない機器が挟まっている構図です。

現場目線の課題：直せない脆弱性という現実

正直に言えば、今回の勧告を読んで最初に浮かぶのは「で、こちらは何ができるのか」という徒労感です。貸与機器のファームウェアは利用者側で更新できず、更新は事業者が配信するもの。その事業者側の対応時期も見えません。研究チームが公開したタイムラインによれば、2026年4月12日に RDK 側へ報告したものの、5月20日に「レポートを受領していない」との連絡があり、6月8日に CERT/CC 経由へ切り替え、7月21日にようやく RDK 側がレポートの復号を完了した——という経緯です。8月19日の公開時点でもベンダー声明は出ておらず、研究チーム自身が「修正されたかどうか現時点では分からない」と書いています。

「修正版が出たら当てる」という、普段の拠り所がそもそも成立しない。残るのは攻撃者が到達できる経路を減らすことだけです。リモート管理を切る、管理画面を管理用セグメントからしか触れないようにする、初期パスワードを変える——地味ですが結局ここに戻ってきます。修正が出ない機器と付き合う難しさは WatchGuard Firebox脆弱性17件、11.x系は修正なし でも同じ形で表れていました。そして「自分で入れた覚えがない部品」が最も危ないという構図は、ESP-IDFにDHCP脆弱性 ESP32搭載機器が影響 と同じです。SBOM のような「中身の一覧」がない限り、情シスは自分の資産に何が入っているかを知りようがありません。

情シスはどうすべきか

CERT/CC が示している当面の対策は明快で、「WebUI へのアクセスを信頼できる管理ネットワークと許可したホストに限定する。管理インターフェースをインターネットや信頼できないネットワークに直接晒さない」——これだけです。まずは自社拠点のルーター・ゲートウェイについて、リモート管理（WAN 側からの管理画面アクセス）が有効になっていないかを確認してください。そのうえで「ネットワーク機器の棚卸し」を仕組みとして整えるなら、自前でチェックリストを作るより公的な指針を土台にするほうが早く、社内の説明にも使えます。

• 中小企業の情報セキュリティ対策ガイドライン（IPA）：資産の把握から更新管理、委託先との役割分担までの骨格が示されています。「貸与機器の責任分界点」を社内で議論する際の共通言語になります。
• 対策のしおり（IPA）：在宅勤務者への啓発資料として使えます。自宅ルーターの管理画面パスワード変更やリモート管理の無効化は、情シスが代行できない以上、本人にやってもらうしかありません。地道な啓発が最後は効きます。
• JVNVU#91551881（JPCERT/CC）：社内向けの一次情報として引用できます。

拠点のルーターやアクセスポイントの脆弱性対応は、機器の型番単位で追いかけるとすぐ破綻します。エレコム無線LAN機器7製品に脆弱性 法人向けAPが対象 のような個別事案も含め、「ネットワーク機器の管理画面は外に出さない」という原則を先に固めておくほうが、結果的に手数が減ります。

中長期の視点：共通基盤の集中リスク

独自ファームウェアを共通のオープンソース基盤に置き換える流れ自体は合理的です。多くの目でコードが見られ、修正も一箇所で済む。今回の脆弱性が外部の研究チームに発見されたのも、ソースが公開されているからこそです。一方で共通化は「1つの欠陥が数千万台に同時に効く」構造でもあります。累計2億台規模の基盤で認証回避が見つかったとき、修正がどれだけの速さで末端まで届くのかは事業者ごとの運用に委ねられ、利用者からは見えません。開発元との連絡がつくまでに3か月以上かかった事実は、その伝達経路が必ずしも整っていないことを示しています。

情シスの立場でできるのは、「更新が届く保証のない機器」を前提に設計しておくことでしょう。宅内・拠点のルーターを信頼境界の内側に置かない、管理画面は必ず管理セグメントに閉じる、拠点間通信は機器の信頼性に依存しない形で暗号化する。ゼロトラストの発想は、こういう「直せない箱」を抱え込んだときに効いてきます。

まとめ

1. ブロードバンド機器の基盤 RDK-B の WebUI に脆弱性5件（CVE-2026-19505〜19509）。うち4件は認証不要で、署名検証の実装ミスにより偽造トークンで管理者ログインが可能です。対象は rdkb-2025q4-kirkstone、CVSS スコアは本稿執筆時点で未付与です。
2. 修正版の提供状況は不明。開発元 RDK Central からの回答が得られておらず、CERT/CC のベンダーステータスは Unknown のままです。当面の対策は「管理画面をインターネットに晒さない・信頼できる管理ネットワークからのみアクセスさせる」に尽きます。
3. RDK-B は自分で導入する製品ではなく通信事業者の貸与機器に入っているソフトです。管理画面の URL に .jst が現れるか、WAN 側から管理画面が開かないかをまず確認し、該当が疑われる場合は VU#874418 を挙げて事業者に問い合わせてください。在宅勤務者の自宅ルーターも同じリスクを抱えています。

出典

• VU#874418: RDK-B WebUI contains multiple vulnerabilities（CERT/CC、2026年8月19日公開）
• JVNVU#91551881 RDK-B の WebUI における複数の脆弱性（JPCERT/CC）
• NVD – CVE-2026-19505
• Multiple vulnerabilities in RDK-B（Whitehats, Wrocław University of Science and Technology）
• Global Adoption of RDK Surpasses 200 Million Devices Across Leading Broadband and Video Service Providers（RDK Central、2025年9月4日）
• RDK Broadband Documentation – WebUI（RDK Central）
• 中小企業の情報セキュリティ対策ガイドライン（IPA）
• 対策のしおり（IPA）