Wikipedia pasó brevemente a modo de solo lectura y luego se recuperó tras una filtración masiva de cuentas de administradores

• Según la página de estado de la Fundación Wikimedia, el 5 de marzo de 2026 varios servicios wiki, incluida Wikipedia, pasaron temporalmente a modo de solo lectura
• Comenzó con una interrupción de acceso a las wikis y luego avanzó a una etapa en la que la función de edición quedó restringida
• No se especificó la causa, pero tras identificar el problema se iniciaron trabajos de corrección, y algunas funciones seguían desactivadas
• El 6 de marzo se restauró la funcionalidad de lectura y escritura, y también se reactivaron la mayoría de las funciones de scripts de usuario
• Wikimedia continúa verificando la estabilidad mediante monitoreo constante

---

Resumen del estado del sistema de Wikimedia

• En la página de estado, todos los sistemas aparecen funcionando normalmente (All Systems Operational)
  • Tanto la lectura como la edición figuran como Operational
  • Se registran 131,002 solicitudes por segundo, 0.08 errores de conexión reportados por usuarios, 1.27 respuestas de error de wiki, un tiempo de respuesta promedio de 0.20 segundos y 11.4 ediciones exitosas

Incidente del modo de solo lectura de las wikis del 5 al 6 de marzo de 2026

• El 5 de marzo, desde las 15:36 UTC, se reportaron problemas de acceso a algunas wikis
  • A las 16:11 UTC se reconoció el problema y comenzaron los trabajos de corrección
  • A las 17:09 UTC se indicó que la causa del problema había sido identificada y la corrección seguía en curso
  • A las 17:36 UTC se restauró el modo de lectura y escritura, aunque algunas funciones seguían desactivadas
  • A las 18:36 UTC se pasó a la etapa de monitoreo tras completar la corrección
• El 6 de marzo a las 00:05 UTC se informó que seguían monitoreando de forma continua
  • Después, el incidente se marcó como resuelto (Resolved) con el mensaje: “las wikis se mantuvieron en modo de lectura y escritura durante varias horas, y se restauró la mayoría de las funciones de scripts de usuario”

Otros incidentes relacionados a inicios de marzo de 2026

• El 3 de marzo se produjo un retraso en la edición por un problema en el servidor de base de datos, pero se resolvió el mismo día
  • El problema se identificó a las 10:09 UTC, la corrección se completó a las 10:17 UTC y pasó a monitoreo, y a las 10:24 UTC todo volvió a la normalidad
• Entre el 25 y el 26 de febrero se reportó una degradación del rendimiento de acceso a las wikis, y en ambos casos se corrigió y normalizó
• El 20 de febrero hubo demoras de conexión en la región europea, y tras identificar la causa, aplicar la corrección y monitorear, el problema quedó resuelto

Funciones de suscripción y notificación

• Los usuarios pueden recibir alertas sobre incidentes, actualizaciones y resoluciones mediante correo electrónico, Slack, Webhook y feeds Atom/RSS
• Al suscribirse por correo electrónico se aplican verificación OTP y protección reCAPTCHA
• La suscripción por Slack opera conforme a los Términos de Atlassian Cloud y la Política de Privacidad

Resumen

• Wikimedia sufrió varias veces a inicios de marzo incidentes de interrupción de la función de edición y degradación del rendimiento, pero todos fueron recuperados
• El cambio a modo de solo lectura del 5 al 6 de marzo fue el incidente más grande, y tras la corrección la mayoría de las funciones volvió a la normalidad
• Actualmente, todos los sistemas se mantienen en estado operativo normal

[GN⁺]

Comentarios en Hacker News

• Según el ticket público de Phabricator, un ingeniero de seguridad de la Wikimedia Foundation cargó scripts aleatorios de usuarios para hacer pruebas
  Uno de ellos era un script malicioso de ruwiki de hace 2 años, y este script se inyectó en el JS global, se propagó rápidamente y causó daños
  Al final, la situación fue tan grave que toda la wiki terminó cambiando a modo de solo lectura

  • Resulta especialmente impactante que quien cometió este error haya sido un ingeniero de seguridad
  • Al principio parecía que había un atacante activo, pero cuando se supo que era un script malicioso antiguo, resolverlo se volvió más sencillo
    Bastaba con usar expresiones regulares para detectar el script y revertir las páginas infectadas a versiones anteriores
  • Esto se parece casi a un caso del gusano Samy
  • Cuesta creer que una organización de 300 millones de dólares cometa un error así
  • Da la impresión de que debió haber habido una conversación tipo: “Claude, ¡tu script ejecutó malware!” “¡Sí, lo siento!”

