cplusplus17/deco-filepush-disclosureTP-Link Deco XE75 Pro V3のデバッグチャネル（tmpsvrオペコード0xC456/0xF0）におけるroot権限でのファイル読み書き脆弱性に関する開示およびPoC。CVSS分析とハンドラの逆コンパイル付き。
関連する VLAN プロジェクト: この XE75 Pro V3 のファームウェア/プロファイルに 正確に対応する実験的な固定 VLAN-30 ソースのアルファ版です。運用者が用意した 純正ファイルが必要で、汎用的なインストーラや書き込み可能なイメージはありません。 ゲスト VLAN 591 は未解決のままです。最終的な 3 台構成でのコールドブート、 UI、クライアント分離の受け入れテストは未完了です。 現在のステータスを参照してください。
研究開示、TP-Link Deco XE75 Pro V3、ファームウェア 1.5.0 Build
20260603 Rel.15804。[email protected] 向けに作成し、当社の 802.1Q IoT VLAN 実装（deco-iot-vlan）と併せて公開します。
Deco のオーナー認証済みデバッグ SSH チャネル（TCP 20001 上の Dropbear、
direct-tcpip 転送のみ、パスワード認証）は、127.0.0.1:20002 上の内部
tmpsvr サービスに到達します。その Lua ハンドラの一つである
inner_file_push（オペコード 0xC456）は、params.file を "w" モードで開き、
params.content をそのままroot 権限で、パスの許可リストもサイズ制限も
権限降格もなしに書き込みます。兄弟オペコード（0xF0）は、対応する
root 権限でのファイル読み取りを提供します。これらを組み合わせると、
認証済みの読み取り + ルートファイルシステム全体への書き込みが可能となり、
ルーターにおいてはそれはデバイス全体を意味します。
SSH :20001 (username = SHA1(owner_email), password = TP-Link account password)
-> direct-tcpip -> 127.0.0.1:20002 (TMPv2)
-> 0xC456 inner_file_push : io.open(file,"w"); write(content); close() [root]
-> 0x00F0 root file read : byte-exact file read [root]
/etc/config は書き込み可能なライブ ramfs → キーを変更すると、ルーターはそれを尊重する。/www は uhttpd により HTTPS 経由で配信される → プッシュされたファイルは即座に到達可能になる。/tp_data/user_data は永続的な ubifs フラッシュ → 再起動後も保持される。GET /cgi-bin/luci 経由でトリガーされる → root 権限での Lua 実行 → io.popen → 任意の root バイナリ実行。4つのステップはすべて、所有者自身のメインユニット上で実行され、元に戻された。
tmpsvr が未修正のままである理由UCR SecLab チームは、:20001 -> 127.0.0.1:20002（tmpsvr）デバッグチャネルを 2年前 に CCS 2024 —「Untangling the Knot: Breaking Access Control in Home Wireless Mesh Networks」（および Black Hat USA 2024 —「Fallen Tower of Babel」）で公開文書化した。旧型 Deco モデル（X55、FW 1.2.2）における彼らの侵入経路は、512ビット RSA ホストキーの因数分解 と、検証されていない tmpsvr ハンドラの悪用であった。
この正確なファームウェア上で観察された差異と残存するハンドラ:
ssh-rsa ホストキーのサイズを512ビットから 2048ビット に増やし（3台のメッシュユニットすべてで観察された共有キー SHA256:9feb3ac4...932a36、およびユニットごとの ecdsa-sha2-nistp521）、2024年の講演で示された512ビット因数分解経路を塞いだ。1.5.0 には以下の root レベルのハンドラが存在する:
:20001 上のパスワード認証（svr_auth_uci） は、SHA1(owner_email) と共有 TP-Link ID パスワードを使用して依然として有効である。0xC456（inner_file_push） は、パス検証が一切ないまま、呼び出し元が指定した任意のパスを root として "w" モードで開く。0x00F0 は、ファイルシステム上の任意のファイルを root として読み取る。0xC505（tty2tcp/start）さえも — 2024年の論文で強調された、クォートされていない /bin/sh -c コマンドインジェクションハンドラそのもの — が 2026年6月のファームウェア（1.5.0）に完全に未修正のまま残っている。luci/controller/admin/mobile_app/iot_device モジュール、inner_file_push）に存在する。実証されたのは LAN からの到達性のみである。観察された LAN 限定のプロファイルについては、AV:A のバリアントを使用する: v3.1 6.8 / v4.0 8.5。以下の AV:N スコアは、ネットワーク経路が実証された場合に条件付きであり、クラウドからの到達性は未検証である。
これは 認証後、所有者権限 から root への昇格であり、未認証 RCE ではない — 以下に示す観察プロファイルのスコアは 6.8（v3.1）および 8.5（v4.0）である。完全な根拠と却下されたスコアの水増しについては docs/cvss-analysis.md を参照。
CVSS v3.1 — LAN 限定評価 6.8（Medium）、条件付きリモートバリアント 7.2（High）:
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H = 7.2 (High)
CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H = 6.8 (Medium) # if LAN-only
決定的な判断: PR:H（所有者 / TP-Link-ID アカウントがデバイスの管理主体である）および S:U（ハンドラはすでに root として実行されている — 権限境界を越えない）。初期のドラフトでは PR:L + S:C により 9.9 と評価されていたが、両方とも却下された。
CVSS v4.0 — LAN 限定評価 8.5（High）、条件付きリモート変種 8.6（High）:
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N = 8.6 (High)
CVSS:4.0/AV:A/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N = 8.5 (High) # if LAN-only
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L = 9.3 (Critical) # with Subsequent-System LAN/mesh impact
現実世界でのリスク — 盗まれた、あるいは使い回された TP-Link-ID のパスワードがメッシュ全体にわたる永続的な root 権限へと昇格し、さらにクライアントトラフィックの MITM を招くこと — は、誇張された v3.1 の基本ベクターではなく、ナラティブ（および v4.0 の SC:H/SI:H/SA:L Subsequent-System メトリクス）に記載されるべきものです。
poc/deco_filepush_poc.py — 自己完結型（stdlib + paramiko）。認証情報は DECO_EMAIL / DECO_PASSWORD 環境変数を介してのみ渡します。ライブモードでは DECO_HOSTKEY が必要で、これは独立して検証されます。生の base64、公開鍵の行、または ssh-keyscan の鍵行 1 行（コメント対応）のいずれかです。スキャンだけではデバイスの認証は行いません。HTTPS チェックは配信されたバイト列を比較しますが、その証明書は検証しません。モードはちょうど 1 つだけ指定する必要があり、検証に失敗した場合は非ゼロで終了します。
python3 poc/deco_filepush_poc.py --selftest # offline framing sanity
[email protected] DECO_PASSWORD=*** DECO_HOSTKEY="$TRUSTED_DECO_HOSTKEY" \
python3 poc/deco_filepush_poc.py --run # write marker + readback + HTTPS check
[email protected] DECO_PASSWORD=*** DECO_HOSTKEY="$TRUSTED_DECO_HOSTKEY" \
python3 poc/deco_filepush_poc.py --cleanup <nonce> # overwrite marker with empty content
PoC は /www/log_export（ramfs。再起動時にもクリアされる）に単一の無害なマーカーを書き込み、その後、成功を報告する前にデバイス自身の root-read オペコードによるバイト単位で正確な読み戻しと未改変の HTTPS 配信を要求します。
ssh-keyscan -p 20001 <deco> → ホスト鍵をピン留め（メッシュ全体で共有される 2048 ビット RSA + ユニットごとの nistp521）。SHA1(owner_email) / TP-Link アカウントのパスワードで SSH 接続し、127.0.0.1:20002 への direct-tcpip を要求。01010100 → 01010200 → 01010200）、続いてオペコード 1 のトークン要求。0xC456、{"params":{"file":"/www/log_export/deco-write-<nonce>.html", "content":"..."}} → {"error_code":0,...}。0xF0、{"params":{"file":"..."}} → バイト単位で正確な読み戻し。GET https://<deco>/log_export/deco-write-<nonce>.html → 200、正確なバイト列。tty2tcp（0xc505）経路は存在が確認されており未検証（静的）だが、別個のインジェクションとしてライブ検証はされていない。完全性のために記載する。この研究は、シンプルかつ防御的な目標から始まりました。それは、アクセスポイントモードで動作する 3 台構成の Deco XE75 Pro V3 メッシュ全体にわたり、信頼できない IoT デバイスをタグ付き 802.1Q VLAN 上に分離することです。
2026 年において、基本的なネットワークセグメンテーション（IoT デバイスを分離された VLAN に配置すること）は根本的なセキュリティ要件です。しかし純正ファームウェア 1.5.0 では、この機能は人為的に未完成のまま放置されています（/lib/iot_network/iot_eth.sh は rootfs から省略され、/etc_ro/init.d/iot_network 内の VLAN ロジックはコメントアウトされています）。これにより厳しい選択を迫られました。完全に能力を備えた Wi-Fi 6E メッシュルーター 3 台を電子廃棄物として捨てるか、それともファームウェアをリバースエンジニアリングして欠落した機能を自らパッチするか。
私たちは、このセキュリティアドバイザリと、併せて提供する VLAN 実装（deco-iot-vlan）の両方を公開することを選びました。その理由は次のとおりです。
20001 を制限する。露出した root ファイル書き込みインターフェースの存在に気づかないままにしない）。README.md — このファイルTEAM-SUMMARY.md — マルチエージェントチーム（claude、codex、gemini、hermes/Qwen）がどのように発見したかpoc/deco_filepush_poc.py — 自己完結型 PoCdocs/cvss-analysis.md — スコアリングの根拠 + フォールバックマトリクスdocs/handler-source.md — 逆コンパイルされた inner_file_push ハンドラ + 参照tp-link-email.md — ベンダー報告書のドラフト。配信は未確認reddit-post.md — コミュニティ投稿のドラフト所有者主導による独立したリバースエンジニアリング。要望に応じて、逆コンパイルされたモジュール全体、オフラインでのフレーミング導出、およびメッシュのホスト鍵インベントリを共有できます。