Wikipedia, एडमिन अकाउंट के बड़े पैमाने पर लीक के बाद read-only mode में गया, फिर बहाल हुआ

 (wikimediastatus.net)
1 पॉइंट द्वारा GN⁺ 2026-03-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Wikimedia Foundation के status page के अनुसार, 5 मार्च 2026 को Wikipedia सहित कई wiki services को अस्थायी रूप से read-only mode में बदल दिया गया
  • यह wiki access outage से शुरू हुआ और बाद में editing function सीमित होने के चरण तक पहुँचा
  • कारण स्पष्ट नहीं किया गया, लेकिन समस्या की पहचान के बाद सुधार कार्य जारी रहा और कुछ features तब भी निष्क्रिय थे
  • 6 मार्च को read-write functionality बहाल कर दी गई और अधिकांश user script features भी फिर से सक्रिय हो गए
  • इसके बाद Wikimedia लगातार monitoring के जरिए stability की जाँच कर रहा है

Wikimedia system status का अवलोकन

  • status page पर सभी सिस्टम सामान्य रूप से काम कर रहे हैं (All Systems Operational) दिखाया गया है
    • read और edit, दोनों functions को Operational के रूप में चिह्नित किया गया है
    • प्रति सेकंड 131,002 requests, users द्वारा report की गई 0.08 connection errors, 1.27 wiki error responses, औसत response time 0.20 सेकंड, और 11.4 successful edits दर्ज किए गए

5–6 मार्च 2026 की wiki read-only mode घटना

  • 5 मार्च 15:36 UTC से कुछ wiki access समस्याएँ report की गईं
    • 16:11 UTC पर समस्या की पहचान के बाद सुधार कार्य शुरू हुआ
    • 17:09 UTC पर समस्या के कारण की पहचान हो चुकी है और सुधार जारी है दिखाया गया
    • 17:36 UTC पर read-write mode बहाल कर दिया गया, लेकिन कुछ features अब भी निष्क्रिय थे
    • 18:36 UTC पर सुधार पूरा होने के बाद monitoring चरण में बदला गया
  • 6 मार्च 00:05 UTC पर लगातार monitoring जारी होने की सूचना दी गई
    • इसके बाद “wiki कई घंटों तक read-write mode में बना रहा, और अधिकांश user script features बहाल हो गए” के साथ इस घटना को resolved घोषित किया गया

मार्च 2026 की शुरुआत की अन्य संबंधित घटनाएँ

  • 3 मार्च को database server समस्या के कारण editing delay हुआ, लेकिन उसी दिन इसे हल कर दिया गया
    • 10:09 UTC पर समस्या की पहचान हुई, 10:17 UTC पर सुधार पूरा होने के बाद monitoring शुरू हुई, और 10:24 UTC पर सेवा सामान्य हो गई
  • 25–26 फ़रवरी को wiki access performance degradation report की गई, और हर बार सुधार के बाद सेवा सामान्य हो गई
  • 20 फ़रवरी को यूरोप क्षेत्र में access delay हुआ, जिसका कारण पहचानकर सुधार और monitoring के बाद समाधान किया गया

subscription और notification features

  • users email, Slack, Webhook, Atom/RSS feed के जरिए घटना, update और resolution की सूचनाएँ प्राप्त कर सकते हैं
  • email subscription पर OTP verification और reCAPTCHA protection लागू होता है
  • Slack subscription Atlassian Cloud terms और privacy policy के अनुसार संचालित होती है

सारांश

  • Wikimedia को मार्च की शुरुआत में कई बार editing function outage और performance degradation की घटनाओं का सामना करना पड़ा, लेकिन सभी बहाल हो गईं
  • 5–6 मार्च की read-only mode घटना सबसे बड़ी थी, और सुधार के बाद अधिकांश functions सामान्य हो गए
  • फिलहाल सभी सिस्टम सामान्य परिचालन स्थिति में हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-06
