セキュリティ

早稲田大学不正アクセス：延べ3,342件の対象とパスワード変更、8月の痕跡を遡るログ点検

早稲田大学不正アクセス：延べ3,342件の対象とパスワード変更、8月の痕跡を遡るログ点検

早稲田大学は2026年11月9日、MyWasedaへのログインに使うユーザー情報を管理するシステムに第三者が侵入し、延べ3,342件の情報を取得されたと公表しました。前半では、学生・教職員・卒業生が気になる件数の読み方、やるべきこと、偽の連絡への備えを公式の文言で整理します。後半はPHPで動くシステムの担当者に向けて、8月31日の痕跡と10月のPHP2Shell公開の関係を切り分け、ログが調査の起点まで遡れるかを調べるPythonを実行結果つきで示します。

まとめ：早稲田大学の不正アクセスで判明した延べ3,342件と、今すぐ行う対応

早稲田大学の発表が示した取得件数は、次の2区分です。

区分 件数 取得された項目
教職員（退職者含む）・学生・卒業生等 81件 項目は3パターンに分かれる
職員等のユーザー情報 3,261件 6項目が一体で取得

学生と教職員は、大学から届く個別の案内に沿って、Wasedaメールアドレスのパスワード変更などを済ませてください。卒業生は、MyWasedaをはじめWaseda IDを使うサービスが、安全性を確認できるまで止まっています。

システムの担当者が受け取るべき教訓は別のところにあります。今回の痕跡は8月31日付で、10月21日の修正版公開より51日も前でした。修正版を当てて終わりにせず、ログが残る範囲をすべて調べる。その前提として、2か月前まで遡れるログを持っておく必要があります。

学生・教職員・卒業生が確かめる対象範囲とパスワード変更、偽連絡の見分け方

約3,400件と延べ3,342件の関係、暗号化パスワードを含む3,281件の読み方

発表文の冒頭にある「約3,400件」は概数で、確定した数字は延べ3,342件です。「延べ」なのは、同じ人が複数のメールアドレスを持つ場合があるためで、大学は実人数と一致しないと説明しています。実人数は公表されていません。

81件の内訳は、氏名と資格名が38件、それにWasedaメールアドレスを加えたものが23件、氏名と暗号化されたパスワードが20件です。3,261件のほうは、教職員番号・氏名・Wasedaメールアドレス・所属部署名・資格名・暗号化されたパスワードの6項目が一体で取られました。20件と3,261件を足した3,281件が、パスワードの情報を含む件数になります。

パスワードは「利用者が設定したそのものではなく、暗号化された状態で保存」と説明されています。ただ、方式は書かれていません。可逆な暗号化と元に戻せないハッシュ化では攻撃への強さが大きく違い、その差はハッシュ化と暗号化の違いの解説で確かめられます。

学生・教職員のパスワード変更と、卒業生のWaseda ID停止という案内の違い

対応は立場で分かれます。学生と教職員には、パスワード変更などの必要な対応が個別に案内されています。卒業生はWaseda IDを使うサービスが一時停止中で、例としてWasedaメールと証明書発行が挙げられました。再開の時期は改めて知らせるとされています。

証明書が急ぎで必要な卒業生は、再開を待たずに窓口へ相談するのが現実的でしょう。Wasedaのパスワードを他社のサービスでも使っていた人は、そちらの変更を先に進めてください。順番はメール、ネット銀行、決済サービスです。メールが先なのは、他社の再設定の連絡がメールで届くためです。使い回しが狙われる手口はパスワードリスト攻撃の仕組みと検知にまとめました。

入試志願者とオープンカレッジ受講生の現状、「未確認」と「影響なし」の差

入試志願者とオープンカレッジ受講生の情報について、大学は「影響は現時点で確認されていません」と書いています。「影響がない」と断定した表現ではありません。

同じように、公表された2区分以外の情報も、取得の事実は確認されていないものの「可能性を否定できない」として調査が続いています。受験生や受講生は、現時点で特別な手続きを求められてはいません。大学は新たに公表すべき事実が判明すれば調査の完了を待たずに知らせるとしているので、続報を見てください。

大学を装うメール・SMSの判断基準と、ITヘルプデスクの受付時間・連絡先

大学は、本学や関係者を装った不審なメールやSMSが届く可能性を警告しました。心当たりのない連絡のリンクを開かない、添付を開かない、IDやパスワードを入力しない、の3点です。氏名や所属部署名まで正しく書かれていても、本物の証拠にはなりません。それらは取得された項目そのものだからです。偽サイトへ誘導する流れはフィッシング詐欺の成立の仕組みで解説しています。

