ウィキペディア、管理者アカウントの大量流出で読み取り専用モードに切り替わるも復旧

 (wikimediastatus.net)
1 ポイント 投稿者 GN⁺ 2026-03-06 | 1件のコメント | WhatsAppで共有
  • ウィキメディア財団のステータスページによると、2026年3月5日にウィキペディアを含む複数のウィキサービスが一時的に読み取り専用モードに切り替わった
  • ウィキへのアクセス障害から始まり、その後編集機能が制限される段階へと進んだ
  • 原因は明示されていないが、問題の特定後に修正作業が進められ、一部機能は依然として無効化された状態だった
  • 3月6日には読み書き機能が復旧し、ほとんどのユーザースクリプト機能も再び有効化された
  • ウィキメディアはその後も継続的なモニタリングを通じて安定性の確認を進めている

ウィキメディアのシステム状態概要

  • ステータスページでは**すべてのシステムが正常稼働中(All Systems Operational)**と表示されている
    • 読み取り、編集機能はいずれもOperationalと表記
    • 1秒あたりのリクエスト数131,002件、ユーザー報告の接続エラー0.08件、ウィキのエラー応答1.27件、平均応答時間0.20秒、成功した編集11.4件と記録されている

2026年3月5〜6日のウィキ読み取り専用モード事案

  • 3月5日15:36 UTCから一部ウィキへのアクセス問題が報告された
    • 16:11 UTCに問題を認識し、修正作業が開始された
    • 17:09 UTCには問題の原因を特定し修正を進行中と表示
    • 17:36 UTCには読み書きモードが復旧したが、一部機能は依然として無効化された状態
    • 18:36 UTCには修正完了後のモニタリング段階へ移行
  • 3月6日00:05 UTCには継続モニタリング中と報告された
    • その後、「ウィキは数時間にわたり読み書きモードを維持し、ほとんどのユーザースクリプト機能が復元された」として事案は**解決済み(Resolved)**となった

2026年3月初旬のその他の関連事案

  • 3月3日にはデータベースサーバーの問題で編集遅延が発生したが、同日中に解決した
    • 10:09 UTCに問題を特定、10:17 UTCに修正完了後モニタリング、10:24 UTCに正常化
  • 2月25〜26日にはウィキアクセスのパフォーマンス低下が報告され、それぞれ修正後に正常化した
  • 2月20日には欧州地域での接続遅延が発生し、原因特定後の修正とモニタリングを経て解決した

購読と通知機能

  • ユーザーはメール、Slack、Webhook、Atom/RSSフィードを通じて事案の発生・更新・解決通知を受け取れる
  • メール購読時にはOTP認証とreCAPTCHA保護が適用される
  • Slack購読はAtlassian Cloud利用規約およびプライバシーポリシーに従って運用される

要約

  • ウィキメディアは3月初旬に複数回の編集機能停止とパフォーマンス低下の事案を経験したが、いずれも復旧した
  • 3月5〜6日の読み取り専用モードへの切り替えは最も大きな事案で、修正後にほとんどの機能が正常化した
  • 現在、すべてのシステムは正常稼働状態を維持している

関連記事

