Wikipedia En Alerta Un Gusano Que Se Replica Al Modificar Scripts De Usuario

Esta mañana la comunidad de Wikimedia y miles de usuarios alrededor del mundo se despertaron con una noticia inquietante: un script malicioso que se autorreplicaba llegó a ejecutarse dentro de la infraestructura de los proyectos y comenzó a insertar código oculto y a modificar scripts de usuario en múltiples wikis. Los primeros avisos vinieron del Village Pump (technical) de Wikipedia, donde editores detectaron una oleada de ediciones automáticas que añadían fragmentos de JavaScript invisible y vandalismo en páginas al azar.

Lo que ocurrió, explicado en términos sencillos: MediaWiki —el software que mueve Wikipedia y cientos de wikis relacionadas— permite que tanto los administradores como los editores registrados carguen pequeños archivos JavaScript para personalizar la experiencia del sitio. Estos ficheros pueden ser globales (por ejemplo, MediaWiki:Common.js) o específicos de cada usuario (por ejemplo, User:TuNombre/common.js). El problema es que, si un actor malicioso consigue que se ejecute un código con privilegios de edición, puede alterar esos ficheros y provocar que el código se ejecute en los navegadores de otros usuarios, propagando así la infección.

Según el registro público de seguimiento del incidente en el sistema de incidencias de la Fundación Wikimedia (Phabricator), la cadena de eventos parece haberse iniciado cuando un script alojado en la Wikipedia en ruso fue invocado y, desde ahí, se modificó un script global con código dañino. Una copia archivada del script problemático está disponible en la memoria web: archivo del test.js.

Mecanismo de propagación: el script malicioso trabajaba en tres frentes simultáneos. Primero intentaba añadir un “loader” en el archivo de JavaScript personal del usuario que lo hubiese ejecutado, de modo que la próxima vez que ese usuario navegara conectado, cargaría el código dañino desde su espacio personal. Segundo, si ese usuario disponía de los permisos adecuados, el script trataba de modificar el MediaWiki:Common.js global para que el código se ejecutara para todo aquel que use ese script compartido. Y tercero, el worm incluía una rutina de vandalismo que elegía páginas al azar (a través de Special:Random) para insertar una imagen y un bloque oculto que cargaba el código externo desde una URL maliciosa.

La combinación de estos tres vectores es lo que convierte el incidente en particularmente peligroso: un único navegador afectado puede convertirse en semilla para una infección que se replica en otros usuarios y, si alcanza el script global, en todo el proyecto.

Los primeros análisis públicos replicados por medios de seguridad indican que el gusano llegó a modificar miles de páginas y decenas de scripts de usuario. El recuento provisional que circuló sitúa las ediciones en torno a 3.996 páginas afectadas y cerca de 85 usuarios que vieron su common.js sobreescrito. Durante la respuesta inmediata, el equipo técnico de la Fundación limitó temporalmente la posibilidad de editar en diversos proyectos para detener la propagación mientras revertían cambios y limpiaban referencias al código inyectado.

Durante la fase de contención, el personal de la Fundación también realizó restauraciones masivas del common.js de varios usuarios y “suprimió” las páginas modificadas para que los cambios maliciosos no quedaran visibles en los historiales públicos. En el momento en que esto se escribe, el código inyectado ha sido eliminado y la edición ha sido restablecida, pero subsisten dudas claves: la Fundación aún no ha publicado un informe post incidente detallado que clarifique cómo se ejecutó exactamente el script y si la ejecución fue accidental, fruto de una prueba, o el resultado de una cuenta comprometida.

Por qué este incidente nos debería preocupar: más allá del vándalismo, un gusano de este tipo tiene implicaciones de seguridad serias. Puede servir como vector para robar tokens de sesión, realizar acciones en nombre de los usuarios afectados, introducir enlaces o scripts que redirijan a servidores externos con fines de seguimiento o carga de malware, y socavar la confianza en el contenido de los proyectos. Además, la naturaleza distribuida y abierta de Wikipedia complica las medidas automáticas de defensa: muchas protecciones se construyen sobre la confianza entre editores y en controles manuales que requieren horas de trabajo humano.

También es relevante el hecho de que el script albergaba código que lo vinculaba con campañas anteriores, lo que sugiere que no se trató de un experimento inofensivo sino de un patrón que se ha visto antes en el ecosistema wiki, según reportes que han rastreado scripts similares en otros incidentes.

Qué pueden hacer los usuarios ahora: si has editado wikis de Wikimedia recientemente y corres el riesgo de haber cargado el script, revisa tu página de usuario (especialmente User:TuNombre/common.js), elimina cualquier código sospechoso y restablece scripts oficiales desde copias de confianza. Considera cambiar contraseñas y habilitar autenticación de dos factores cuando esté disponible. La documentación técnica de MediaWiki sobre JavaScript de usuario es un buen punto de partida para entender qué archivos pueden ejecutarse en tu navegador: Manual: JavaScript (MediaWiki).

Para la comunidad y los mantenedores del software, el episodio debería impulsar una reflexión profunda sobre la necesidad de controles adicionales alrededor de las páginas que ejecutan código en los navegadores de los editores: revisión obligatoria de cambios en scripts globales, mejor telemetría para detectar cargas inusuales, y procesos más estrictos para ejecutar y probar scripts en entornos aislados antes de activarlos en vivo.

Transparencia y lecciones pendientes: la respuesta técnica inmediata detuvo la propagación, pero la ausencia de un informe técnico completo dificulta saber si hubo acceso no autorizado a cuentas de personal, si falta mejorar los permisos y procesos de prueba interna, o si hay vulnerabilidades en herramientas de edición que deben parchearse. La comunidad merece una investigación pública y documentada que explique las causas raíz y las medidas correctoras propuestas. Mientras tanto, herramientas de terceros y medios especializados como BleepingComputer han publicado análisis preliminares que ayudan a contextualizar el ataque, y el registro de incidencias en Phabricator sirve como fuente primaria para el seguimiento por parte de técnicos y voluntarios.

Este incidente recuerda que, en proyectos abiertos y colaborativos de gran escala, la seguridad no es solo responsabilidad de los administradores sino un esfuerzo colectivo: protocolos claros para pruebas internas, auditorías de código, procedimientos de respuesta y comunicación transparente son componentes imprescindibles. La comunidad, los desarrolladores y la Fundación deberán trabajar juntos para cerrar las brechas y restaurar la confianza.

Si participas como editor en cualquier wiki de Wikimedia y detectas comportamientos extraños —redirecciones inesperadas, scripts ocultos en tus páginas de usuario, ediciones masivas no autorizadas—, notifícalo inmediatamente en los canales de soporte técnico de la comunidad (por ejemplo, Village Pump (technical)) y sigue las directrices oficiales que publique la Fundación. Para seguir la investigación y los anuncios oficiales, revisa el seguimiento en Phabricator y la página de estado de Wikimedia en status.wikimedia.org.

La historia no termina con la eliminación del código: queda por ver el informe post incidente, las medidas concretas que adopte la Fundación y cómo evolucionarán las prácticas de seguridad en una de las plataformas colaborativas más visitadas del planeta. Mientras tanto, la lección es clara: en la web abierta, la confianza debe ir acompañada de controles técnicos y procesos que minimicen el impacto de fallos y malos actores.