Wikipedia 자가증식 JavaScript 웜 사건 — 보안 검토 중 내부 활성화로 전파
사건 개요
2026년 3월 5일, Wikimedia Foundation 직원이 전 세계 Wikimedia 프로젝트의 사용자 스크립트 코드를 대상으로 보안 검토 작업을 수행하던 중 2년 전 심어진 악성 JavaScript 스크립트를 의도치 않게 실행했다. 이 스크립트는 자가증식 웜으로 작동해 Meta-Wiki 전체로 빠르게 전파됐다.
Wikimedia Foundation은 공식 성명에서 다음과 같이 밝혔다.
- 악성 코드가 활성화된 시간은 약 23분
- 그 시간 동안 Meta-Wiki의 페이지 삭제 및 훼손이 발생했고 이후 복구됨
- Wikimedia 프로젝트는 약 2시간 동안 읽기 전용 모드로 전환됐으며 사용자 JavaScript가 일시 비활성화됨
- 개인 정보 침해 또는 Wikipedia가 의도적 공격을 받았다는 증거는 없음
BleepingComputer 분석에 따르면 웜이 활성화된 23분 동안 약 3,996개 페이지가 변조됐고, 약 85명 사용자의 common.js 파일이 악성 코드로 교체됐다.
기술적 세부사항
악성 스크립트의 출처와 잠복 경위
문제의 악성 스크립트는 User:Ololoshka562/test.js 로, 2024년 3월 러시아어 Wikipedia에 최초 업로드됐다. 이 스크립트는 당시 두 개의 러시아어 위키 프로젝트를 대상으로 한 공격에 이미 사용된 이력이 있는 것으로 알려졌다. 이후 약 1년 6개월간 러시아어 Wikipedia에 잠복 상태로 존재했다.
Wikimedia Foundation의 보안팀 직원은 사용자 스크립트 보안 검토 작업을 수행하면서 별도의 격리된 테스트 환경이나 전용 테스트 스크립트를 사용하는 대신, 플랫폼 내 실제 사용자 스크립트를 무작위로 로드하는 방식을 사용했다. 이 직원은 Wikimedia Foundation 전체 인터페이스 관리자(Global Interface Administrator) 권한을 보유하고 있었으며, 이 권한은 Meta-Wiki의 MediaWiki:Common.js 전역 스크립트를 편집할 수 있는 최고 수준의 접근 권한이다.
웜 전파 메커니즘
악성 스크립트가 Global Interface Administrator 계정 환경에서 실행되자 다음 순서로 전파가 진행됐다.
- 스크립트가 MediaWiki:Common.js (Meta-Wiki 전체에 적용되는 전역 JavaScript 파일)에 악성 로더 코드를 삽입
- 전역 스크립트가 수정된 상태에서 Meta-Wiki를 방문하는 모든 사용자가 악성 로더를 자동 실행
- 악성 로더는 실행 시 해당 사용자의 User:Common.js (개인 스크립트 파일)에 동일한 악성 코드를 삽입해 웜을 자기 복제
- 동시에 Special:Random 명령으로 무작위 페이지를 선택한 뒤 5,000픽셀 크기의 이미지를 삽입하고 숨겨진 JavaScript 로더( basemetrika.ru 호스팅)를 페이지에 추가
관리자 권한을 가진 사용자가 감염된 상태에서 Meta-Wiki를 방문할 경우 추가 파괴 행동이 실행됐다.
- Special:Nuke 를 이용해 전역 네임스페이스에서 무작위 3개 문서를 삭제
- Special:Random 과 action=delete 로 추가 20개 문서를 삭제
- 삭제된 문서의 편집 요약에는 러시아어로 클로징 프로젝트를 의미하는 문구가 남겨짐
외부 스크립트 호스팅
악성 스크립트는 basemetrika.ru 도메인에서 추가 페이로드를 로드하는 방식을 사용했다. 이 외부 도메인에서 XSS 스크립트가 추가로 주입됐다. 이는 단순 반달리즘이 아닌 추가 악성코드 삽입까지 가능한 구조였음을 시사한다.
탐지 및 대응
비정상적인 대량 자동 편집 활동은 거의 즉시 보안 경보를 발생시켰다. 편집 규모와 속도가 정상 범위를 벗어났기 때문이다. Wikimedia 엔지니어들은 웜을 억제하기 위해 전체 Wikimedia 프로젝트를 읽기 전용 모드로 전환하고 사용자 JavaScript 기능을 전면 비활성화했다. 이 조치로 인해 전 세계 수백만 명의 사용자가 약 2시간 동안 Wikipedia를 편집하지 못했다. 피해를 입은 페이지와 삭제된 문서는 이후 복구됐다.
근본 원인 분석
기술적 원인
자가증식 JavaScript 웜이 작동할 수 있었던 기술적 근거는 MediaWiki의 전역 사용자 스크립트 아키텍처에 있다. MediaWiki:Common.js 는 모든 방문자에게 자동으로 실행되므로, 이 파일이 한 번 오염되면 플랫폼 전체에 걸쳐 웜이 확산될 수 있다. 사용자 스크립트 시스템이 외부 도메인에서 추가 JavaScript를 로드하는 것을 허용하는 구조도 공격 표면을 확장했다.
잠복 악성 코드 탐지 메커니즘이 없었다는 점도 기술적 원인이다. 러시아어 Wikipedia에 2024년부터 존재하던 악성 스크립트가 1년 6개월간 감지되지 않았다는 것은 사용자 스크립트에 대한 자동화된 악성코드 분석 체계가 없었음을 의미한다.
관리적 원인
보안 검토 절차의 핵심적 결함이 이번 사건의 직접적 원인이다.
- 보안 검토 작업을 위한 격리된 테스트 환경이나 읽기 전용 샌드박스가 마련되지 않음
- 최고 수준의 접근 권한(Global Interface Administrator)을 가진 계정이 보안 검토 같은 고위험 작업을 수행할 때 추가적인 안전장치나 이중 승인 절차가 없음
- 보안 검토 대상 코드를 실제 운영 환경에서 직접 실행하는 것을 허용하는 작업 지침이 존재했거나, 이를 명시적으로 금지하는 지침이 없음
인적 원인
Wikimedia Foundation이 공개한 사건 보고서에 따르면 직원은 테스트 목적으로 실제 사용자 스크립트를 무작위로 로드하는 방식을 선택했다. 이 결정이 최고 권한 계정으로 운영 환경에서 이루어졌다는 점에서, 최소 권한 원칙(Principle of Least Privilege) 준수와 안전한 테스트 환경 사용이라는 기본 보안 원칙이 적용되지 않았다.
Wikimedia Foundation 자체도 공식 성명에서 이 상황의 아이러니를 인정했다. 이 사건이 정확히 이런 종류의 공격 위험을 줄이기 위한 보안 검토 작업 중에 발생했다고 밝혔다.
영향 평가
직접적 피해
약 3,996개 페이지가 변조됐고 85명 사용자의 개인 스크립트가 감염됐다. 삭제된 문서는 복구됐으며 Wikimedia Foundation은 영구적 피해가 없다고 공식 확인했다. 개인 정보 침해 증거도 없다고 밝혔다. 약 2시간의 전체 편집 중단이 발생했으며, 이 시간 동안 전 세계 수백만 명의 사용자가 영향을 받았다.
잠재적 위험 (실제로 발생하지 않은 시나리오)
만약 악성 스크립트가 더 파괴적인 페이로드를 가졌거나, 탐지가 더 늦었거나, 더 많은 관리자 권한 보유자가 감염된 상태로 방문했다면 피해 규모는 현저히 컸을 것이다. 외부 도메인 basemetrika.ru 를 통한 추가 페이로드 삽입 구조는 단순 반달리즘을 넘어 사용자 브라우저에 악성코드를 배포하는 XSS 공격으로 발전할 가능성이 있었다.
예방 및 대응 방안
즉각 조치
악성 코드가 삽입된 외부 도메인( basemetrika.ru ) 접속을 차단하고, 감염된 사용자 스크립트를 식별해 정리해야 한다. 감염 기간 동안 Global Interface Administrator 이상 권한을 보유한 계정이 Meta-Wiki를 방문했는지 로그를 검토하고, 해당 계정에서 추가 파괴 행동이 실행됐는지 확인해야 한다.
구조적 개선
Wikimedia Foundation은 사건 이후 사용자 스크립트 보안 강화를 위한 추가 조치를 개발 중이라고 밝혔다. 구체적으로 필요한 개선 사항은 다음과 같다.
- 보안 검토 및 테스트 작업을 위한 격리된 샌드박스 환경 구축
- 사용자 스크립트에 대한 자동화된 악성코드 정적 분석 시스템 도입 (업로드 시점에 의심 패턴을 탐지하는 체계가 있었다면 2024년에 심어진 스크립트를 사전에 발견할 수 있었을 것)
- 최고 권한 계정이 보안 검토 같은 고위험 작업을 수행할 때 이중 승인 절차나 별도의 격리된 권한 계정을 사용하는 정책 수립
- 외부 도메인에서 JavaScript를 로드하는 사용자 스크립트를 탐지하고 차단하는 Content Security Policy 강화 검토
컨설팅 관점
고객사 커뮤니케이션 전략
비기술 직원 대상
세계 최대 백과사전이 해킹을 당한 것처럼 보이지만, 실제 원인은 외부 공격자가 아니라 내부 직원이 보안 점검 작업 중 실수로 과거에 심어진 악성 코드를 작동시킨 것이다. 이 사건은 보안 점검 자체도 올바른 방식으로 수행하지 않으면 새로운 보안 사고를 만들 수 있다는 교훈을 준다.
기술팀 대상
이 사건에서 도출되는 핵심 기술 교훈은 세 가지다.
- 첫째, 보안 검토·침투 테스트·취약점 스캐닝 같은 보안 작업을 운영 환경의 고권한 계정으로 직접 수행하는 것은 그 자체로 보안 사고를 유발할 수 있다. 격리 원칙은 공격자뿐만 아니라 내부 보안 활동에도 동일하게 적용된다.
- 둘째, 사용자가 생성하는 콘텐츠(User-generated Content) 플랫폼에서 코드(특히 JavaScript) 실행 권한을 사용자에게 부여하는 구조는 원칙적으로 높은 위험을 내포한다. 이 위험은 코드 업로드 시점의 정적 분석과 실행 시점의 동적 격리를 통해서만 통제할 수 있다.
- 셋째, 1년 6개월간 탐지되지 않은 잠복 악성 스크립트는 사용자 스크립트 생태계에 대한 정기적인 자동화 감사가 없었음을 의미한다.
경영진 대상
이 사건은 사이버 보안 담당자가 보안 활동을 수행하는 방식 자체가 보안 위험이 될 수 있다는 점을 보여준다. 보안팀의 작업 절차와 도구 환경에도 내부 통제와 위험 관리 체계가 필요하다. 또한 플랫폼이 사용자 생성 코드를 허용하는 구조라면, 그 코드에 대한 거버넌스 프레임워크가 반드시 설계 단계에서 포함돼야 한다.
법무/컴플라이언스 대상
Wikimedia Foundation은 개인 정보 침해가 없다고 밝혔다. 그러나 외부 도메인( basemetrika.ru )으로의 사용자 브라우저 데이터 전송 가능성이 있었다면 GDPR 등 데이터 보호 규정에 따른 검토가 필요했을 것이다. 이번 사건은 실제 피해가 제한적이었기 때문에 법적 파급 효과가 최소화됐으나, 구조적으로 동일한 사건이 더 오래 지속됐다면 규정 위반 가능성이 발생했을 것이다.
예상 질문 및 답변
Q: 이 사건은 Wikipedia를 의도적으로 공격한 것인가, 아니면 완전히 내부 실수인가?
A: 두 요소가 혼재한다. 악성 스크립트를 원래 심은 것은 2024년에 외부 행위자가 수행한 의도적 행위다. 그러나 그 스크립트가 Wikimedia 전체로 전파된 직접적 원인은 Wikimedia Foundation 직원의 내부 실수다. Wikimedia Foundation 자체도 공식 보고에서 이 점을 명확히 인정했다. 따라서 이 사건의 본질은 외부 위협(잠복 악성 코드)과 내부 절차적 실패(고권한 계정으로 운영 환경에서 임의 스크립트 실행)의 결합이다.
Q: 이런 사건이 우리 조직에서도 발생할 수 있는가?
A: 사용자 생성 콘텐츠나 사용자 생성 코드를 허용하는 플랫폼이라면 동일한 구조적 위험이 존재한다. 내부 시스템에서 보안 검토나 취약점 스캐닝을 수행할 때 격리 환경 없이 운영 환경에서 직접 실행하는 관행도 동일한 위험을 내포한다. 특히 높은 권한을 가진 계정이 테스트나 검토 목적으로 검증되지 않은 코드나 파일을 실행하는 상황은 모든 조직에서 발생할 수 있는 시나리오다.
학습 내용 및 시사점
첫째, 보안 활동의 역설이 이 사건에서 명확히 드러났다. 보안 취약점을 찾기 위한 검토 작업이 검토 대상 취약점을 직접 촉발한 것이다. 이는 보안 작업 절차 자체에도 위험 관리 체계가 필요하다는 점을 보여준다. 격리 환경 없이 고권한 계정으로 수행하는 보안 검토는 공격자와 동일한 행동 결과를 낼 수 있다.
둘째, 잠복 악성 코드의 위험성이 구체적으로 확인됐다. 2024년에 심어진 스크립트가 1년 6개월간 탐지되지 않고 존재하다가 하나의 실수로 즉시 활성화됐다. 이는 플랫폼이 사용자 생성 코드를 허용하는 구조라면, 현재 존재하는 모든 코드에 대한 소급 감사와 업로드 시점의 자동화된 악성코드 검사가 필수임을 보여준다.
셋째, 사건 대응 속도와 복구 역량이 실제 피해를 결정했다. 23분의 활성화 시간, 2시간의 읽기 전용 전환, 그리고 모든 피해 페이지의 완전 복구라는 결과는 탐지와 격리가 신속하게 이루어졌기 때문에 가능했다. 사전에 준비된 인시던트 대응 절차와 빠른 시스템 격리 능력이 실질적 피해 범위를 제한하는 핵심 요소임을 이 사건이 다시 한번 확인한다.