JCEは入口だった——山梨大学59サイト、復旧後のWordPressから見えた「サイト間の境界」

山梨大学のWebサイト改ざんについて、対象となった59サイトを外形から調べた。

最初は「JCEを使っていたサイトはどこだったのか」を探していた。

しかし途中で、それを特定すること自体にはあまり意味がないと思った。

大学の調査では、6月上旬、あるWebサイトで使われていたJoomla拡張機能「JCE」の脆弱性が悪用され、WebShellが設置された。

その後、7月下旬にかけて、そのWebShellを利用して同じレンタルサーバ上の他サイトへ侵害が拡大した可能性が高いとされている。

同じ1台のレンタルサーバ内に59サイトがあり、当初54サイトが閲覧できない状態になった。

7月中旬以降には、不正ユーザーの作成、WebShellなどの不審ファイル、SEOスパム・SEOポイズニングも複数サイトで確認されたという。

さらに大学は7月31日の段階で、

「同一のサーバー上で稼働するほぼ全てのWordPress使用サイトが侵害されています」

と公表している。

つまりJCEが入口だったことは、すでに分かっている。

それより気になったのは、

なぜ一つのWebShellから、59サイト規模の問題になったのか。

だった。

まず、59サイトを外から調べた

今回確認した内容を先にまとめる。観測日は2026年9月17日である。

33という数字は下限だ。

Wayback Machineに保存されていないサイトもあり、保存されていてもトップページHTMLからCMSを判定できないケースがある。

したがって、

59サイト中33サイトだけがWordPressだった

という意味ではない。

今回の方法で、侵害前WordPressだと確認できたのが少なくとも33サイト、という意味だ。

なお、対象サイトの一覧は大学が公開状況一覧として自ら公表しているものであり、本稿のホスト名はそこに記載されたものに限っている。

現在WordPress 7.1で動いている18サイト

9月17日時点で対象59サイトを確認すると、学外から到達でき、WordPress 7.1として識別できるサイトが18あった。

さらに、Wayback Machineに残る侵害前のHTMLと、現在のトップページHTMLから、

/wp-content/uploads/

/wp-content/themes/

/wp-content/plugins/

の公開パスを抽出して比較した。

結果がこれだ。

ここでいう「パス」は、サーバ内のディレクトリを直接見たものではない。

侵害前と現在のトップページHTMLから参照されていたWordPress関連URLを比較したものだ。

したがって、この表から実際のファイルシステムの状態や復旧方法そのものを断定することはできない。

ただ、違いはかなりはっきり出た。

図書館は40本中40本が同じ

最も分かりやすかったのが、山梨大学附属図書館 lib.yamanashi.ac.jp だった。

侵害前のトップページから確認できたWordPress関連パスは40。

現在も40。

そして、

40パスすべてが一致した。

uploads配下でも18パスが一致している。

テーマも、

digital-lib

のまま。

確認できたプラグインも、

contact-form-7

confirm-plus-contact-form-7

smooth-page-scroll-updown-buttons

などが共通していた。

循環器内科 cardiology.med.yamanashi.ac.jp も、侵害前22パスに対して現在26パス。

侵害前の22パスがすべて現在も確認できた。

テーマも understrap-child-main が継続している。

総合分析実験センター clir.yamanashi.ac.jp は57パス中35パスが一致し、テーマ lightning も継続。

臨床教育部 resident.yamanashi.ac.jp も50パス中26パスが一致し、テーマ mistify がそのまま残っている。

少なくとも外から見える範囲では、侵害前のサイト構造をかなり強く維持して現在動いているサイトがある。

一方、かなり変わったサイトもある

逆の例が cacr.yamanashi.ac.jp だった。

侵害前には46あったWordPress関連パスが、現在は6。

一致したのは2つ。

テーマも、

lightning

から、

twentytwentyfive

へ変わった。

同様に、

nanbyousien.yamanashi.ac.jp は27 → 6。

neurol.med.yamanashi.ac.jp は46 → 6。

respiratory.yamanashi.ac.jp は65 → 6。

いずれも現在はWordPress標準テーマの twentytwentyfive が使われている。

ただし、ここを「再構築した」と決めつけるのは違う。

インシデント対応なら、普通はファイルを調べる。

知らないPHPファイルがないか。

改ざんされたファイルがないか。

不要なテーマやプラグインがないか。

使っていないものは削除する。

WebShellや不審ファイルが見つかれば削除する。

その結果として、外から見える /wp-content/ の参照が大きく減ることは十分あり得る。

Twenty Twenty-FiveもWordPressの標準テーマなので、安全確認の過程で一度標準テーマへ戻した可能性もある。

したがって今回言えるのは、

侵害前の構造を強く残しているサイトと、現在の公開構造が大きく変わったサイトの両方がある。

