Skip to main content
Blog
Blog

Inversiones de bits por rayos cósmicos y el riesgo oculto a escala

Cuando un evento con probabilidad de uno en un millón resulta no ser tan raro. Cómo nuestra atmósfera convierte ceros en unos y cómo eso puede afectar a la seguridad.

Aug 08, 2025 Actualizado Jul 19, 2026 7 min read
blog-cover-cosmic-ray-bit-flips
Tabla de Contenidos

Resumen: bit flips por rayos cósmicos

  • Los rayos cósmicos causan single-event upsets (SEUs) que voltean bits en memoria a un ritmo de aproximadamente uno por gigabyte por mes a nivel del mar. A escala planetaria, no es una curiosidad rara.
  • Incidentes famosos de bit flip incluyen un elector belga contado incorrectamente por 4.096 votos (2003), y el skip 'Upwarp' en el speedrun de Super Mario 64 causado por un solo bit volteado. Ambos son consistentes con la probabilidad SEU de rayos cósmicos según duración de exposición.
  • A escala de aplicación web, los bit flips por rayos cósmicos son una de las pequeñas causas residuales de bugs no reproducibles. Memoria ECC, almacenamiento con checksum y manejo idempotente de peticiones son las mitigaciones prácticas.

¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.

En 2013, el speedrunner competitivo de Super Mario 64 DOTA_Teabag estaba recorriendo Tick Tock Clock, un nivel tristemente célebre por castigar incluso a los mejores jugadores debido a una secuencia de saltos especialmente exigente. En medio de la partida, Mario de repente salió disparado hacia arriba a través del suelo, saltándose una sección completa del nivel y ahorrándole a DOTA_Teabag unos valiosos segundos.

Vídeo del incidente de inversión de bits en Super Mario 64

TTC Upwarp: Ceiling Warp vs Byte Change

La comunidad de speedrunning, que llevaba décadas jugando y diseccionando Super Mario 64, quedó atónita. Se ofreció una recompensa para reproducir el glitch; algunos speedrunners afirmaron que DOTA_Teabag había "sacudido el cartucho" (una técnica para provocar glitches de forma predecible en juegos de Nintendo 64 modificando ligeramente el ángulo del cartucho). El misterio se resolvió cuando el youtuber y reconocido cazador de glitches pannenkoek12 (traducido como 'Pancake12') descubrió que un único bit en la memoria de la Nintendo 64 era el responsable. La inversión de bit ocurrió en 0xC5837800, la dirección de memoria encargada de la posición vertical de Mario. El cambio en binario fue de 1100 0101 a 1100 0100, y por una casualidad extraordinaria, era exactamente el cambio necesario para teletransportar a Mario a una plataforma superior.

¿Qué causó todo esto? Todo apunta a una inversión de bit por rayo cósmico: un error aleatorio en chips informáticos provocado por una partícula de alta energía procedente del espacio que, en un momento concreto, afecta a un sistema.

Ilustración de una inversión de bit por rayo cósmico impactando un chip de memoria de un ordenador

¿Qué es una inversión de bit por rayo cósmico?

Una inversión de bit por rayo cósmico (también conocida como "single-event upset" o SEU) ocurre cuando una partícula ionizante procedente de un rayo cósmico del espacio impacta en una celda de memoria o transistor individual, invirtiendo un bit binario de 0 a 1, o de 1 a 0. Estas inversiones de bits pueden provocar un error transitorio que no deja daño físico en el hardware, pero sí puede alterar datos almacenados en memoria o en la lógica del sistema, modificando el comportamiento de las aplicaciones o incluso desactivando funciones de seguridad.

La speedrun de Super Mario 64 no es el único caso documentado de un evento cósmico con efectos en la Tierra. Durante las elecciones belgas de 2003, una candidata desconocida recibió exactamente 4.096 votos extra de la nada en las máquinas de votación electrónica del país. El error solo se detectó porque recibió más votos que el número total de votantes, lo que era matemáticamente imposible.

