# 위키백과, 관리자 계정 대량 유출로 읽기 전용 모드 전환되었다가 복구

> Clean Markdown view of GeekNews topic #27233. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=27233](https://news.hada.io/topic?id=27233)
- GeekNews Markdown: [https://news.hada.io/topic/27233.md](https://news.hada.io/topic/27233.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-03-06T09:37:36+09:00
- Updated: 2026-03-06T09:37:36+09:00
- Original source: [wikimediastatus.net](https://www.wikimediastatus.net)
- Points: 1
- Comments: 1

## Topic Body

- 위키미디어 재단의 **상태 페이지**에 따르면, 2026년 3월 5일 위키백과를 포함한 여러 **위키 서비스가 일시적으로 읽기 전용 모드**로 전환됨  
- **위키 접근 장애**로 시작되어, 이후 **수정 기능이 제한**되는 단계로 이어짐  
- 원인은 명시되지 않았으나, **문제 식별 후 수정 작업이 진행**되었고 일부 기능은 여전히 비활성화 상태였음  
- 3월 6일에는 **읽기-쓰기 기능이 복구**되었으며, 대부분의 사용자 스크립트 기능도 다시 활성화됨  
- 위키미디어는 이후 **지속적인 모니터링을 통해 안정성 점검**을 진행 중임  
  
---  
  
### 위키미디어 시스템 상태 개요  
- 상태 페이지에는 **모든 시스템이 정상 작동(All Systems Operational)** 상태로 표시됨  
  - 읽기, 편집 기능 모두 **Operational**로 표기  
  - 초당 요청량 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일의 읽기 전용 모드 전환은 가장 큰 사건으로, **수정 후 대부분 기능이 정상화**됨  
- 현재 모든 시스템은 **정상 작동 상태**로 유지되고 있음

## Comments



### Comment 52493

- Author: neo
- Created: 2026-03-06T09:37:36+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47263323) 
- 공개된 [Phabricator 티켓](https://phabricator.wikimedia.org/T419143)을 보면, Wikimedia Foundation의 한 **보안 엔지니어**가 테스트를 위해 무작위 사용자 스크립트를 로드했음  
  그중 하나가 2년 된 **악성 ruwiki 스크립트**였고, 이 스크립트는 전역 JS에 자신을 주입해 빠르게 퍼지며 피해를 일으켰음  
  결국 위키 전체가 읽기 전용 모드로 전환될 정도로 심각한 사태였음
  - 이런 실수를 한 게 **보안 엔지니어**라는 점이 특히 충격적임
  - 처음엔 현재 공격자가 있는 줄 알았는데, 과거의 악성 스크립트였다는 걸 알고 나니 해결은 간단해졌음  
    정규식을 써서 해당 스크립트를 탐지하고, 감염된 페이지를 이전 버전으로 되돌리면 됨
  - 이건 거의 [**Samy 웜**](https://en.wikipedia.org/wiki/Samy_%28computer_worm%29) 같은 사례로 보임
  - 3억 달러 규모의 조직이 이런 실수를 한다는 게 믿기지 않음
  - “Claude, 네 스크립트가 악성 코드 실행했어!” “맞아요, 죄송해요!” 같은 대화가 오갔을 것 같음

- 이 **웜의 동작 방식**이 흥미로움  
  MediaWiki의 Common.js와 User:Common.js에 자신을 주입해 전역 감염을 유지하고, jQuery로 감염 흔적을 숨김  
  20개의 임의 문서를 훼손하고, 관리자 계정을 감염시키면 Special:Nuke 기능으로 문서를 삭제함  
  - 단순히 “내가 얼마나 혼란을 일으킬 수 있는지 보라”는 장난 수준의 동기처럼 보임
  - basemetrika.ru 도메인은 존재하지 않음. NXDomain 응답이 돌아옴
  - XSS를 시도하는 것처럼 보이지만 실제로는 **비효과적 코드**라 외부 로드는 일어나지 않음
  - 이런 정교한 웜은 **AI가 설계했을 가능성**도 있다고 생각함

- 데이터베이스 자체가 감염 매개체라 정리 작업이 **디지털 포렌식 악몽**이 될 거란 말이 있었음  
  하지만 루트 권한을 뚫은 건 아니고, 백업이 있다면 복구는 가능할 것 같음  
  - 며칠치 편집이 사라지더라도 Wikipedia 전체로 보면 감내할 수준임  
  - 실제로는 DB 롤백이 아니라 일반적인 **위키 되돌리기 도구**로 처리되었고, Wikipedia 본체가 아닌 **Meta 사이트**만 영향받았음

- 러시아 위키 커뮤니티에서의 조사에 따르면, 2023년 러시아어 대체 위키들에 대한 **반달 공격**에 쓰였던 코드가 이번에도 사용된 것으로 보임  
  ruwiki 사용자 Ololoshka562가 만든 [test.js](https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js)가 그 스크립트였고,  
  WMF 직원 sbassett이 테스트 중 이 스크립트를 불러오며 실행된 것으로 추정됨  
  - 작년에도 ruwiki가 비슷한 방식으로 대규모 훼손을 당한 적이 있었음

- 오래된 **XSS 웜**처럼 보임  
  MediaWiki가 사용자에게 JavaScript 삽입을 허용하는 구조가 위험하다고 예전부터 생각했음  
  - 놀라운 건 이런 XSS가 아직 **비밀번호 탈취** 같은 공격에 쓰이지 않았다는 점임  
    [이 글](https://varun.ch/posts/autofill/)처럼 브라우저 자동완성 취약점을 이용했다면 훨씬 심각했을 것임

- Wikipedia에 불만이 있더라도, 이번 사태를 빌미로 **괴롭힘이나 스토킹**을 하는 건 정당화될 수 없음

- 위키 편집자 친구의 말에 따르면, 이번 사건은 **교차 사이트 스크립팅(XSS)** 해킹으로 보임  
  러시아어 위키의 사용자 페이지에서 시작된 코드가 Meta의 common.js를 통해 퍼졌고,  
  운영자들이 수동으로 되돌리는 모습이 [Recent Changes 페이지](https://meta.wikimedia.org/wiki/special:RecentChanges)에서 보였음  
  - “러시아발 공격”처럼 보이지만, 그런 식으로 **출처를 위조하는 건 매우 쉬움**
  - 하지만 다른 사용자는 이 코드가 오래된 러시아 해킹 도구 “**woodpecker**”의 변형일 가능성이 높다고 봄

- 추가 맥락으로 [Wikipediocracy 포럼](https://wikipediocracy.com/forum/viewtopic.php?f=8&t=14555),  
  [Village Pump 토론](https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Meta-Wiki_compromised),  
  [Reddit 메가스레드](https://old.reddit.com/r/wikipedia/comments/1rllcdg/megathread_wikimedia_wikis_locked_accounts/) 등이 있음  
  문제의 페이로드는 [이 링크](https://ru.wikipedia.org/w/index.php?title=%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Ololoshka562/test.js&oldid=136952558)에서 확인 가능  
  - [웹 아카이브 버전](https://web.archive.org/web/20260305155250/https://ru.wikipedia.org/wiki/%D0%A3%D1%87%D0%B0%D1%81%D1%82%D0%BD%D0%B8%D0%BA:Ololoshka562/test.js)은 안전하게 볼 수 있음  
  - 일부 링크는 접근 권한이 없어 열리지 않음

- 사실 이런 일은 **시간문제**였음  
  Wikipedia는 보안에 대해 너무 **안이한 태도**를 보여왔음  
  “인터페이스 관리자” 권한만 있으면 전역 JS/CSS를 수정할 수 있고, 2FA도 최근에야 도입됨  
  게다가 많은 사용자가 **검증되지 않은 사용자 스크립트**를 쓰고 있음  
  이런 구조 자체가 보안 악몽이며, 이번 사태로 사용자 스크립트가 전역 비활성화된 것도 이 때문일 것임  
  - 예전엔 메인 페이지조차 삭제된 적이 있었음 ([링크](https://en.wikipedia.org/wiki/Wikipedia:Don%27t_delete_the_main_page))  
  - 현재 인터페이스 관리자는 약 137명 정도로, 대부분 Wikimedia 직원이라 그나마 **검증된 인원**임  
  - 인터넷이 점점 적대적인 환경이 되어가니, 이런 문제 해결에 **기부나 기술 지원**이 필요하다고 느낌  
  - 브라우저 확장(TamperMonkey 등)을 통한 사용자 스크립트는 여전히 존재하므로, 완전한 차단은 불가능함  
  - 실제로 영어 위키 기준 **15명의 인터페이스 관리자**만 활동 중임 ([참조](https://en.wikipedia.org/wiki/Wikipedia:Interface_administrators))

- 이제는 **AI가 Wikipedia를 다 긁어갔기 때문에** 아무도 Wikipedia를 직접 쓰지 않는다는 농담 섞인 말도 나옴