1 pontos por GN⁺ 2026-03-06 | 1 comentários | Compartilhar no WhatsApp
  • 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

 
GN⁺ 2026-03-06
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

    • É especialmente chocante que quem cometeu esse erro tenha sido um engenheiro de segurança
    • No começo parecia que havia um atacante ativo no momento, mas ao descobrir que era um script malicioso antigo, a solução ficou simples
      Bastava usar regex para detectar o script e reverter as páginas infectadas para uma versão anterior
    • Isso parece quase um caso do worm Samy
    • É difícil acreditar que uma organização de 300 milhões de dólares cometa um erro desses
    • Parece até que deve ter havido uma conversa tipo: “Claude, seu script executou malware!” “Sim, desculpa!”
  • 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

    • Parece ter uma motivação de brincadeira, do tipo “veja quanto caos eu consigo causar”
    • O domínio basemetrika.ru não existe. Retorna resposta NXDomain
    • Parece tentar XSS, mas na prática é código ineficaz, então não ocorre carregamento externo
    • Acho possível que um worm tão sofisticado tenha sido projetado por IA
  • 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

    • Mesmo que alguns dias de edições se perdessem, na escala da Wikipedia isso seria tolerável
    • Na prática, não foi um rollback do DB, e sim tratado com as ferramentas normais de reversão da wiki, e apenas o site Meta foi afetado, não a Wikipedia em si
  • 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

    • No ano passado, a ruwiki também sofreu vandalismo em larga escala de modo semelhante
  • Parece um velho worm de XSS
    Há muito tempo eu acho perigosa a forma como o MediaWiki permite que usuários injetem JavaScript

    • O mais surpreendente é que esse tipo de XSS ainda não tenha sido usado para ataques como roubo de senha
      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

    • Parece um “ataque vindo da Rússia”, mas forjar a origem desse jeito é muito fácil
    • Mas outro usuário acha muito provável que esse código seja uma variante da antiga ferramenta russa de hack “woodpecker
  • 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

    • A versão no Web Archive pode ser vista com segurança
    • Alguns links não abrem por falta de permissão de acesso
  • 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

    • No passado, até a página principal já foi apagada (link)
    • Atualmente há cerca de 137 administradores de interface, a maioria funcionários da Wikimedia, então ao menos são pessoas verificadas
    • Como a internet está se tornando um ambiente cada vez mais hostil, dá a sensação de que são necessárias doações ou apoio técnico para resolver esse tipo de problema
    • Scripts de usuário via extensões de navegador (como TamperMonkey) ainda existem, então o bloqueio total é impossível
    • Na wiki em inglês, de fato apenas 15 administradores de interface estão ativos (referência)
  • 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