Tras la investigación, los investigadores concluyeron que un rayo cósmico había invertido un único bit en la posición 13 de la memoria de la máquina de votación, otorgándole a la candidata 4.096 votos adicionales [1]. En binario, cada bit duplica el valor, por lo que el bit en esa posición equivale a 2^12, es decir, exactamente 4.096.

Raro no significa imposible, especialmente a escala

Las inversiones de bits por rayos cósmicos son increíblemente raras a nivel de bit individual, pero no son imposibles. En 1996, investigadores de IBM estimaron que un ordenador de escritorio típico con 256 megabytes de RAM podría experimentar una inversión de bit inducida por rayos cósmicos aproximadamente una vez al mes. Avanzando hasta hoy, donde los sistemas modernos suelen funcionar con 16 gigabytes de RAM (¡62,5 veces más que en el estudio!), el riesgo escala en consecuencia. Combinado con los millones de rayos cósmicos que impactan en la Tierra cada segundo, es solo cuestión de tiempo que uno golpee el bit equivocado en el momento equivocado. Investigadores de la Universidad de Vanderbilt pudieron confirmarlo, afirmando en su investigación que una granja de routers de un proveedor de servicios de internet con 25 gigabytes de memoria podría experimentar una inversión de bit cada 17 horas [2].

La conclusión clave es que un evento "de uno en un millón" ocurrirá a diario si se realizan más de un millón de operaciones al día. En cside, analizamos aproximadamente más de 10 millones de scripts cada 24 horas en busca de comportamientos maliciosos. Aunque una inversión de bit tenga una probabilidad de uno en cien millones, operar a ese volumen convierte esas probabilidades aparentemente imposibles en algo perfectamente posible.

Si bien la memoria de grado empresarial puede estar protegida frente a las inversiones de bits por rayos cósmicos mediante la adopción de memoria con corrección de errores (ECC), capaz de detectar y corregir errores de un solo bit, el hardware de consumo generalmente no cuenta con esa protección. Es importante entender que "raro" en un mundo donde se producen millones de operaciones significa que es solo cuestión de tiempo.

Endurecimiento cósmico y resiliencia como principio de diseño

Dado que las inversiones de bits cósmicos son una cuestión de estadística, ¿cómo se pueden construir sistemas que anticipen lo inesperado? La respuesta está en diseñar para la tolerancia a fallos. Por ejemplo, las naves espaciales de la NASA ejecutan los cálculos críticos por triplicado: varios procesadores realizan la misma operación y, si uno discrepa debido a una inversión de bit, los otros dos lo anulan por mayoría. En la Tierra, la memoria ECC puede desempeñar un papel importante en la protección de routers, servidores e infraestructura en la nube frente a errores de un solo bit (¡e incluso detectar errores de dos bits en algunos casos!). Pero como todo, la memoria ECC tiene sus propias limitaciones. Normalmente no protege los registros de la CPU, la memoria de la GPU ni los búferes de red. Incluso en entornos empresariales equipados con memoria ECC, las inversiones de múltiples bits o los fallos a nivel lógico pueden pasar desapercibidos. Por eso es fundamental contar con una estrategia de resiliencia por capas. En cside, aplicamos la misma filosofía a la seguridad del lado del cliente. Aunque un script malformado o un exploit en un caso límite puedan ser raros de forma individual, analizar millones de archivos JavaScript a diario significa que, en conjunto, no lo son en absoluto.

En definitiva, las inversiones de bits por rayos cósmicos nos recuerdan que, a escala, trabajamos con probabilidades, no con certezas. Un evento de uno en un millón se vuelve inevitable cuando los sistemas procesan mil millones de operaciones a la vez. Ya sea que estés construyendo una base de datos, un sistema de votación o un proxy de navegador del lado del cliente, la lección es siempre la misma: planifica para todas las posibilidades. En el lado del cliente, la imprevisibilidad escala con el volumen. Por eso, tus sistemas deben construirse asumiendo que nada es inmune al fallo, y diseñarse para resistir incluso las anomalías más improbables, de escala cósmica.

Referencias:

