管理者アカウントの大規模な侵害により、ウィキペディアが読み取り専用モードに移行

81日前原文(wikimediastatus.net)

概要

2026年3月5日に Wikisの編集機能 に障害発生
編集機能の一部 が現在も無効化
原因特定後、修正対応 を実施済み
定常的な 監視体制 で状況確認中
直近1週間で 複数回の障害発生 を記録

2026年3月5日発生：Wikis編集障害の経緯

15:36 UTC ：一部の Wikisへのアクセス障害 を確認、調査開始
16:11 UTC ： 問題の原因特定、修正作業に着手
17:09 UTC ： Wikisが再び読み書き可能 に。ただし 一部機能は引き続き無効
17:36 UTC ： 修正を適用、結果を監視中。 編集機能の一部 は依然として無効
- 編集機能の完全復旧は未達成
- 読み取り機能は正常に稼働

障害発生状況一覧（2026年2月20日～3月5日）

3月5日 ：Wikis編集機能障害（未解決）
3月3日 ：データベースサーバ障害。 10:09 UTC に問題発生、 10:24 UTC に復旧
2月26日・25日・20日 ：各日で 障害発生→修正→監視→復旧 の流れ
その他の日付 ：特に障害報告なし

現在のサービスステータス

Reading（読み取り） ：正常稼働
Editing（編集） ： パフォーマンス低下 または 一部機能停止
Partial Outage（部分的停止） ：一部機能に影響
Major Outage（大規模障害） ：該当日なし
Maintenance（メンテナンス） ：該当日なし

障害対応の流れ

調査（Investigating） ：障害発生時に即時調査
原因特定（Identified） ：原因判明後、修正作業開始
修正適用（Fix implemented） ：修正後、影響範囲の監視
監視（Monitoring） ：修正後も安定稼働を確認
復旧（Resolved） ：サービス完全復旧後に障害終了宣言
- 体制の迅速な切り替えとユーザーへの情報共有
- 障害発生～復旧までの一貫した対応プロセス

今後の注意点と推奨事項

編集機能の利用者 は、 一部機能が無効 である点に注意
障害発生時の公式アナウンス の定期確認推奨
復旧状況や今後の影響 に関する情報収集の継続推奨

Hackerたちの意見

追加のコンテキスト: https://wikipediocracy.com/forum/viewtopic.php?f=8&t=14555 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(techni... https://old.reddit.com/r/wikipedia/comments/1rllcdg/megathre... 明らかなJSワームのペイロード: https://ru.wikipedia.org/w/index.php?title=%D0%A3%D1%87%D0%B...

└

jQueryがまだ使われてるのを見ると嬉しい :)

└

Wikipediocracyのリンクは「権限がありません」と出る。

うわ、これ昔のXSSワームみたいだね。 https://meta.wikimedia.org/wiki/Special:RecentChanges?hidebo... MediaWikiが編集者にJavaScriptを埋め込ませることがあるのは危険だと思ってた。

└

それにしても、こういうXSS攻撃が実際にパスワードをブラウザのオートフィルを通じて盗むために使われてないのが意外だよね[0]。ワームのコードや複製されたコードは、実際にはサイト内のものだけを攻撃してるみたい。でも、認証情報が漏れたら（しかも人はサイト間でパスワードを使い回すから）もっとひどいことになるかも。[0] https://varun.ch/posts/autofill/

誰かが「MediaWikiがPHPで書かれてるからだ」と言う前にここにいるよ。

└

PHPは「return false」がtrueを返す言語だよ。 https://danielc7.medium.com/remote-code-execution-gaining-do...

わあ。このワームは面白いね。以下のことをするみたいだ: - MediaWiki:Common.jsページに自分を注入してグローバルに持続させる、そしてUser:Common.jsページにも同じことをしてフォールバックする - jQueryを使って感染を示すUI要素を隠す - 20のランダムな記事を5000px幅の画像とbasemetrika.ruからの別のXSSスクリプトで破壊する - 管理者が感染したら、Special:Nukeページを使ってグローバルネームスペースから3つのランダムな記事を削除し、さらにSpecial:Randomでaction=deleteを使って別の20のランダムな記事を削除する編集！Special:Nukeは本当に変だね。検索フィールドからデフォルトの削除対象記事リストを取得して、どんな記事グループでも削除できるようにして、削除を承認するんだ。これを3回連続でやる。