• El modo de operación de este gusano es interesante
  Se inyecta en Common.js y User:Common.js de MediaWiki para mantener una infección global, y oculta rastros de la infección con jQuery
  Vandaliza 20 documentos aleatorios y, si infecta una cuenta de administrador, elimina documentos con la función Special:Nuke

  • Parece tener una motivación más bien de broma, como de “miren cuánto caos puedo causar”
  • El dominio basemetrika.ru no existe. Responde con NXDomain
  • Parece intentar hacer XSS, pero en realidad es código ineficaz, así que no se produce ninguna carga externa
  • Algunos creen que es posible que un gusano tan sofisticado haya sido diseñado por IA

• Se dijo que, como la propia base de datos era el vector de infección, la limpieza sería una pesadilla de forense digital
  Pero no se comprometieron privilegios de root, así que si hay respaldos parece posible recuperarse

  • Aunque se perdieran algunos días de ediciones, a escala de Wikipedia entera sería algo tolerable
  • En la práctica no se hizo un rollback de la DB, sino que se resolvió con las herramientas normales de reversión de wiki, y solo se vio afectado el sitio Meta, no Wikipedia en sí

• Según la investigación en la comunidad de la wiki rusa, parece que esta vez se reutilizó código que ya se había usado en ataques de vandalismo contra wikis alternativas en ruso en 2023
  El script era test.js, creado por el usuario de ruwiki Ololoshka562,
  y se estima que se ejecutó cuando el empleado de WMF sbassett cargó ese script durante una prueba

  • El año pasado ruwiki ya había sufrido una vandalización masiva de forma parecida

• Parece un gusano XSS de la vieja escuela
  Desde hace tiempo algunos pensaban que era riesgoso que MediaWiki permitiera a los usuarios inyectar JavaScript

  • Lo sorprendente es que este tipo de XSS todavía no se haya usado para ataques como robo de contraseñas
    Si se hubiera aprovechado una vulnerabilidad del autocompletado del navegador como en este texto, habría sido mucho más grave

• Aunque uno tenga quejas sobre Wikipedia, eso no justifica usar este incidente como pretexto para acoso o stalking

• Según un amigo editor de wikis, este incidente parece un hack de cross-site scripting (XSS)
  El código comenzó en una página de usuario de la wiki en ruso y se propagó por common.js de Meta,
  y se podía ver a los operadores revertiendo manualmente los cambios en la página de Recent Changes

  • Puede parecer un “ataque venido de Rusia”, pero falsificar el origen de esa manera es muy fácil
  • Sin embargo, otro usuario cree que probablemente este código sea una variante de la vieja herramienta de hackeo rusa “woodpecker”

• Como contexto adicional, están el foro de Wikipediocracy,
  la discusión en Village Pump,
  y el megahilo de Reddit, entre otros
  El payload en cuestión puede verse en este enlace

  • La versión archivada en la web se puede ver de forma segura
  • Algunos enlaces no se abren por restricciones de acceso

• En realidad, algo así era cuestión de tiempo
  Wikipedia ha mostrado una actitud demasiado relajada hacia la seguridad
  Con solo tener permisos de “administrador de interfaz” se puede modificar el JS/CSS global, y el 2FA recién se introdujo hace poco
  Además, muchos usuarios usan scripts de usuario no verificados
  Esa estructura en sí ya es una pesadilla de seguridad, y probablemente por eso ahora se deshabilitaron globalmente los scripts de usuario

  • Antes incluso llegaron a borrar la página principal (enlace)
  • Actualmente hay unos 137 administradores de interfaz, la mayoría empleados de Wikimedia, así que al menos son personas más o menos verificadas
  • Como internet se está volviendo un entorno cada vez más hostil, da la sensación de que hacen falta donaciones o apoyo técnico para resolver este tipo de problemas
  • Los scripts de usuario vía extensiones del navegador (como TamperMonkey) siguen existiendo, así que un bloqueo total es imposible
  • De hecho, en la Wikipedia en inglés solo hay 15 administradores de interfaz activos (referencia)

• También salió el comentario, medio en broma, de que como la IA ya raspó toda Wikipedia, ahora nadie usa Wikipedia directamente