[1] https://web.archive.org/web/20070927185155/http://wiki.ael.be/index.php/ElectronicVotingRandomSpontaneousBitInversionExplained

[2] https://www.independent.co.uk/news/science/subatomic-particles-cosmic-rays-computers-change-elections-planes-autopilot-a7584616.html

Jack LaFond
Security Researcher

I'm a security engineer + security researcher at cside.

FAQ

Frequently Asked Questions

Un evento singular, o SEU, es un error transitorio en el que una partícula de alta energía, a menudo procedente de un rayo cósmico, impacta una celda de memoria o un transistor y cambia un único bit binario de 0 a 1 o de 1 a 0. No deja daño físico en el hardware, pero puede corromper datos almacenados o alterar la lógica de forma silenciosa, cambiando el comportamiento de una aplicación o incluso desactivando una función de seguridad hasta que la memoria afectada se reescribe.

Por bit son extremadamente raros, pero la tasa agregada no es insignificante. Una estimación aproximada del sector la sitúa cerca de un cambio por gigabyte de RAM al mes a nivel del mar. Investigadores de IBM calcularon que un ordenador de mediados de los noventa con 256 MB de memoria podía experimentar alrededor de uno al mes, y la Universidad de Vanderbilt halló que una granja de routers con 25 GB podía sufrir uno cada 17 horas aproximadamente. Más memoria y más máquinas significan más cambios en total.

No. La memoria con código de corrección de errores (ECC) detecta y corrige la mayoría de los errores de un solo bit y puede señalar algunos de dos bits, lo que la hace valiosa para servidores, routers e infraestructura en la nube. Pero normalmente no cubre los registros de la CPU, la memoria de la GPU ni los búferes de red, y los fallos de varios bits o de nivel lógico pueden escaparse. El hardware de consumo suele no tener ECC en absoluto. La ECC es una capa de defensa importante, no una garantía completa frente a todo error transitorio.

Se diseñan para tolerar fallos en lugar de suponer un hardware perfecto. Las medidas habituales incluyen memoria ECC, almacenamiento con sumas de verificación o hash que detecta la corrupción al leer, gestión idempotente de solicitudes para que una operación repetida no cuente dos veces, y cómputo redundante. Las naves de la NASA, por ejemplo, ejecutan cálculos críticos en varios procesadores y dejan que dos coincidentes superen en votos a un tercero discrepante. El objetivo es detectar y recuperarse de los errores, no fingir que nunca ocurren.

Asume que, con suficiente volumen, algo acabará fallando, y construye para detectarlo en lugar de intentar prevenir cada caso posible. Los patrones prácticos incluyen validar entradas y salidas, aplicar sumas de verificación a los datos en tránsito y en reposo, hacer idempotentes las escrituras, registrar suficiente contexto para investigar un evento aislado y monitorizar anomalías que no puedes reproducir a voluntad. Un evento entre un millón se vuelve rutinario cuando un sistema ejecuta millones de operaciones al día, así que la resiliencia supera a perseguir la certeza.

Depende de dónde esté tu riesgo. La memoria ECC es el primer paso para servidores e infraestructura de larga duración que mantienen estado en RAM. Las sumas de verificación y los hashes importan más para datos que se mueven o persisten, ya que detectan corrupción que la ECC no puede ver una vez que los datos salen de la memoria. El cómputo redundante encaja en cálculos críticos para la seguridad que no pueden fallar en silencio. La mayoría de los sistemas maduros combinan los tres en capas en lugar de elegir uno, porque cada uno cubre un hueco que los otros dejan abierto.

Son una causa residual pequeña, muy por detrás de las condiciones de carrera, los errores de memoria, las pruebas inestables y las diferencias de entorno. Persigue primero las explicaciones comunes. Considera un error transitorio de hardware solo después de haber descartado fallos de software reproducibles y de confirmar que el síntoma es un único cambio de bit no recurrente, coherente con la probabilidad de SEU en tu exposición. A escala planetaria, sin embargo, ese pequeño residual sigue apareciendo con regularidad, así que no lo descartes por completo.

