【独自調査】タイムズ・まんだらけ・らしんばんの保存ソースを比較　旧版jQueryと脆弱性管理の課題

不正アクセスを公表したタイムズカー、まんだらけ、らしんばんのWebサイトについて、Internet Archiveに保存されたHTMLとJavaScriptを比較しました。タイムズとまんだらけには同系統のTeeda Ajaxコードがあり、らしんばんにはEC-CUBE由来のJavaScriptが確認できました。

3社の調査対象ファイルには、それぞれjQuery 1.2.6、1.10.2、3.3.1のバージョン表記がありました。いずれも、jQueryが公表する2件の既知脆弱性の対象範囲に含まれます。

ただし、今回確認したのは保存された公開ソースです。各社の環境で脆弱性が成立することや、今回の不正アクセスに悪用されたことを示す証拠は得られていません。
この前提で調査結果と、企業が旧版ライブラリの影響評価・更新を先送りするリスクを整理します。

調査対象と保存時点

調査では、提供されたInternet Archiveの保存HTML・JavaScriptを読み、スクリプトの参照先、バージョン文字列、関数名、処理内容を比較しました。サーバー内部のプログラムやログを取得した調査ではありません。

日時は保存ファイルの記録に合わせ、UTCで統一しています。日本時間は9時間後です。
※HTMLと参照先のJavaScriptは別々に保存されるため、一式が同時点の構成を完全に再現しているとは限りません。

※まんだらけの通販画面のソースは2025年しかみあたりませんでした。

タイムズとまんだらけに同系統のTeeda Ajaxコード

タイムズとまんだらけの保存ソースでは、SeasarプロジェクトのTeeda Ajaxに由来するajax.jsに、サーバーからの応答をevalでJavaScriptとして評価する処理が確認できました。攻撃者が応答に実行可能なコードを混入でき、その応答が評価される場合、利用者のブラウザーで不正なJavaScriptを実行するクロスサイトスクリプティング（XSS）につながる可能性があります。成立した場合、ページ内の情報の読み取りや、ログイン中の利用者の権限を使った不正な操作が問題となります。

確認したのは、応答を処理する_evalResult内の次のコードです。

eval('(' + resText + ')')

resTextはサーバーから受信した応答文字列です。この実装は、応答をJSONデータとして解析するのではなく、JavaScriptの式として評価します。前後を丸括弧で囲んでも、実行できる内容をデータだけに制限することにはなりません。外部入力が適切にエスケープされず、実行可能な式として応答に組み込まれるような経路が、診断時の確認対象になります。

両社の保存ソースで確認した構成

Teeda Ajaxは、ブラウザーのJavaScriptからサーバー側のJavaの処理を呼び出す仕組みです。クライアント側ではKumu.Ajaxが通信と応答処理を担います。

タイムズのログインHTMLには、Teedaの名前空間を示すxmlns:te="http://www.seasar.org/teeda/extension"と、teedaExtension配下のajax.js、kumu.jsを読み込む記述がありました。まんだらけの通販HTMLもajax.jsを参照し、両社のJavaScriptに次の識別子や処理が確認できました。

確認したコード	技術的な役割
Kumu.Ajax	Ajax通信と応答処理を担うクライアント側の実装
executeTeedaAjax	コールバック関数やパラメーターを指定してサーバー側の処理を呼び出す
teeda.ajax	Teeda Ajaxの通信先として指定されるパス
_evalResult	受信した応答を形式に応じて処理する関数
eval('(' + resText + ')')	応答文字列をJavaScriptの式として評価する処理

まんだらけのカート用コードでは、executeCartTeedaAjaxWrapperが通信先をekizo.mandarake.co.jp/cart/teeda.ajaxとして組み立て、商品IDや数量などを渡す構成になっていました。まんだらけ側のajax.jsにはwithCredentials = trueの設定もあり、別ホストへの通信でCookieなどの資格情報を扱う設計が読み取れます。この設定自体が脆弱性を意味するわけではありません。

両社のファイルには、日時文字列の生成方法、資格情報の扱い、通信完了処理などに違いがあり、同系統のライブラリであっても完全に同一のコードではありません。

診断では応答生成から実行までの経路を確認

脆弱性診断では、「外部入力→サーバー側での応答生成→_evalResult→eval」というデータの流れを確認します。攻撃者が変更できる値が応答に含まれるか、その値が安全に文字列として処理されるか、該当する応答評価が実際に呼ばれるかが判断のポイントです。

改修では、応答を厳密なJSON形式に統一し、互換性を検証したうえでJSON.parseによる解析へ移行する方法が考えられます。これにより、応答をJavaScriptの式として実行する処理をなくせます。

なお、タイムズではHTMLの記載順に各スクリプトが正常実行されると、先行するajax.jsがKumuを定義するため、後続のkumu.jsの初期化ブロックはスキップされます。今回取り上げたevalは、そのブロックとは別にajax.jsに定義された処理です。

今回の調査では、サーバー側のTeedaの正確なバージョンや、攻撃者が応答にコードを混入してevalへ到達させる経路は特定していません。タイムズの対象ログイン画面では当該関数の呼び出し経路も未確認です。実際に悪用可能な脆弱性であるか、特定のCVEに該当するか、今回の不正アクセスの原因となったかは不明です。

らしんばんではEC-CUBE由来のJavaScriptを確認

らしんばんの通販HTMLは、template/default/js/eccube.jsとjquery.min.jsを参照していました。取得したeccube.jsには、window.eccubeや商品規格・在庫・フォーム送信に関する処理があり、EC-CUBE由来のJavaScriptであることを確認しています。