問い合わせ先は、卒業生も含めてITヘルプデスクです。電話は0120-200-042、受付は平日9時から17時で日本語のみ。フォームのURLは発表文の末尾に載っています。

8月31日の侵入痕跡と10月21日のPHP2Shell公開を時系列で切り分ける根拠

公式発表と外部情報を並べた2026年8月19日から11月9日までの時系列

「PHPの脆弱性で侵入された」と受け取られやすい事案なので、日付を並べて確かめます。

日付 出来事 出典
8月19日 研究者が最初の脆弱性を発見 Wiz
8月24日 PHPのチームへ報告 Wiz
8月31日 早大で不正アクセスの痕跡 早稲田大学
10月17日 公表前の攻撃試行を観測 AWS
10月21日 修正版の公開と脆弱性の公表 PHP
10月22日 早大がアクセス制限を開始 早稲田大学
11月9日 早大が不正アクセスを公表 早稲田大学

出典は、発見と報告の日付がWiz Researchのブログ、10月17日がAWSのセキュリティブログです。修正の内容はPHP公式のGHSA-w8hw-w9fx-j79wとGHSA-6wmf-4rv5-p3rpにあります。

発表文の「PHPの脆弱性」にCVE番号がなく、侵入経路も調査中である点

大学の発表は「PHPの脆弱性への対応を契機として本学システムの状況を確認する中で」痕跡を見つけた、と書いています。脆弱性の名前もCVE番号もありません。侵入経路は、セキュリティ専門事業者と連携して調査中です。

手がかりは10月22日付の告知です。「PHPに関する脆弱性への対応」としてMyWasedaやPHPで稼働する各種システムのアクセスを制限しており、修正版公開の翌日にあたります。PHP2Shellへの対応と読むのが自然ですが、これは日付からの推定で、大学が明言したものではありません。

最も早い公開観測より47日前という間隔から、言えることと言えないこと

8月31日は、AWSが試行を観測した10月17日の47日前、修正版公開の51日前です。筆者が確認できた公開情報の範囲では、この時期にPHP2Shellが悪用されたという報告は見当たりません。

だからといって「PHP2Shellは無関係」とも言えません。発見者がPHPのチームへ報告したのは8月24日で、8月31日より前に別の誰かが同じ欠陥を知っていた可能性は、公開情報だけでは否定できないためです。別の脆弱性や、盗まれた認証情報による侵入も考えられます。結論は1つ。経路が公表されるまで、原因は不明として扱うべきです。

実務で重いのは原因の特定よりも、点検のきっかけと侵入の時期が2か月近く離れていた事実のほうです。

修正版の適用後に行う遡及点検と、調査の起点を公表日より前に置く手順

更新前に証拠を取るCISA BOD 26-04の手順と、48〜72時間の判断枠

米CISAのBOD 26-04の実施ガイダンスは、フォレンジック調査が必要とされた脆弱性の進め方を時間枠つきで示しています。最初の2時間で影響範囲を特定し、2〜24時間で証拠を保全して更新を当て、24〜48時間で分析、48〜72時間で上位へ上げるかを判断する流れです。

順序の要点は、更新や遮断の前に揮発性のデータと証拠を集めること。同ガイダンスには「時期尚早な封じ込めは重要な証拠を破壊しうる」とあります。米連邦機関向けの文書で時間枠も必須ではないとされていますが、順序はそのまま民間のサーバーに当てはまります。

起点は公表日にしない、痕跡が見つかるたびに調査範囲を広げる進め方

PHP2Shellに固有の手がかりと、10月17日以降のログを見直す手順はPHP2Shellの影響範囲と修正版の解説にまとめています。ただ、8月31日はその窓の47日前です。脆弱性の観測日で窓を固定すると、早稲田大学で見つかったような痕跡は対象から外れます。

進め方は次の順にします。

  1. 残っているログの全期間を対象にする
  2. 外部公開のサーバーから順に痕跡を探す
  3. 見つかった日付の前後へ、対象システムを広げる
  4. 認証情報を持つシステムへ必ず範囲を伸ばす

大学の発表にも「調査範囲を広げた結果」個人情報を管理するシステムへの侵入を確認した、とあります。最初に痕跡が出た場所と、情報を取られた場所は同じとは限りません。ログの見方そのものは不正アクセスの調べ方とログの確認手順が基礎になります。

Debian既定のrotate 14では52日前の8月31日に届かないログ保存の落とし穴

