- Segundo a página de status da Wikimedia Foundation, em 5 de março de 2026 vários serviços wiki, incluindo a Wikipédia, foram temporariamente colocados em modo somente leitura
- O incidente começou com falhas de acesso aos wikis e depois evoluiu para uma fase em que a função de edição ficou limitada
- A causa não foi especificada, mas, após a identificação do problema, o trabalho de correção foi realizado, e algumas funções ainda permaneciam desativadas
- Em 6 de março, as funções de leitura e escrita foram restauradas, e a maioria dos recursos de scripts de usuário também voltou a ser ativada
- A Wikimedia segue monitorando continuamente a estabilidade após o incidente
Visão geral do status dos sistemas da Wikimedia
- A página de status mostra todos os sistemas operacionais (All Systems Operational)
- Tanto leitura quanto edição aparecem como Operational
- Foram registrados 131.002 requisições por segundo, 0,08 erros de conexão reportados por usuários, 1,27 respostas de erro dos wikis, tempo médio de resposta de 0,20 segundo e 11,4 edições bem-sucedidas
Incidente do modo somente leitura dos wikis em 5~6 de março de 2026
- A partir de 15:36 UTC de 5 de março, foram reportados problemas de acesso a alguns wikis
- Às 16:11 UTC, o problema foi reconhecido e o trabalho de correção foi iniciado
- Às 17:09 UTC, o status indicava causa identificada e correção em andamento
- Às 17:36 UTC, o modo de leitura e escrita foi restaurado, mas algumas funções ainda permaneciam desativadas
- Às 18:36 UTC, o incidente passou para a fase de monitoramento após a conclusão da correção
- Em 6 de março, às 00:05 UTC, foi informado que o sistema seguia em monitoramento contínuo
- Depois, o incidente foi marcado como resolvido (Resolved) com a observação de que os wikis permaneceram em modo de leitura e escrita por várias horas, e a maioria dos recursos de scripts de usuário foi restaurada
Outros incidentes relacionados no início de março de 2026
- Em 3 de março, houve atraso nas edições devido a um problema no servidor de banco de dados, mas isso foi resolvido no mesmo dia
- Problema identificado às 10:09 UTC, correção concluída e monitoramento iniciado às 10:17 UTC, normalização às 10:24 UTC
- Entre 25 e 26 de fevereiro, foi reportada degradação no desempenho de acesso aos wikis, e os casos foram corrigidos e normalizados em seguida
- Em 20 de fevereiro, houve lentidão de acesso na região da Europa, e o incidente foi resolvido após identificação da causa, correção e monitoramento
Assinaturas e notificações
- Os usuários podem receber notificações de ocorrência, atualização e resolução de incidentes por e-mail, Slack, Webhook e feed Atom/RSS
- Na assinatura por e-mail, são aplicadas verificação por OTP e proteção reCAPTCHA
- A assinatura via Slack é operada de acordo com os Termos do Atlassian Cloud e a Política de Privacidade
Resumo
- A Wikimedia enfrentou várias interrupções na função de edição e degradações de desempenho no início de março, mas todas foram restauradas
- A mudança para modo somente leitura entre 5 e 6 de março foi o maior incidente, e a maior parte das funções voltou ao normal após a correção
- No momento, todos os sistemas seguem em estado normal de operação
1 comentários
Comentários do Hacker News
Pelo ticket público do Phabricator, um engenheiro de segurança da Wikimedia Foundation carregou scripts aleatórios de usuários para testes
Um deles era um script malicioso da ruwiki com 2 anos de idade, e esse script injetou a si mesmo no JS global, se espalhando rapidamente e causando danos
No fim, a situação foi grave a ponto de toda a wiki ser colocada em modo somente leitura
Bastava usar regex para detectar o script e reverter as páginas infectadas para uma versão anterior
O modo de operação desse worm é interessante
Ele se injeta em Common.js e User:Common.js do MediaWiki para manter a infecção global, e usa jQuery para esconder os rastros da infecção
Vandaliza 20 documentos aleatórios e, ao infectar uma conta de administrador, apaga documentos com a função Special:Nuke
Houve quem dissesse que, como o próprio banco de dados era o vetor de infecção, a limpeza seria um pesadelo de perícia digital
Mas não houve comprometimento de root, e se houver backups, a recuperação parece viável
Segundo a investigação na comunidade da wiki russa, o código usado em ataques de vandalismo contra wikis alternativas em russo em 2023 aparentemente foi reutilizado desta vez
O script era o test.js criado pelo usuário Ololoshka562 da ruwiki,
e acredita-se que ele tenha sido executado quando o funcionário da WMF sbassett carregou esse script durante um teste
Parece um velho worm de XSS
Há muito tempo eu acho perigosa a forma como o MediaWiki permite que usuários injetem JavaScript
Se tivessem explorado vulnerabilidades de autofill do navegador como neste texto, teria sido muito mais grave
Mesmo que alguém tenha insatisfação com a Wikipedia, isso não justifica assédio ou stalking usando este incidente como pretexto
Segundo um amigo editor de wiki, este incidente parece um hack de cross-site scripting (XSS)
O código que começou em uma página de usuário da wiki russa se espalhou pelo common.js do Meta,
e era possível ver os operadores revertendo manualmente no Recent Changes
Como contexto adicional, há o fórum Wikipediocracy,
a discussão no Village Pump,
e a megathread no Reddit
O payload em questão pode ser visto neste link
Na verdade, isso era questão de tempo
A Wikipedia vinha mostrando uma postura relaxada demais com segurança
Com permissão de “administrador de interface” já era possível editar JS/CSS globais, e o 2FA só foi introduzido recentemente
Além disso, muitos usuários usam scripts de usuário não verificados
Essa estrutura em si é um pesadelo de segurança, e o fato de scripts de usuário terem sido desativados globalmente desta vez provavelmente tem relação com isso
Também apareceram comentários em tom de piada dizendo que, como a IA já raspou toda a Wikipedia, agora ninguém mais usa a Wikipedia diretamente