ただし、本体の世代・バージョンは未特定です。products/detailというURL形式や、_token、product_class_idという項目名だけで4系とは判断できません。ファイルの著作権表記にある年も、システムの更新年や本体バージョンを示すものではありません。

今回の比較では、3社に共通する単一のサーバー側フレームワークは確認できませんでした。共通して確認できたのは、既知脆弱性の対象範囲に入る旧版jQueryのバージョン表記です。

3社のjQuery表記と既知脆弱性の対象範囲

jQueryの公式セキュリティアドバイザリが示す対象範囲は、次のとおりです。[1][2]

1.2.6、1.10.2、3.3.1は、いずれも両方の対象範囲に入ります。これらは、条件によってブラウザーで意図しないコードが実行されるクロスサイトスクリプティング（XSS）につながる問題です。公式情報は、HTMLをサニタイズしていても問題が発生し得ると説明しています。

実際の評価には、攻撃者が制御できる入力が、該当する処理へ届くかの確認が必要です。バージョン文字列の一致だけで、サーバー侵害や個人情報の一括流出まで推定することはできません。

脆弱性の放置が危険なのは、影響を判断しないまま使い続けるため

今回の観察は、Webサイトが正常に表示されていても、利用する部品の安全性を別途評価する必要があることを示しています。「画面が動く」「業務に支障がない」という動作確認では、既知脆弱性への対応状況は分かりません。

一般に、既知脆弱性を把握せずに利用を続ければ、悪用条件が揃っている箇所を修正する機会を失います。現時点では危険な入力経路がなくても、機能追加や画面改修によってデータの流れが変わる可能性があります。影響評価の記録がなければ、過去の「問題なし」という判断が現在も有効か確認できません。

そのため、旧版を見つけた後に必要なのは、利用箇所、実際のファイル内容、既知脆弱性、到達可能な処理、適用済み対策を照合し、更新や緩和策の判断を記録することです。今回の公開ソース調査だけで、各社がこうした管理を怠っていたと判断することはできません。

米国NISTも、パッチ管理を、更新の特定、優先順位付け、取得、適用、適用結果の確認まで含むプロセスと位置付けています。更新作業を事業継続のための予防保守として扱う考え方です。[3]

脆弱性診断で実際の経路を確認し、管理ツールで修正まで追う

公開ソースからのバージョン確認は、調査の入口です。企業が自社環境を評価する際には、部品の棚卸しと、アプリケーションの挙動を確認する診断を組み合わせる必要があります。

たとえば、今回のようなjQueryの問題では、ライブラリを検出するだけでなく、検索結果、会員情報、外部APIの応答などが、どの処理を経てHTMLとして表示されるかを確認します。認証後の画面や複数の操作を要する機能も、権限を持つ運営側が診断範囲に含めることが重要です。診断範囲を整理する際は、脆弱性診断の目的・種類・実施頻度も参考になります。

今回の調査から考えられる、実務上の確認事項は次のとおりです。

製品によって検査対象や得意分野は異なります。脆弱性診断ツールの種類と自動診断・手動診断の違いを踏まえ、自社のWebアプリケーション、サーバー、依存ライブラリのどこまで確認できるかを見極める必要があります。

診断結果を受け取った後の管理も欠かせません。対象資産が多い企業では、担当部門や委託先ごとに対応が分散します。検出結果を資産・責任者と結び付け、修正期限と再確認まで追跡する仕組みが必要です。脆弱性管理ツールの比較と選び方では、検出機能に加え、優先順位付けや対応状況の管理を含めて検討できます。

運用では、すぐに更新できない場合も、理由、暫定対策、残るリスク、次回の見直し日を記録します。更新後は業務機能の動作と問題の解消を確認し、担当者が対応を完了させます。部品を把握し、影響を判断し、修正を確認する一連の作業を継続することが、既知脆弱性を未評価のまま残さないための基盤になります。

出典

脆弱性と管理に関する一次資料

1. jQuery：CVE-2020-11022／GHSA-gxr4-xjj5-5px2
2. jQuery：CVE-2020-11023／GHSA-jpcq-cgw6-v4j6
3. NIST SP 800-40 Rev. 4：Guide to Enterprise Patch Management Planning

独自調査に用いた保存資料

以下は調査対象の代表的な保存URLです。本文の判断は提供された保存ファイルの内容に基づきます。Wayback Machineの再生では、参照ファイルが別の保存日時に切り替わる場合があります。

• タイムズのログインHTML（2026年8月2日・UTC）：HTMLと、提供されたjQuery・ajax.js・kumu.jsの保存ファイルを照合。
• タイムズのajax.js（2026年8月2日・UTC）
• まんだらけの通販HTML（2025年8月7日・UTC）：HTMLと、提供されたjQuery・ajax.jsの保存ファイル、およびカート用コードを照合。
• まんだらけのjQuery（2025年8月8日・UTC）
• らしんばんの通販HTML（2026年8月28日・UTC）：HTMLと、提供されたjQuery・eccube.jsの保存ファイルを照合。両JavaScriptの保存記録は2026年8月29日・UTC。

各社の不正アクセスに関する公表

• パーク24：タイムズカーWebシステムへの不正アクセスに関する第3報（2026年9月29日）
• まんだらけ：不正アクセス関連の告知・サービス案内
• らしんばん：不正アクセスによる個人情報漏えい可能性に関するお知らせ（2026年10月1日）