└

Wikipediocracyのフォーラムで誰かが指摘してたけど、basemetrika.ruは存在しないみたい。解決しようとするとNXDomainのレスポンスが返ってくる。事態が複雑になってきたね。

└

こんな複雑なワームがAIによって設計されてるなんて、驚かないよ。

└

「ランダムな20の記事を5000px幅の画像とbasemetrika.ruからの別のXSSスクリプトでいたずらしてる。これがXSSを引き起こそうとしてるように見えるけど、実際には効果がないから、basemetrika.ruは絶対に読み込まれないよ（ドメインが存在しないことを無視してもね）」

これは基本的に、昔のMySpaceのサミーワームの武器化された、非常に破壊的なバージョンだね。MediaWiki:Common.jsを攻撃するのは、MediaWikiの展開にとって絶対に最悪のシナリオだよ。このスクリプトは、サイト全体のすべての訪問者や編集者によって実行されるから、一瞬で大規模な拡散ループができちゃう。特に管理者を狙って、jQueryを使ってUI要素を隠しながら、バックグラウンドでSpecial:Nukeを静かにトリガーするのは本当に陰湿だね。これは、ユーザーが編集できる名前空間から直接実行可能なJavaScriptを保存して提供することを許すレガシーなウェブアーキテクチャの根本的な危険を暴露してる。これを片付けるのは、ウィキメディアチームにとって絶対に法医学的な悪夢になるだろうね。データベースの履歴自体がアクティブな配布ベクトルだから。

└

2010年代初頭に、サイト保護サービスのサブスクリプションが主な収入源の会社で働いてたんだけど、その中にはマルウェアに感染したWordPressのインストールをクリーンアップするサービスもあった。私はその仕事をするチームで働いてたんだ。このタイプのデータベースに保存された実行可能なJavaScriptは、クリーンアップするのが最も厄介な感染の一つだったよ。

└

クライアントサイド（JavaScript）にアプリロジックが詰め込まれすぎるのは、常に攻撃ベクトルになってる。サーバーサイドにできるだけ移せれば、見えないものが増えるからね。

└

その脆弱性の詳細をどこで見つけたか教えてくれる？リンク先には載ってないんだ。すごく興味ある。特に、修正する部分や他のユーザーがそれを広めているところについて？

└

「これを整理して、最初のインスタンスを見つけて、その前のバックアップにリセットして。1時間、1日、1週間？この場合はあまり関係ないけど。」

└

「MediaWiki:Common.jsに当たるのは、MediaWikiのデプロイメントにとって絶対に悪夢のシナリオだよ。なぜなら、そのスクリプトは文字通りすべての訪問者によって実行されるから…私たちのようにデフォルトでJSをオフにしているセキュリティオタクを除いてね。理由がない限りは有効にしないし、すぐに無効にするし、JSを必要とするウェブサイトにはあまり良い印象を持ってない。数年前までは、この行動はラッダイトや統合失調症の人たちの領域だった。今では、UID 0を持つ誰にとっても、合理的な自己防衛のための便利なツールになった。WMFは、自分たちのUIがどれだけ特別だと思っているのか再評価して、もしかしたらJSなしでもやっていけるかもしれないと考えてみるべきだね。ちょっとした提案だよ。」

└

これを整理するのは、ウィキメディアチームにとって絶対に法医学的な悪夢になるだろうね。データベースの履歴自体がアクティブな配布ベクターだから。まあ、ワームはroot権限を取れなかったみたいだし、ウィキメディアがスナップショットを取ったり最近バックアップを作ってたら、そこまでの悪夢にはならないかも？それに、差分からはかなり詳細な法医学的なストーリーがわかるし、動機の指標も含まれてる。