遡る範囲を決めるのは、結局ログの保存期間です。Debianのapache2パッケージのlogrotate設定は daily と rotate 14 で、手を入れなければ2週間ほどでローテーションから外れて消えます。仮に10月22日に点検を始めたとすると、8月31日は52日前。既定のままなら、その日のアクセスログはとうにありません。早稲田大学の保存設定は公表されておらず、これは一般のサーバーの話です。

保存期間の下限は、90日を目安にしてください。今回の痕跡から公表までの70日に、調査の時間を足すと60日では足りないからです。サーバー上の設定は次のコマンドで見られます。パスはディストリビューションに合わせて読み替えます。

grep -E 'daily|weekly|rotate' /etc/logrotate.d/apache2 /etc/logrotate.d/nginx

別ホストやオブジェクトストレージへの転送も、同じ設定の見直しで入れておきます。侵入者は手元のログを消せるためです。

ログの保存範囲と初出POSTを調べるPython、更新ファイルを洗い出すfind

調査の起点に届くかを終了コードで返すPythonスクリプトと実行結果

次のスクリプトは、アクセスログの最古の日付、抜けている日、調査の起点まで届くかを判定し、平常期間の後に初めてPOSTされた .php を一覧にします。標準ライブラリだけで動き、--logs を省いた場合は内蔵の検証ログで試せる仕様です。Combined形式のログを想定しています。

# アクセスログが調査の起点まで遡れるかを調べ、初めてPOSTされた.phpを一覧にする
# Python 3.9以上・標準ライブラリのみ。--logsを省くと内蔵の検証ログで動く
import argparse
import gzip
import re
import sys
from datetime import date, datetime, timedelta
from pathlib import Path

LINE = re.compile(r'\[(\d{2}/\w{3}/\d{4}):[^\]]*\] "(\w+) ([^ ?"]+)[^"]*" (\d{3})')


def read_logs(directory):
    for path in sorted(Path(directory).glob("access.log*")):
        opener = gzip.open if path.suffix == ".gz" else open
        with opener(path, "rt", encoding="utf-8", errors="replace") as f:
            yield from f


def sample_logs():
    day = date(2026, 8, 25)
    while day <= date(2026, 11, 9):
        # 9月12日から14日はローテーションの失敗でログが無い想定
        if not date(2026, 9, 12) <= day <= date(2026, 9, 14):
            stamp = day.strftime("%d/%b/%Y")
            yield f'198.51.100.7 - - [{stamp}:10:00:00 +0900] "POST /login.php HTTP/1.1" 200 512'
            if day == date(2026, 8, 31):
                yield f'203.0.113.9 - - [{stamp}:03:12:00 +0900] "POST /upload/a1.php HTTP/1.1" 200 64'
        day += timedelta(days=1)


def analyze(lines):
    days, first_post = set(), {}
    for line in lines:
        m = LINE.search(line)
        if not m:
            continue
        day = datetime.strptime(m[1], "%d/%b/%Y").date()
        days.add(day)
        if m[2] == "POST" and m[3].endswith(".php") and m[4].startswith("2"):
            first_post[m[3]] = min(day, first_post.get(m[3], day))
    return days, first_post


def main():
    parser = argparse.ArgumentParser()
    parser.add_argument("--logs", help="access.log* を置いたディレクトリ")
    parser.add_argument("--since", default="2026-08-31", help="調査の起点日")
    parser.add_argument("--baseline-days", type=int, default=3, help="平常とみなす先頭の日数")
    args = parser.parse_args()

    since = date.fromisoformat(args.since)
    days, first_post = analyze(read_logs(args.logs) if args.logs else sample_logs())
    if not days:
        sys.exit("ログを読み取れません")

    oldest, newest = min(days), max(days)
    span = (newest - oldest).days + 1
    missing = [oldest + timedelta(n) for n in range(span) if oldest + timedelta(n) not in days]
    reachable = oldest <= since
    baseline_end = oldest + timedelta(args.baseline_days)
    new_paths = sorted((d, p) for p, d in first_post.items() if d >= baseline_end)

    print(f"保存範囲: {oldest} から {newest}")
    print(f"欠落日: {len(missing)} 日 {[str(d) for d in missing[:5]]}")
    print(f"起点 {since} まで: {'届く' if reachable else '届かない（この期間は判定不能）'}")
    print("平常期間の後に初めてPOSTされた.php:")
    for day, path in new_paths:
        print(f"  {day} {path}")
    sys.exit(0 if reachable and not missing and not new_paths else 1)


if __name__ == "__main__":
    main()

Python 3.14.10（Windows）で2026年11月10日に実行した結果です。ログの日付も a1.php も内蔵の検証データで、早稲田大学のシステムを調べたものではありません。

