医療従事者向けeラーニング事業を手がける学研メディカルサポートで、同社Web制作事業部が管理する78サイトのWordPressが不正アクセスを受けたことが公表されました。攻撃者は不正な管理アカウントを作成し、既存アカウントのパスワードを書き換えています。検知は2026年8月3日午前、同日中に追加認証の設定と緊急バージョンアップまで完了しています。
情シスにとっての要点は「学研の話」ではありません。自社にも、情シスが把握していないWordPressサイトが存在していないかという点です。今日やるべきことは1つ、管理者アカウント一覧に見覚えのないユーザーが増えていないかの確認です。
この記事でわかること
- 学研メディカルサポートで何が起きたのか（時系列と確定している事実）
- なぜ78サイトが一斉に侵害されたのか、その構造的な理由
- 「不正アカウント生成」「パスワード書き換え」が示す攻撃の型
- 自社のWordPressで今日確認できる、具体的な点検ポイント
- 参照すべきIPAの公的指針
WordPressは「情シスが知らないところ」で動いている
WordPressとは、専門知識がなくてもWebサイトの記事や画像を更新できるようにするCMS（コンテンツ管理システム）です。オープンソースで無償のため、企業サイトからキャンペーンサイト、採用サイト、製品紹介サイトまで幅広く使われています。W3Techsの調査（2026年8月25日時点）では、全ウェブサイトの40.7％、CMSを利用しているサイトに限れば58.9％がWordPressです。
問題は「うちはWordPressを使っていない」という認識のほうにあります。WordPressは情シスが決裁して導入するものとは限りません。
- 広報・マーケ部門が制作会社に発注したキャンペーンサイト・特設サイト
- 人事部門が採用ブランディングのために立てた採用サイト
- 事業部が製品ごとに作った製品紹介サイト
- 数年前のイベント用に作られ、更新が止まったまま公開され続けているサイト
これらは情シスの資産管理台帳に載っていないことがあります。ドメインだけ情シスが管理し、中身はまったく見ていない、というケースもあります。「使っていない」ではなく「把握していないだけ」を疑うのが、この事案の正しい読み方です。
何が起きたのか
同社の公表内容と報道から確認できる事実を時系列で整理します。
| 日時 | 内容 |
|---|---|
| 2026年8月3日（月）午前 | Web制作事業部が管理するWebサイト（WordPress）への不正アクセスを検知 |
| 2026年8月3日 15:30 | WordPress管理画面を表示するための追加認証を設定 |
| 2026年8月3日 21:00 | WordPressの緊急バージョンアップおよびアカウント情報の復旧を実施 |
| 2026年8月4日 | 同社サイトで事象を公表 |
| 2026年8月24〜25日 | セキュリティ専門媒体が報道 |
被害の内容として公表されているのは次の2点です。
- WordPress内の不正なアカウント生成
- WordPress内の既存アカウントのパスワード書き換え
一方で、同社は「閲覧障害等は確認されておりません」「流出や不正利用は確認されておりません」としています。対象はWordPressのバージョンアップを実施予定であった78サイトで、各サイトの管理者へは個別に連絡したとしています。
なお、原因は「WordPressの脆弱性を狙った不正アクセス」とだけ説明されており、WordPress本体（コア）の脆弱性なのか、プラグインやテーマの脆弱性なのかは公表されていません。CVE番号も示されていないため、本記事でも特定の脆弱性とは結び付けずに扱います。
「バージョンアップ予定だった」という記述をどう読むか
公式発表は対象を「WordPressのバージョンアップを実施予定であった78サイト」と表現しています。ここから読み取れるのは、更新すべきと認識されていたサイト群が、更新の実行前に攻撃を受けたという構図です。
参考までに、WordPress本体は2026年に入ってから7.0（7月7日）、7.0.1（7月13日）、7.0.2（7月27日）と短い間隔で更新され、検知直後の8月6日には7.0.3、8月21日には7.1が公開されています。「まとめて計画的に上げよう」と考えているうちに窓が開いたままになることは、多数のサイトを抱える現場では珍しくありません。
なぜ78サイトが一斉に侵害されたのか
78という数は、1社が自社用に運用するサイト数としては多いものです。公式発表が「Web制作事業部が管理する」サイトとし、「サイト管理者へ個別にご連絡」と書いていることから、制作・運用を受託しているサイトが含まれるとみられます（受託分と自社運用分の内訳は公表されていません）。
ここが情シスにとって最も重要な論点です。自社サイトの制作・保守を外部に委託している場合、自社側では何もしていなくても、委託先の管理環境ごと侵害され得ます。同一の管理基盤・同一のテンプレート・同一のプラグイン構成で多数のサイトを面倒見ている制作会社は珍しくなく、1つの脆弱性がそのまま全サイトに刺さります。攻撃者から見れば、1回の攻撃で数十サイトの管理者権限が取れる効率のよい標的です。
今回、実際に個人情報の流出は確認されていません。しかし仮に管理者権限が長期間握られていれば、フィッシングページの設置、マルウェア配布、SEOスパムの埋め込み、フォーム経由の入力情報の窃取といった二次利用に直結します。自社の看板ドメインが加害インフラに変わるのが、この種の侵害で最も避けたい結末です。
「不正アカウント生成」と「パスワード書き換え」が示すもの
この2つが揃うのは、攻撃者が管理者権限を取得し、その権限を維持しようとしたことを意味します。WordPressに対する攻撃では典型的なパターンです。
- 新規アカウントの作成：正規アカウントを止められても入り直せるようにする、いわゆる裏口の確保。
- 既存アカウントのパスワード書き換え：正規の管理者を締め出す、あるいは乗っ取ったアカウントを継続利用する。
逆に言えば、この痕跡はサイト側から見つけられるということでもあります。バージョンアップだけして安心するのではなく、「入られていた前提」で痕跡を確認することが必要です。
自社のWordPressで今日確認できることは何ですか
管理者アカウントの一覧、ユーザー登録の設定、管理画面の公開範囲の3点です。脆弱性の特定を待たずに確認でき、管理画面にログインできる担当者がいれば数分で終わります。
| 確認項目 | 見る場所・方法 |
|---|---|
| 見覚えのない管理者がいないか | 管理画面「ユーザー」→権限グループ「管理者」で絞り込み。WP-CLIなら wp user list --role=administrator |
| 直近に作られたアカウントがないか | ユーザー一覧を登録日順に確認（覚えのない登録日のユーザーに注意） |
| 誰でも登録できる設定になっていないか | 「設定」→「一般」→「メンバーシップ：だれでもユーザー登録ができるようにする」のチェックと「新規ユーザーのデフォルト権限グループ」（購読者以外になっていないか） |
| 本体・プラグイン・テーマのバージョン | 「ダッシュボード」→「更新」。停止中のプラグインや使っていないテーマもファイルは残っているため、不要なものは削除する |
| 管理画面が全世界に開いていないか | /wp-admin/ と /wp-login.php へのアクセス制限（IP制限・Basic認証・多要素認証）の有無 |
| 身に覚えのないファイル・投稿 | 更新日時の新しいPHPファイル、下書きに紛れたスパム投稿、テーマファイルの改変 |
もし不審な管理者アカウントが見つかった場合は、その場で削除して終わりにせず、いつから存在したのか、その間に何をされたのかをアクセスログで確認してください。削除だけで済ませると、別の裏口が残っている可能性を見落とします。
情シスはどうすべきか
個別の設定手順を自前で積み上げるより、公的機関の指針を起点にするほうが確実です。特に委託先との責任分界を詰める際、公的な文書は共通言語として使えます。
- IPA「安全なウェブサイトの運用管理に向けての20ヶ条」：運用側の視点でチェックポイントが整理されています。今回に直結するのは第4条（CMS等の構成ソフトウェアの脆弱性対策を定期的にしているか）と第9条（OS・サーバソフトウェア・ミドルウェアをバージョンアップしているか）です。委託先へのヒアリング項目としてそのまま流用できます。
- IPAテクニカルウォッチ「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」：CMS特有の脅威と、構築・運用時の勘所がまとまっています。公開は古い資料ですが、管理画面のアクセス制限・プラグインの取捨・更新の運用という論点は今回の事案とそのまま重なります。
- IPA「安全なウェブサイトの作り方」：制作を発注する側が、要件として何を書くべきかを確認する際に。
そのうえで、今回の事案から導ける実務的な打ち手は次の3つです。
- 公開サイトの棚卸し：自社ドメイン配下・サブドメイン・別ドメインを含め、公開中のサイトとその管理主体（社内部署／委託先）、CMSの有無を一覧化する。台帳がないと、そもそも今回のような通知を誰が受け取るのかが決まりません。
- 管理画面を公開しない：更新は原則として認証・IP制限の内側で行う。追加認証（Basic認証・多要素認証）は、どの脆弱性が悪用されたか分からない段階でも侵入の敷居を上げられる数少ない手です。学研メディカルサポートが検知当日に真っ先に打ったのもこの手でした。
- 委託先との合意事項を文書にする：更新の頻度と責任者、緊急時の連絡経路、インシデント時の報告義務。「バージョンアップ予定だった」という状態を、誰がいつ解消するのかを決めておくということです。
あわせて、サイト更新を担当する非IT部門の担当者への啓発も欠かせません。管理画面のパスワードの使い回しをやめる、退職者・異動者のアカウントを残さない、といった基本が守られていないサイトほど、脆弱性以前のところで落ちます。
現場目線の所感
この事案で率直に評価したいのは、初動の速さです。午前に検知して同日15:30に追加認証、21:00に緊急バージョンアップとアカウント復旧、翌日に公表。78サイトを抱えた状態でこのスピードは、実務としてかなり良い部類です。「流出は確認されていない」で終わらせず、実施した対策を時刻付きで書いている点も誠実だと感じます。
同時に、身につまされるのが「バージョンアップを実施予定であった」という一文です。多数のサイトを抱えていると、更新は必ず「まとめてやる作業」になります。テーマやプラグインの互換性確認、表示崩れのチェック、公開時間の調整。全部やろうとすると数十サイト分の段取りが必要で、どうしても後ろ倒しになる。やるべきことは分かっていて、計画もあって、それでも間に合わない——この構図は、限られた人員でシステムを見ている情シスなら心当たりがあるのではないでしょうか。
もう1つ、しんどいのは「自社の外にある弱点」です。委託先の管理環境で起きたことは、自社の情シスからは見えません。監視も入れられなければ、パッチ適用の判断もできない。できるのは、契約と定期的な確認で担保することだけです。地味ですが、棚卸しと委託先ヒアリングという古典的な手段が、結局いちばん効きます。
まとめ
- 学研メディカルサポートのWeb制作事業部が管理する78サイトのWordPressで不正アクセスが発生し、不正アカウントの生成と既存アカウントのパスワード書き換えが確認されました。検知当日に追加認証と緊急バージョンアップを実施し、流出は確認されていません。
- WordPressは情シスの台帳に載らない形で社内に点在しがちです。広報・人事・事業部が発注した特設サイトや、更新の止まった旧サイトを含め、まず公開サイトの棚卸しから始めてください。
- 今日できるのは管理者アカウント一覧の確認と管理画面へのアクセス制限です。委託先に任せているサイトについては、更新の責任者と緊急時の連絡経路を文書で確認しておきましょう。
出典
- 株式会社学研メディカルサポート「弊社Web制作事業部が管理するWebサイト（WordPress）への不正アクセス発生について」（2026年8月4日）
- Security NEXT「複数管理サイトに不正アクセス、CMSに脆弱性 – 学研Meds」（2026年8月25日）
- IPA「安全なウェブサイトの運用管理に向けての20ヶ条 〜セキュリティ対策のチェックポイント〜」
- IPAテクニカルウォッチ「CMSを用いたウェブサイトにおける情報セキュリティ対策のポイント」
- WordPress.org「リリースアーカイブ」
- W3Techs「Usage statistics of WordPress」（2026年8月25日時点）
