株式会社教育ソフトウェア、2016年に使用を終えた休眠サーバーがランサムウェア被害 — レンタルサーバー会社の通報で判明、4,627件が対象

項目	内容
発生日	2026年4月30日から5月1日にかけて不正アクセス。対象サーバーは2016年までに使用を終えていた
公表日	2026年8月17日（報道は2026年8月24日）
対象組織・業界	株式会社教育ソフトウェア（デジタル採点、CBT・IBT、教学マネジメント、BPO、入試採点サポート、マークシート・OMR機器／情報通信・IT）
影響件数	4,627件。顧客情報、所属大学名、氏名、学籍番号の一部等。クレジットカード情報は保有しておらず対象外
攻撃手法	長期間使用していないレンタルサーバーへの不正アクセス。ランサムウェアによる暗号化の被害と、第三者の不正アクセスの痕跡が確認された。過去に送受信したメール等が閲覧された可能性がある
情報源	株式会社教育ソフトウェア「長期間使用していないサーバーへの不正アクセスによる個人情報漏えいのお詫びとお知らせ」（2026年8月17日）、サイバーセキュリティ.com（2026年8月24日）、Security NEXT（2026年8月24日）

概要

デジタル採点やマークシート機器を手がける株式会社教育ソフトウェアは2026年8月17日、長期間使用していないレンタルサーバーが第三者による不正アクセスを受け、ランサムウェアによる暗号化被害が発生したと公表しました。

対象となったサーバーは、2016年までに使用されていた「自己採点システム」のもので、その後は休眠状態でした。不正アクセスがあったのは2026年4月30日から5月1日にかけてです。発覚したのは自社の監視ではなく、レンタルサーバー会社からの通報でした。

外部調査機関による調査で、ランサムウェアによる暗号化の被害と第三者の不正アクセスの痕跡が確認されています。サーバー内に残っていた顧客やお取引先と過去に送受信したメール等が閲覧された可能性があり、対象は4,627件です。含まれる情報は顧客情報、所属大学名、氏名、学籍番号の一部等で、対象となるのは2016年までにこのサーバーの自己採点システムを利用した人です。クレジットカード情報は保有していないため対象外としています。

調査の結果、情報漏えいの事実は確認されておらず、二次被害の発生も確認されていないとしています。同社は当該サーバーを廃止し、セキュリティアップデートの定期的な監査と監視体制の強化を挙げています。

経緯

• 2016年まで: 当該レンタルサーバーで「自己採点システム」を運用。その後は使用を終え、休眠状態となる
• 2026年4月30日〜5月1日: 当該サーバーへの不正アクセス。ランサムウェアによる暗号化被害が発生
• その後: レンタルサーバー会社からの通報を受けて調査を開始
• 調査: 外部調査機関により、暗号化の被害と不正アクセスの痕跡を確認。過去のメール等が閲覧された可能性を確認。情報漏えいの事実は確認されず
• 2026年8月17日: 株式会社教育ソフトウェアが公表。当該サーバーを廃止
• 2026年8月24日: 報道により広く伝えられる

原因

判明している事実: 使用を終えて休眠状態にあったレンタルサーバーが不正アクセスを受け、ランサムウェアで暗号化されたことです。侵入経路、悪用された脆弱性、レンタルサーバー会社が異常を把握した経緯は、いずれも公表されていません。

考えられる原因（推測）

10年前に役目を終えたサーバーが、2026年の時点でまだインターネットから到達できる状態にあったことになります。使用をやめた時点で契約と設定が残り、その後は誰も触らないまま動き続けていたと読めます。セキュリティアップデートの定期監査を再発防止策に挙げているのは、更新の対象からこのサーバーが外れていたためと考えられます。

対象が「過去に送受信したメール等」とされている点も、休眠サーバーの性格を表しています。サービスを止めても、その上で動いていたメールや業務のやりとりはそのまま残ります。件数の4,627件が2016年までの利用者を指しているのは、当時のデータが削除されずに置かれていたということです。

発覚がレンタルサーバー会社からの通報だったことについて、同社側でどのような監視を行っていたかは公表されていません。

対策

組織が学ぶべきこと

1. サービスを止めるときに、サーバーの契約と設定まで止める

サービスの終了は「使わなくなる」という業務上の判断ですが、サーバーの契約、公開設定、ドメインの向き先は、判断とは別に手を動かして止める必要があります。止め忘れたものは、更新も監視もされないまま外部から到達できる状態で残ります。終了の手続きに「契約の解約」と「データの削除」を項目として入れておかないと、10年単位で残ります。

2. 使っていないシステムのデータを、先に消す

今回対象になったのは、2016年までの利用者の情報と、当時のメールのやりとりです。サービスを止めた時点でデータを消していれば、10年後に侵害されても失うものはありませんでした。すぐに消せない事情があるなら、どこに何が残っているかを一覧にして、消せる時期を決めておく。残す判断と、残っていることを忘れる状態は別のものです。

3. 外部から知らされる前に気づける範囲を決めておく

本件の発覚はレンタルサーバー会社からの通報でした。外部からの通報は、そのサービスの提供者が異常に気づいた場合にしか届きません。自社が管理しているつもりのないサーバーは、通報も来ない可能性があります。監視の対象に何が入っていて何が入っていないのかを一覧で答えられるようにしておく必要があります。

ヤグラの視点 — 発見までの時間：10年前に止めたシステムが、まだ動いていた

不正アクセスがあったのは2026年4月30日から5月1日、公表は8月17日です。あいだの3か月半は、通報を受けてからの調査に費やされたものと考えられます。目を引くのは、この3か月半よりも、その前の10年です。2016年までに使用を終えたサーバーが、2026年になっても稼働し、当時のメールとデータを抱えたまま外部から到達できる状態にありました。

攻撃者からすれば、こうしたサーバーは狙いやすい対象です。更新されていないので既知の脆弱性が残っていて、誰も見ていないので侵入しても気づかれません。しかも動いているという事実そのものが、外からは確認できます。使われているかどうかは、外部からは関係ありません。

この形の資産に対して、監視や検知を足しても効きません。そもそも自社の管理台帳に載っていないものは、監視の対象にも入らないからです。効くのは順序が逆で、まず外部から到達できるものを自社の側から数え直し、台帳と突き合わせて「動いているのに誰の持ち物か分からないもの」を洗い出すこと。そのうえで、台帳に載っているものについては、通常ではまず起きない変更——見慣れないアカウントの追加や、休眠中のはずのサーバーからの通信——を拾えるようにしておく（→ ヤグラ AI SOC）。今回のように外部からの通報で初めて知る形にしないためには、この2つを順番に進める必要があります。

今後の対応

本件は原因・影響範囲・対応のいずれも公表され、対象サーバーは廃止されています。追加公表の予定は示されていません。

• 参考: 侵入経路と悪用された脆弱性、レンタルサーバー会社が異常を把握した経緯は公表されていません

更新履歴

日時	内容
2026-08-25	2026年8月17日の公表内容および2026年8月24日の報道をもとに記事を公開