保存範囲: 2026-08-25 から 2026-11-09
欠落日: 3 日 ['2026-09-12', '2026-09-13', '2026-09-14']
起点 2026-08-31 まで: 届く
平常期間の後に初めてPOSTされた.php:
  2026-08-31 /upload/a1.php

終了コードは1です。--since 2026-08-20 で試すと「届かない（この期間は判定不能）」に変わりました。ここで見るべきは「判定不能」の扱いです。ログが無い期間は安全なのではなく、何も言えません。一覧に出たパスも侵害の証拠ではなく、人が中身を確かめる候補です。PHP2Shellのようにアプリより下の層で起こる攻撃は、このPOSTの一覧だけでは捕まえられません。

8月25日以降に更新された.phpを一覧にするfindと、時刻偽装の限界

ログと併せて、公開ディレクトリのファイルも見ます。次のコマンドは、指定日より後に更新された .php を日付つきで出します。

find /var/www -type f -name '*.php' -newermt '2026-08-25' -printf '%TY-%Tm-%Td %p\n'

Git Bash のGNU findで、8月1日の .php、8月31日の .php、9月2日の .txt を置いて試すと、8月31日の .php だけが表示されました。デプロイの記録と突き合わせ、説明のつかないファイルを残します。更新時刻は攻撃者が書き換えられるので、一覧に出ないことは安全の証明になりません。消す前に複製を取ることも忘れずに。

認証情報が取られた前提のアカウント点検と、第三者の診断を入れる判断基準

アカウント区分ごとのハッシュ方式を集計するSQLとOWASPの基準値

今回の対象には「暗号化されたパスワード」が含まれました。同じ事態が自社で起きたとき、方式を即答できるかが初動を左右します。次のSQLは、アカウントの区分と状態ごとにハッシュ方式の件数を出します。列名は自社の表に読み替えてください。

SELECT account_type, status,
       CASE
         WHEN password_hash LIKE '$argon2id$%' THEN 'argon2id'
         WHEN password_hash LIKE '$2_$%' THEN 'bcrypt'
         WHEN length(password_hash) = 32 THEN '無塩ハッシュの疑い'
         ELSE '要確認'
       END AS scheme,
       COUNT(*) AS accounts
FROM accounts
GROUP BY account_type, status, scheme
ORDER BY account_type, status, scheme;

6行の検証データをSQLiteで実行した結果を、列をそろえて示します。

alumni   active   無塩ハッシュの疑い  2
faculty  active   argon2id           1
faculty  retired  bcrypt             1
staff    active   bcrypt             1
student  active   argon2id           1

基準はOWASP Password Storage Cheat Sheetに従います。Argon2idの最低設定の一つはメモリ19MiB、反復2回、並列度1、bcryptのコストは10以上です。MD5のような古い方式は、現在のパスワードを失効させて入れ直してもらう方法が同じ文書に示されています。移行のコードはbcryptのコスト係数とArgon2idへの移行で扱いました。上の結果なら、最初に手を付けるのは alumni の2行です。

退職者と卒業生のアカウントを区分単位で止める設計と、全件失効の実装順

大学の発表では、対象に退職者も卒業生も含まれ、卒業生向けはサービスごと止める措置が取られました。自社の認証基盤でも、利用者の区分ごとに停止と再開を切り替えられるかを確かめてください。区分の列がなく、全員を一括でしか止められない設計だと、在籍者の業務まで道連れになります。

状態が retired の行にパスワードのハッシュが残っていないかは、上の集計で分かります。検証データの faculty の1行がその例で、退職後も認証情報を持ち続ける理由があるかを問う材料になるでしょう。全件のパスワード無効化と再設定の流れはSONICWIREの全会員パスワード無効化の実装に、APIトークンの失効はAPI不正アクセス対策の実装手順に分けて書いています。パスワードの変更だけでは発行済みのセッションが残るため、両方を同じ手順書に入れます。

1,000人以下でも報告対象になる不正目的の類型と、確報60日の期限

個人情報保護委員会の案内では、不正の目的をもって行われたおそれがある行為による漏えい等に、人数の要件は書かれていません。「不正の目的」の主体には第三者も含まれます。速報は発覚日から3〜5日以内、確報は30日以内で、不正な目的のおそれがあれば60日以内です。

侵入が2か月前でも、期限の起算は発覚日です。ログが足りないと、確報に必要な影響範囲を書けないまま期限が来ます。大学の発表は「関係機関への報告・相談」とのみ記し、発覚の日付は書いていません。実務の流れは個人情報保護委員会への報告義務の実務をご覧ください。

自社の点検で済む範囲と、第三者の診断やフォレンジックへ切り替える条件