Hacker News की राय

  • सार्वजनिक Phabricator ticket को देखने पर पता चलता है कि Wikimedia Foundation के एक security engineer ने टेस्टिंग के लिए रैंडम user scripts लोड किए थे
    उनमें से एक 2 साल पुरानी malicious ruwiki script थी, और इस script ने खुद को global JS में inject करके तेज़ी से फैलते हुए नुकसान पहुँचाया
    आखिरकार स्थिति इतनी गंभीर हो गई कि पूरी wiki को read-only mode में डालना पड़ा

    • यह बात खास तौर पर चौंकाने वाली है कि ऐसी गलती एक security engineer ने की
    • शुरुआत में लगा कि कोई मौजूदा attacker सक्रिय है, लेकिन बाद में पता चला कि यह पुरानी malicious script थी, तो समाधान आसान हो गया
      regex का इस्तेमाल करके उस script को detect किया जा सकता था, और संक्रमित pages को पुराने version पर revert किया जा सकता था
    • यह लगभग Samy worm जैसा मामला लगता है
    • 300 million dollar के संगठन से ऐसी गलती होने पर यक़ीन करना मुश्किल है
    • ऐसा लगता है जैसे कोई बातचीत हुई हो: “Claude, तुम्हारी script ने malicious code execute कर दिया!” “हाँ, माफ़ कीजिए!”

  • इस worm के काम करने का तरीका दिलचस्प है
    यह MediaWiki के Common.js और User:Common.js में खुद को inject करके global infection बनाए रखता है, और jQuery से infection के निशान छिपाता है
    यह 20 random documents को deface करता है, और अगर admin account संक्रमित हो जाए तो Special:Nuke फीचर से documents delete कर देता है

    • इसकी मंशा बस “देखो मैं कितना chaos पैदा कर सकता हूँ” वाली शरारत जैसी लगती है
    • basemetrika.ru domain मौजूद नहीं है। NXDomain response मिलता है
    • यह XSS की कोशिश करता हुआ दिखता है, लेकिन असल में ineffective code है इसलिए external load नहीं होता
    • लगता है कि इतना sophisticated worm शायद AI ने design किया हो

  • कुछ लोगों का कहना था कि database खुद infection vector बन गया है, इसलिए सफाई का काम digital forensics nightmare होगा
    लेकिन root privilege compromise नहीं हुआ था, और अगर backup हो तो recovery संभव लगती है

    • कुछ दिनों के edits खो भी जाएँ तो Wikipedia के पैमाने पर यह सहने लायक है
    • असल में DB rollback नहीं किया गया, बल्कि सामान्य wiki revert tools से मामला संभाला गया, और Wikipedia core नहीं बल्कि सिर्फ Meta site प्रभावित हुई

  • Russian wiki community की जाँच के अनुसार, 2023 में Russian alternative wikis पर हुए vandal attack में इस्तेमाल हुआ code ही इस बार भी इस्तेमाल हुआ लगता है
    ruwiki user Ololoshka562 की बनाई test.js वही script थी,
    और माना जा रहा है कि WMF staff sbassett ने टेस्ट के दौरान इसी script को लोड किया, जिससे यह execute हुई

    • पिछले साल भी ruwiki इसी तरह के बड़े पैमाने के defacement का शिकार हुआ था

  • यह किसी पुराने XSS worm जैसा लगता है
    मैं पहले से सोचता था कि MediaWiki का users को JavaScript inject करने देना एक खतरनाक संरचना है

    • हैरानी की बात यह है कि इस तरह का XSS अब तक password theft जैसे हमलों में इस्तेमाल नहीं हुआ
      इस लेख की तरह browser autofill vulnerability का उपयोग किया गया होता, तो मामला कहीं ज्यादा गंभीर होता

  • Wikipedia से शिकायतें हों, तब भी इस घटना को बहाना बनाकर harassment या stalking करना सही नहीं ठहराया जा सकता

  • एक wiki editor दोस्त के अनुसार, यह घटना cross-site scripting (XSS) hack लगती है
    Russian wiki के user page से शुरू हुआ code Meta के common.js के ज़रिए फैला,
    और admins को manually revert करते हुए Recent Changes page पर देखा गया

    • यह “Russia-origin attack” जैसा दिख सकता है, लेकिन इस तरह source spoof करना बहुत आसान है
    • लेकिन एक अन्य user का मानना है कि यह code पुराने Russian hacking tool “woodpecker” का variant होने की संभावना ज्यादा है

  • अतिरिक्त संदर्भ के लिए Wikipediocracy forum,
    Village Pump चर्चा,
    Reddit megathread आदि हैं
    संबंधित payload को इस लिंक पर देखा जा सकता है

    • web archive version को सुरक्षित रूप से देखा जा सकता है
    • कुछ links access permissions के कारण नहीं खुलते

  • सच कहें तो ऐसी घटना बस समय की बात थी
    Wikipedia ने security को लेकर बहुत लापरवाह रवैया दिखाया है
    सिर्फ “interface administrator” permission होने पर global JS/CSS बदला जा सकता है, और 2FA भी हाल में ही लागू हुआ
    इसके अलावा बहुत से users unverified user scripts इस्तेमाल करते हैं
    यह पूरी संरचना ही एक security nightmare है, और शायद इसी वजह से इस घटना के बाद user scripts को globally disable किया गया

    • पहले main page तक delete हो चुका है (link)
    • फिलहाल interface administrators लगभग 137 हैं, और उनमें ज़्यादातर Wikimedia staff हैं, इसलिए कम-से-कम वे verified personnel हैं
    • इंटरनेट लगातार अधिक hostile environment बनता जा रहा है, इसलिए लगता है कि ऐसे मुद्दों के समाधान के लिए donation या technical support की जरूरत है
    • browser extensions (TamperMonkey आदि) के जरिए user scripts अब भी मौजूद रहेंगे, इसलिए पूरी तरह रोकना संभव नहीं है
    • वास्तव में English Wikipedia में सिर्फ 15 interface administrators सक्रिय हैं (संदर्भ)

  • अब मज़ाक में यह भी कहा जा रहा है कि AI ने Wikipedia को पूरा scrape कर लिया है, इसलिए अब कोई Wikipedia सीधे इस्तेमाल ही नहीं करता