1件のコメント

 
GN⁺ 2026-03-06
Hacker Newsの反応

  • 公開されている Phabricatorチケット を見ると、Wikimedia Foundationのあるセキュリティエンジニアがテストのためにランダムなユーザースクリプトを読み込んでいた
    その中の1つが2年前の悪意ある ruwiki スクリプトで、このスクリプトはグローバルJSに自分自身を注入して急速に広がり、被害を引き起こした
    結局、ウィキ全体が読み取り専用モードに切り替えられるほど深刻な事態だった

    • こんなミスをしたのがセキュリティエンジニアだという点が特に衝撃的だ
    • 最初は現在進行中の攻撃者がいるのかと思ったが、過去の悪性スクリプトだと分かってからは解決は簡単になった
      正規表現を使って該当スクリプトを検出し、感染したページを以前のバージョンに戻せばよい
    • これはほとんど Samyワーム のような事例に見える
    • 3億ドル規模の組織がこんなミスをするなんて信じられない
    • 「Claude、お前のスクリプトがマルウェアを実行したぞ！」「はい、すみません！」みたいな会話があったのではと思う

  • このワームの動作方式が興味深い
    MediaWikiのCommon.jsとUser:Common.jsに自分自身を注入してグローバル感染を維持し、jQueryで感染の痕跡を隠す
    20個の無作為な文書を荒らし、管理者アカウントに感染するとSpecial:Nuke機能で文書を削除する

    • 単に「自分がどれだけ混乱を起こせるか見てみろ」という悪ふざけ程度の動機に見える
    • basemetrika.ru ドメインは存在しない。NXDomain応答が返ってくる
    • XSSを試みているように見えるが、実際には効果のないコードなので外部ロードは発生しない
    • こういう精巧なワームはAIが設計した可能性もあると思う

  • データベース自体が感染媒体なので、後片付けはデジタルフォレンジックの悪夢になるだろうという話があった
    ただし root 権限を突破されたわけではなく、バックアップがあれば復旧は可能そうだ

    • 数日分の編集が失われても、Wikipedia全体で見れば耐えられる範囲だ
    • 実際にはDBロールバックではなく、通常のウィキの差し戻しツールで処理され、Wikipedia本体ではなくMetaサイトだけが影響を受けた

  • ロシア語版ウィキコミュニティでの調査によると、2023年にロシア語の代替ウィキ群への荒らし攻撃に使われたコードが今回も使われたようだ
    ruwiki のユーザー Ololoshka562 が作成した test.js がそのスクリプトで、
    WMF のスタッフ sbassett がテスト中にこのスクリプトを読み込んで実行されたとみられる

    • 昨年も ruwiki は似たような方法で大規模な荒らし被害を受けたことがある

  • 古いXSSワームのように見える
    MediaWikiがユーザーにJavaScript挿入を許可する構造は危険だと以前から思っていた

    • 驚くべきなのは、こうしたXSSがまだパスワード窃取のような攻撃に使われていなかった点だ
      この記事 のようにブラウザの自動入力の脆弱性を利用していたら、はるかに深刻だったはずだ

  • Wikipediaに不満があったとしても、今回の件を口実に嫌がらせやストーキングをすることは正当化できない

  • ウィキ編集者の友人の話では、今回の事件は**クロスサイトスクリプティング（XSS）**によるハッキングに見える
    ロシア語版ウィキのユーザーページから始まったコードが Meta の common.js を通じて広がり、
    管理者たちが手動で差し戻していく様子が Recent Changesページ で見えていた

    • 「ロシア発の攻撃」に見えるが、そのように発信元を偽装するのは非常に簡単だ
    • ただ、別のユーザーはこのコードが古いロシア製ハッキングツール「woodpecker」の変種である可能性が高いと見ている

  • 追加の文脈として Wikipediocracyフォーラム、
    Village Pumpの議論、
    Redditメガスレッド などがある
    問題のペイロードは このリンク で確認できる

    • Webアーカイブ版 は安全に見られる
    • 一部のリンクはアクセス権限がなく開けない

  • 実際、こういうことは時間の問題だった
    Wikipediaはセキュリティに対してあまりに甘い姿勢を見せてきた
    「インターフェース管理者」権限さえあればグローバルJS/CSSを修正でき、2FAも最近になってようやく導入された
    しかも多くのユーザーが未検証のユーザースクリプトを使っている
    こうした構造自体がセキュリティ上の悪夢であり、今回の件でユーザースクリプトがグローバルに無効化されたのもそのためだろう

    • 以前にはメインページすら削除されたことがあった (リンク)
    • 現在のインターフェース管理者は約137人で、大半はWikimediaのスタッフなので、それなりに信頼できる人員ではある
    • インターネットがますます敵対的な環境になっていく中で、こうした問題の解決には寄付や技術支援が必要だと感じる
    • ブラウザ拡張機能（TamperMonkeyなど）経由のユーザースクリプトは今も存在するため、完全な遮断は不可能だ
    • 実際、英語版ウィキでは15人のインターフェース管理者しか活動していない (参照)

  • 今ではAIがWikipediaを全部クロールしてしまったので、もう誰もWikipediaを直接使わない、という冗談めいた話も出ている