公開サイトが1台で個人情報を持たず、ログが起点まで揃っていて一覧に説明のつかないものが無いなら、本記事のスクリプトとfindで一次の点検は足ります。

次のどれかに当たるなら、自社だけで結論を出さないでください。

  • ログが起点に届かない、または欠落日がある
  • 認証情報や会員情報を持つサーバーで説明のつかないファイルが出た
  • パスワードの保存方式を説明できない
  • 委託先の作ったPHPシステムを誰も把握していない

侵入の痕跡が実際に見つかった場合は、ファイルを消す前にフォレンジック調査の流れと調査会社の選び方を確認し、保全を先に行います。痕跡は無いが外部公開のPHPや認証まわりの弱点を第三者に洗い出してほしい場合は、脆弱性診断・セキュリティ診断でご相談いただけます。

よくある質問

早稲田大学の不正アクセスについて、関係者から出やすい質問をまとめました。内容は2026年11月9日の公式発表に基づきます。

早稲田大学の不正アクセスで自分の情報が取られたかはどう確かめますか？

発表文に、自分で照会するページの案内はありません。学生と教職員には必要な対応が個別に案内されており、必要に応じて対象者へ個別に連絡する場合があるとも書かれています。案内が見当たらないときは、ITヘルプデスクの電話（0120-200-042、平日9時から17時）か、発表文に載っているフォームで尋ねてください。届いたメールのリンクではなく、大学の公式サイトから窓口をたどるほうが安全です。

卒業生がWasedaメールや証明書発行を使えないのはなぜですか？

被害防止のため、安全性を確認できるまでMyWasedaをはじめWaseda IDを使うサービスが一時停止されているためです。発表文はWasedaメールと証明書発行を例に挙げています。再開の時期と今後の対応は改めて知らせるとされ、11月9日の時点で日付は示されていません。Wasedaメールを他のサービスの登録先にしている人は、再設定の連絡を受け取れない点に注意し、登録先の変更を検討してください。

パスワードは暗号化されていたのに変更する必要はありますか？

大学が個別に案内している以上、案内に従って変更してください。発表文は暗号化の方式を明らかにしておらず、取得された情報がどの程度解読しにくいかは外部から判断できません。同じパスワードを他社のサービスで使っているなら、そちらも別の文字列に変えます。これは個別の案内の有無にかかわらず、今回の件を機に済ませておきたい作業です。多要素認証の設定についても、問い合わせ先はITヘルプデスクです。

今回の不正アクセスの原因はPHP2Shellですか？

公表されていません。大学は「PHPの脆弱性への対応を契機」に痕跡を見つけたと説明しているだけで、脆弱性の名前も書いておらず、侵入経路は調査中です。痕跡の日付である8月31日は、PHP2Shellの修正版公開より51日前で、公開情報で確認できる最初の攻撃試行より47日前にあたります。この間隔だけでは、関係があるとも無いとも断定できません。続報で経路が示されるのを待つ必要があります。

受験生やオープンカレッジの受講生は何かする必要がありますか？

入試志願者とオープンカレッジ受講生の情報は、今回の不正アクセスによる影響が現時点で確認されていません。発表文には、これらの方に個別の手続きを求める記載もないという状況です。ただし調査は続いており、確認されていないことと影響が無いことは同じではありません。大学名を使った不審なメールやSMSには、受験生も同じように注意し、リンクや添付を開かず、公式サイトで情報を確かめてください。

関連記事

お気に入りに入れた記事の一覧

一創の公式 SNS

X では毎朝の新着記事と IT ニュースの速報を、YouTube・TikTok・Instagram・LinkedIn・Facebook では記事の解説動画を配信しています。

この記事に関連するサービス

資料請求

今日のトレンド記事 直近 24 時間で、いつもより多く読まれている記事

  1. 2026.11.07　コラム サイバーセキュリティ緊急対策パッケージとは？4本柱の施策と期限、企業と委託先が今やること
  2. 2025.04.30　テックブログ IMSIキャッチャー（偽基地局）とは？2Gフォールバックの手口と日本での対策
  3. 2026.11.06　テックブログ ドコモ不正アクセスの見舞金・対象確認とMy docomo再開状況：最大29.5万件の流出項目【11月9日第四報】
  4. 2026.11.06　テックブログ あいおいニッセイ同和の不正アクセス：44.4万件の漏えい項目と窓口、止まった手続きの代わり
  5. 2026.11.06　テックブログ TeamSpirit不正アクセス：28,824件流出の原因と利用企業の確認点、開発用サーバーの認証情報を守る実装

RELATED POSTS 関連記事

一覧へ戻る

目次