▲

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

 (wikimediastatus.net)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • 위키미디어 재단의 상태 페이지에 따르면, 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일의 읽기 전용 모드 전환은 가장 큰 사건으로, 수정 후 대부분 기능이 정상화됨
  • 현재 모든 시스템은 정상 작동 상태로 유지되고 있음
▲
GN⁺ 1일전  [-]
Hacker News 의견들

  • 공개된 Phabricator 티켓을 보면, Wikimedia Foundation의 한 보안 엔지니어가 테스트를 위해 무작위 사용자 스크립트를 로드했음
    그중 하나가 2년 된 악성 ruwiki 스크립트였고, 이 스크립트는 전역 JS에 자신을 주입해 빠르게 퍼지며 피해를 일으켰음
    결국 위키 전체가 읽기 전용 모드로 전환될 정도로 심각한 사태였음

    • 이런 실수를 한 게 보안 엔지니어라는 점이 특히 충격적임
    • 처음엔 현재 공격자가 있는 줄 알았는데, 과거의 악성 스크립트였다는 걸 알고 나니 해결은 간단해졌음
      정규식을 써서 해당 스크립트를 탐지하고, 감염된 페이지를 이전 버전으로 되돌리면 됨
    • 이건 거의 Samy 웜 같은 사례로 보임
    • 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가 그 스크립트였고,
    WMF 직원 sbassett이 테스트 중 이 스크립트를 불러오며 실행된 것으로 추정됨

    • 작년에도 ruwiki가 비슷한 방식으로 대규모 훼손을 당한 적이 있었음

  • 오래된 XSS 웜처럼 보임
    MediaWiki가 사용자에게 JavaScript 삽입을 허용하는 구조가 위험하다고 예전부터 생각했음

    • 놀라운 건 이런 XSS가 아직 비밀번호 탈취 같은 공격에 쓰이지 않았다는 점임
      이 글처럼 브라우저 자동완성 취약점을 이용했다면 훨씬 심각했을 것임

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

  • 위키 편집자 친구의 말에 따르면, 이번 사건은 교차 사이트 스크립팅(XSS) 해킹으로 보임
    러시아어 위키의 사용자 페이지에서 시작된 코드가 Meta의 common.js를 통해 퍼졌고,
    운영자들이 수동으로 되돌리는 모습이 Recent Changes 페이지에서 보였음

    • “러시아발 공격”처럼 보이지만, 그런 식으로 출처를 위조하는 건 매우 쉬움
    • 하지만 다른 사용자는 이 코드가 오래된 러시아 해킹 도구 “woodpecker”의 변형일 가능성이 높다고 봄

  • 추가 맥락으로 Wikipediocracy 포럼,
    Village Pump 토론,
    Reddit 메가스레드 등이 있음
    문제의 페이로드는 이 링크에서 확인 가능

  • 사실 이런 일은 시간문제였음
    Wikipedia는 보안에 대해 너무 안이한 태도를 보여왔음
    “인터페이스 관리자” 권한만 있으면 전역 JS/CSS를 수정할 수 있고, 2FA도 최근에야 도입됨
    게다가 많은 사용자가 검증되지 않은 사용자 스크립트를 쓰고 있음
    이런 구조 자체가 보안 악몽이며, 이번 사태로 사용자 스크립트가 전역 비활성화된 것도 이 때문일 것임

    • 예전엔 메인 페이지조차 삭제된 적이 있었음 (링크)
    • 현재 인터페이스 관리자는 약 137명 정도로, 대부분 Wikimedia 직원이라 그나마 검증된 인원임
    • 인터넷이 점점 적대적인 환경이 되어가니, 이런 문제 해결에 기부나 기술 지원이 필요하다고 느낌
    • 브라우저 확장(TamperMonkey 등)을 통한 사용자 스크립트는 여전히 존재하므로, 완전한 차단은 불가능함
    • 실제로 영어 위키 기준 15명의 인터페이스 관리자만 활동 중임 (참조)

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

답변달기