これは時間の問題だったね。ウィキペディアコミュニティはセキュリティに対して軽率な態度を取ってる。 "インターフェース管理者"のステータスを持つユーザーは、レビューなしで特定のウィキのすべてのユーザーに対してグローバルなJavaScriptやCSSを変更できるからね。数年前に必須の2FAを追加したばかりだよ…それ以前は、英語版ウィキペディアの管理者がウィキメディアのサイトプレゼンテーションの変更を元に戻すまで、どの管理者もその能力を持ってたんだ。でもそれだけじゃない。ほとんどの「パワーユーザー」や管理者は、「ユーザースクリプト」をインストールしていて、これはサンドボックスされていないJavaScript/CSSのガジェットで、サイトの動作を完全に変えちゃうことができるんだ。これらのユーザースクリプトは、2段階認証がないまま放置されたユーザーアカウントによって維持されていることが多い。ユーザースクリプトが今はグローバルに無効化されていることから、これがベクトルだったんじゃないかな。ウィキメディア財団はこれがセキュリティの悪夢だって知ってるよ。私も編集者だったときにこれについて文句を言ったことがある。でも、ウェブサイトを使っているほとんどの編集者はプロの開発者じゃなくて、スクリプトを制限しようとする試みをウィキメディア財団の権力の奪取だと見なしてるんだ。

└

ちょっと関係ないかもしれないけど、数回メインページが削除されたことを思い出したよ: https://en.wikipedia.org/wiki/Wikipedia:Don%27t_delete_the_m...

└

ウィキペディアの管理者はほとんど無能だね。

飲料水を管理するソフトウェアを重要インフラとしてマークすることは完全に理解できるけど、ある時点で国家ベースのサイバー攻撃がウィキペディアをネットから消し去るのは、現代社会が共通の事実に合意する能力に深刻なダメージを与えるよね…今、「もしウィキペディアが消えたら何を意味するんだろう…」って考えたけど、安全な飲料水のレベルではないけど、やっぱりそれなりのレベルだよ。

└

すべての永続データにはバックアップが必要だよ。そんなに高いハードルじゃない。

└

とにかくミラーがたくさんあるし、ローカルコピーを取るのも簡単じゃん？もっと心配なのは、政府の検閲や年齢確認・デジタルID法で、どの記事を読んだかが警察があなたを止めたときに見る政府の記録の一部になることだよ。

phabについての理論: 「ロシア語のウィキペディアのディスコードチャットで少し調査が行われたんだけど、役に立つかも。1. 2023年に、ロシア語の代替ウィキプロジェクトであるWikirealityとCyclopediaに対して、いたずら攻撃があったんだ。ここに、これらの攻撃の主催者についての記事があるよ: https://wikireality.ru/wiki/РАОрг 2. 2024年に、ruwikiのユーザーOloloshka562が、これらの攻撃で使われたスクリプトを含むページを作成したんだ: https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js それは次の1.5年間は非アクティブだった。3. 今日、sbassettが他のユーザーのスクリプトを大量にglobal.jsに読み込んだみたいで、もしかしたらグローバルAPIの制限をテストするためかも: https://meta.wikimedia.org/wiki/Special:Contributions/SBasse... その中の一つの編集で、Ololoshkaのスクリプトを読み込んで実行したんだ: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=30167...」

自分の古い自分に感謝してるよ、デフォルトでJavaScriptを無効にしておいて。これを続けててよかった。

ウィキペディアが攻撃されてるのは残念だね。今は5年前よりも悪意のあるアクターが増えてる気がする。これとは関係ないかもしれないけど、libgenやアナのアーカイブとかも攻撃が増えてるのに気づいた。ウィキペディアと同じだとは全然言ってないけど、今は人々の自由を狙うアクターが増えてるように見えるよね（例えば、情報へのアクセスの選択の自由とか、年齢制限、いわゆる年齢「確認」もこれに関わってるし）。

ハクソク