cside escanea aproximadamente más de 10 millones de scripts cada 24 horas, por lo que se construye sobre la misma premisa que describe este artículo: a ese volumen, los fallos raros son inevitables y hay que detectarlos en lugar de ignorarlos. La plataforma trata un script malformado o un exploit de caso límite como algo que aparecerá en conjunto aunque cada caso individual sea improbable, y su canal de escaneo está diseñado para señalar comportamientos anómalos de scripts de terceros en lugar de confiar en que cada entrada esté bien formada.

Sí, ese es el núcleo del diseño. cside obtiene y analiza los scripts de terceros por su lado y aplica hash a las cargas útiles de la sesión real, de modo que un cambio que solo se activa en condiciones concretas sigue apareciendo como una diferencia respecto a la versión conocida como buena. Como un comportamiento entre un millón se vuelve común con millones de scripts al día, la plataforma asume que los casos límite ocurrirán y está construida para sacarlos a la luz en lugar de muestrear un subconjunto y confiar en que el resto esté limpio.

cside se despliega como una única etiqueta JavaScript de origen propio, o mediante el Scan Method sin agente, sin cambios de DNS. No se sitúa delante de tu tráfico ni enruta ni actúa como proxy de tus visitantes. En su lugar, obtiene y analiza los scripts de terceros en la infraestructura de cside y lee el comportamiento del script en la sesión real, de modo que el análisis pesado ocurre del lado de cside mientras tus páginas siguen cargando con normalidad para tus usuarios.

Añades una etiqueta JavaScript ligera de origen propio a tu sitio, sin cambios de DNS y sin enrutar nada a través de cside. Si prefieres no añadir ningún script, el Scan Method sin agente puede monitorizar tus páginas de forma externa. A partir de ahí, cside obtiene y analiza tus scripts de terceros y vigila su comportamiento en la sesión real en busca de manipulación o skimming, de modo que la cobertura del lado del cliente empieza rápido sin rediseñar cómo tu sitio sirve el tráfico a los visitantes.

cside se cobra por uso, normalmente según el volumen de sesiones o de páginas vistas, con niveles que escalan a medida que crece tu tráfico y un plan gratuito para empezar. No hay cargos ligados a añadir un cambio de DNS o un proxy, porque cside no usa ninguno de los dos. Para un presupuesto ajustado a tu tráfico y a la cobertura que necesitas, lo mejor es hablar con el equipo de cside en lugar de adivinar a partir de un precio de lista fijo.

Monitoriza y protege tus scripts de terceros

Gain full visibility and control over every script delivered to your users to enhance site security and performance.

Empieza gratis o prueba Business con una versión de prueba de 14 días.

Interfaz del panel de cside que muestra la monitorización de scripts y el análisis de seguridad
Related Articles
Reservar una demo

¿Quieres verlo en detalle con un ingeniero?

Treinta minutos, sobre tu propio sitio. Nada de diapositivas.

Reserva una demo personalizada para ver:

Cómo cumplir los requisitos 6.4.3 y 11.6.1 de PCI DSS en 1 día
Por qué los scripts de terceros son un riesgo de seguridad para ti y tus visitantes
Cómo monitorizar fugas de privacidad y consentimiento (RGPD, CCPA) en cada tercero
Cómo frenar el abuso de registros, el uso compartido de cuentas y el fraude de contracargos con device intelligence
Cómo detectar y controlar agentes de IA y bots que llegan a tu sitio en tiempo real

¿Prefieres mandarnos una pregunta?

Buscando huecos libres…

Solo humanos de verdad. Nos daríamos cuenta.

¿Problemas para reservar? Abrir el calendario en una pestaña nueva

¿Qué quieres resolver?

Cuéntanoslo en una línea y te responderemos con algo útil, no con un discurso genérico.

Solemos ayudar con:

Ver qué scripts de terceros se ejecutan en tu sitio
Evidencias para PCI DSS 6.4.3 y 11.6.1
Bots, agentes de IA y robo de cuentas

¿Prefieres reservar una hora? Elegir un hueco