学研グループの株式会社学研メディカルサポート、管理する78サイトがWordPressの脆弱性を突かれ不正アクセス — バージョンアップ実施予定の直前だった
| 項目 | 内容 |
|---|---|
| 発生日 | 2026年8月3日午前に不正アクセスを検知。侵入の開始時期は公表されていない |
| 公表日 | 2026年8月4日（報道は2026年8月24日） |
| 対象組織・業界 | 株式会社学研メディカルサポート（学研グループ。e-ラーニングサービス、DX支援、研修制作・運営支援／情報通信・IT） |
| 影響件数 | 公表されていない。対象はWeb制作事業部が管理する78サイト（いずれもバージョンアップを実施予定であったもの）。現時点で流出や不正利用は確認されていない |
| 攻撃手法 | WordPressの脆弱性を悪用した不正アクセス。WordPress内での不正なアカウント生成と、既存アカウントのパスワード書き換えが行われた |
| 情報源 | 学研メディカルサポート「弊社Web制作事業部が管理するWebサイト（WordPress）への不正アクセス発生について」（2026年8月4日）、ScanNetSecurity（2026年8月24日） |
e-ラーニングサービスやDX支援、研修の制作・運営支援を手がける株式会社学研メディカルサポート（学研グループ）は2026年8月4日、同社Web制作事業部が管理するWebサイトがWordPressの脆弱性を悪用した不正アクセスを受けたと公表しました。
対象となったのは、バージョンアップを実施予定であった78サイトです。攻撃者によって行われたのは、WordPress内での不正なアカウント生成と、既存アカウントのパスワードの書き換えでした。
検知は2026年8月3日午前です。同社は同日15時30分にWordPress管理画面への認証強化を完了し、21時に緊急アップデートとアカウント情報の復旧を完了しています。検知から復旧までが同じ日のうちに収まっています。
現時点で、各Webサイトでの閲覧障害や、個人情報・問い合わせ情報の流出は確認されていないとしています。サイトの管理者に対しては個別に通知を行うとし、継続して監視するとしています。
- 侵入の開始時期: 公表されていない
- 2026年8月3日午前: Web制作事業部が管理するWebサイトへの不正アクセスを検知
- 2026年8月3日15時30分: WordPress管理画面への認証強化を完了
- 2026年8月3日21時: WordPressの緊急アップデートおよびアカウント情報の復旧を完了
- 2026年8月4日: 株式会社学研メディカルサポートが公表。対象サイトの管理者へ個別に通知するとする
- 2026年8月24日: 報道により広く伝えられる
判明している事実: WordPressの脆弱性を悪用した不正アクセスを受けたことです。該当する脆弱性の名称やCVE番号、影響を受けたプラグインやテーマ、侵入の開始時期は公表されていません。
考えられる原因（推測）
Section titled “考えられる原因（推測）”対象が「バージョンアップを実施予定であった78サイト」と説明されている点から、更新が必要だと把握したうえで、着手する前に攻撃を受けたと読めます。脆弱性の公開から更新の完了までの間には、必ず待ち時間が生まれます。その窓が閉じる前に到達されたということになります。
攻撃者が行ったのは、不正なアカウントの生成と既存アカウントのパスワードの書き換えです。いずれも、その場でデータを持ち出すのではなく、後から確実に入り直せる状態を作るための操作です。データの流出が確認されていないことと、侵入の目的が達成されていないことは別で、同社が継続監視を挙げているのはこの点を踏まえたものと考えられます。
組織が学ぶべきこと
Section titled “組織が学ぶべきこと”1. 使っているソフトウェアの脆弱性情報を、自社の資産に突き合わせて追う
Section titled “1. 使っているソフトウェアの脆弱性情報を、自社の資産に突き合わせて追う”破られたのは自社で書いたプログラムではなく、WordPressという外部のソフトウェアです。本体・プラグイン・テーマの脆弱性はほぼ毎月公表されますが、公表を見ただけでは自社が対象かどうか分かりません。どのサイトが何をどの版で動かしているかを一覧にして初めて、公表された脆弱性を自社の話として読めます。自分で作っていないものにこそ、この突き合わせが要ります。
2. 更新が終わるまでの時間を、別の手段で持たせる
Section titled “2. 更新が終わるまでの時間を、別の手段で持たせる”脆弱性の公表から更新の完了までには、検証や利用者への調整のぶんだけ必ず時間がかかります。その間を素通しにしないために、管理画面のアクセス元を制限する、多要素認証を入れる、といった入口側の対策を先に打てます。同社が8月3日15時30分に管理画面の認証強化を済ませ、緊急アップデートを21時に完了させた順序は、この考え方に沿ったものです。
3. サイトを預ける側と預かる側で、更新の責任範囲を決めておく
Section titled “3. サイトを預ける側と預かる側で、更新の責任範囲を決めておく”今回侵害されたのは制作事業部が管理する78サイトで、運営しているのはそれぞれ別の組織です。制作を委託した側から見ると、自社のサイトの安全は委託先の更新作業に左右されます。誰が本体とプラグインを更新するのか、緊急の脆弱性が出たときは何時間以内に着手するのか、障害時の連絡はどこへ来るのか。ここを契約や運用の取り決めに書いていないと、公表を読んで初めて自社が当事者だと知ることになります。
ヤグラの視点 — 復旧可能性という指標：自分で書いていないソフトウェアを、どこまで把握できているか
Section titled “ヤグラの視点 — 復旧可能性という指標：自分で書いていないソフトウェアを、どこまで把握できているか”検知が8月3日の午前、管理画面の認証強化が15時30分、緊急アップデートと復旧が21時。同じ日のうちに封じ込めから復旧までが終わっています。WordPressを狙った侵害で、サイトの停止も再構築も伴わずにこの速さで収まる例は多くありません。
同社が影響範囲を「バージョンアップを実施予定であった78サイト」と表現できたことに、この速さの理由があります。侵害が判明した時点で、どのサイトが対象かを数え直す必要がなかったということです。普段の更新管理のために持っていた一覧が、そのまま緊急時の対象リストとして働いたわけです。自社で作っていないソフトウェアの棚卸しは、脆弱性を塞ぐための作業として語られがちですが、破られた後にどれだけ早く戻せるかも、同じ一覧に支えられます。
この把握は、一度作れば終わるものではありません。プラグインは追加され、テーマは差し替えられ、制作したサイトは納品後も動き続けます。一覧を更新し続ける担当を決めることと、更新が滞っているものを定期的に拾い上げることが、そのまま脆弱性への備えになります。それでも、把握しきれなかったところから入られる場合は残ります。そのとき手がかりになるのが、今回不正に行われた管理者アカウントの生成とパスワードの書き換えという痕跡です。どちらも記録に残り、通常の運用ではまず起きない操作なので、変更が起きた時点で拾えるようにしておけば、次も同じ日のうちに閉じられます（→ ヤグラ AI SOC）。
- 悪用された脆弱性の内容と、侵入の開始時期
- 78サイトそれぞれでの被害の有無と、サイト運営者への通知の結果
- 個人情報・問い合わせ情報の流出の有無についての最終的な確認
- 再発防止策の公表内容
判明次第、本記事に追記します。
| 日時 | 内容 |
|---|---|
| 2026-08-24 | 2026年8月4日の公表内容および2026年8月24日の報道をもとに記事を公開 |