そこまでだ。

WordPress 7.1に上げればWebShellが消えるわけではない

現在確認できた18サイトはWordPress 7.1になっている。

しかし、

CMSを最新にすることと、侵害された環境をクリーンにすることは別だ。

今回入口となったJCEでも同じである。

JCEのCVE-2026-48907は、2.9.99.5で修正された。

JCE公式によると、2.9.99.5より前の全バージョンが影響を受け、未認証ユーザーによるEditor Profileのアップロードから任意ファイルアップロードにつながる問題だった。

2.9.99.6ではアクセス制御やファイル処理など追加のハードニングも行われている。

そしてJCE自身が、重要な注意を書いている。

更新は侵入口を閉じるが、すでに侵害されたサイトをクリーンにはしない。

更新前に攻撃者が置いたものは、アップデートしても自動的には消えない。

これはWordPressでも同じだ。

WebShellがWordPress本体とは別のPHPファイルとして置かれていれば、本体を7.1へ更新しても残り得る。

既存ファイルにコードを埋め込まれていれば、そのファイルをどう扱うかも判断しなければならない。

だから復旧では、

どのファイルを残すか。

何を削除するか。

何をクリーンなものに置き換えるか。

テーマやプラグインをそのまま信用するか。

認証情報をどう変更するか。

そして何を根拠に「再び公開していい」と判断するか。

が重要になる。

大学も、安全性が確認できたWebサイトから順次公開を再開すると説明している。

でも、それだけでは59サイトを説明できない

ここから先は推測になる。

ただ、実務経験から一番気になるのは、

ディレクトリの権限と、実行ユーザーの分離

だ。

WebShellを一つ置かれたからといって、その瞬間に同じサーバ上の全サイトを自由に書き換えられるわけではない。

WebShellも基本的には、それを実行しているOSユーザーが持つ権限の範囲で動く。

例えば、

サイトAを user-a、

サイトBを user-b、

サイトCを user-c

として動かし、それぞれのWebディレクトリの所有者と書き込み権限を分離していれば、サイトAにWebShellを置かれても、サイトBやCを書き換えるためにはもう一つ壁を越える必要がある。

逆に確認したくなるのは、

各サイトが別のOSユーザーで動いていたのか。

複数サイトが同じユーザーで動いていなかったか。

ディレクトリ所有者は分離されていたか。

group writeやACLで、隣のサイトまで書き込める状態ではなかったか。

FTP、SFTP、管理用アカウントを複数サイトで共用していなかったか。

という点だ。

もちろん、今回どれが該当したのかは公開情報からは分からない。

別の認証情報を途中で取得した可能性もある。

権限昇格があった可能性も否定できない。

だから、

「権限設定が原因だった」

とは書けない。

ただし、

JCEの脆弱性だけでは、一つのサイトから同じレンタルサーバ上の他サイトへ侵害が広がった理由までは説明できない。

これは切り分けて考える必要がある。

パッチを当てることと、被害を一サイトで止めることは別

JCEを更新する。

WordPressを最新にする。

不審ファイルを削除する。

認証情報を変更する。

これはもちろん必要だ。

ただ、それらとは別に、

サイトごとにOSユーザーを分ける。

ディレクトリの所有者を分ける。

書き込み権限を分ける。

という設計がある。

目的は単純だ。

一つのサイトを取られても、

そこで止める。

JCEの脆弱性は入口だった。

WebShellが置かれたことも分かっている。

同じレンタルサーバ上の他サイトへ侵害が拡大した可能性が高いことも大学の調査で示されている。

今回、59サイトを外から追ってみると、現在WordPress 7.1で動く18サイトの中にも、侵害前の構造を強く残したサイトと、大きく構造が変わったサイトの両方があった。

復旧方法そのものは外からは分からない。

でも、一つだけ最後まで残る問いがある。

一つのWebサイトに置かれたWebShellが、なぜ別のWebサイトまで触れたのか。

次に同じ入口を一つ突破されたとしても、59サイト規模にしないためには、パッチとは別の対策が必要になる。

サイトごとにユーザーを分ける。

ディレクトリの権限を分ける。

一つの侵害を、一つのサイトで止める。

JCEは入口だった。

59サイト規模の問題にしたのは、その先にあった「サイト間の境界」だったのではないか。

参考

• レンタルサーバ上の Web サイトで学外公開を停止しています（2026-08-05 更新） – 山梨大学 総合情報戦略機構
• 一部ホームページの公開停止に関するお知らせ（続報） | 山梨大学
• レンタルサーバ対象Webサイトの公開状況一覧 – 山梨大学 総合情報戦略機構
• 54サイトが閲覧不可に ～ 山梨大学が契約しているレンタルサーバでのWebサイト改ざん | ScanNetSecurity