Skip to main content
Blog
Blog

Kosmische straling, bitflips en het verborgen risico op schaal

Wanneer een kans van één op een miljoen toch niet zo zeldzaam blijkt te zijn. Hoe onze atmosfeer nullen en enen omzet en wat dat betekent voor beveiliging.

Aug 08, 2025 Bijgewerkt Jul 19, 2026 6 min read
blog-cover-cosmic-ray-bit-flips
Inhoudsopgave

Kort samengevat: cosmic ray bit flips

  • Kosmische straling veroorzaakt single-event upsets (SEU's) die bits in geheugen omdraaien met een frequentie van ongeveer één per gigabyte per maand op zeeniveau. Op planeetschaal is dit geen zeldzame curiositeit.
  • Beroemde bit-flip-incidenten omvatten een Belgische kiezer die 4.096 stemmen te veel toegewezen kreeg (2003) en de 'Upwarp'-skip in de Super Mario 64-speedrun veroorzaakt door één omgedraaide bit. Beide zijn consistent met de SEU-waarschijnlijkheid van kosmische straling bij de blootstellingsduur.
  • Op webapplicatieschaal zijn cosmic-ray bit flips een van de kleine restoorzaken van niet-reproduceerbare bugs. ECC-geheugen, checksummed-storage en idempotente request-handling zijn de praktische mitigaties.

Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.

In 2013 was de competitieve Super Mario 64-speedrunner DOTA_Teabag bezig met Tick Tock Clock, een level dat berucht is omdat het zelfs de beste spelers genadeloos afstraft door een reeks lastige sprongen. Terwijl hij zijn weg zocht door het level, schoot Mario plotseling recht omhoog door de vloer, waarmee een heel gedeelte van het level werd overgeslagen en DOTA_Teabag kostbare seconden won.

Video over het Super Mario 64-bitflipincident

TTC Upwarp: Ceiling Warp vs Byte Change

De speedrunningcommunity, die al tientallen jaren Super Mario 64 speelt en tot op de bodem uitzoekt, stond versteld. Er werd een beloning uitgeloofd om de glitch te reproduceren; sommige speedrunners beweerden dat DOTA_Teabag de cartridge had "geschud" (een manier om een Nintendo 64-spel soms voorspelbaar te glitchen door de hoek van de gamecartridge licht te veranderen). Het mysterie werd opgelost toen YouTuber en gerenommeerd videogame-glitchjager pannenkoek12 (vertaald 'Pancake12') ontdekte dat één enkele bit in het geheugen van de Nintendo 64 de oorzaak was. De bitflip vond plaats op 0xC5837800, het adres dat verantwoordelijk is voor Mario's verticale positie. De binaire waarde veranderde van 1100 0101 naar 1100 0100, en door buitengewoon geluk was dit precies de verandering die nodig was om Mario naar een hoger platform te teleporteren.

Wat veroorzaakte dit in de eerste plaats? Alle aanwijzingen wijzen op een kosmische-straling-bitflip: een willekeurige fout in computerchips, veroorzaakt door een hoogenergetisch deeltje uit de ruimte dat op precies het verkeerde moment een systeem raakt.

Illustratie van een kosmische-straling-bitflip die een geheugenchip van een computer raakt

Wat is een kosmische-straling-bitflip?

Een kosmische-straling-bitflip (ook wel een "single-event upset" of SEU genoemd) treedt op wanneer een losgeslagen ioniserend deeltje van kosmische straling uit de ruimte een enkele geheugencel of transistor raakt en een binaire bit omzet van 0 naar 1, of van 1 naar 0. Deze bitflips kunnen een zachte fout veroorzaken die geen fysieke schade aan de hardware achterlaat, maar wel opgeslagen data in het geheugen of logica kan wijzigen, waardoor het gedrag van applicaties verandert of zelfs beveiligingsfuncties worden uitgeschakeld.

De Super Mario 64-speedrun is niet het enige gedocumenteerde geval waarbij een kosmische gebeurtenis gevolgen had op aarde. Tijdens de Belgische verkiezingen van 2003 ontving een onbekende kandidaat plotseling exact 4.096 extra stemmen op de elektronische stemmachines van het land, schijnbaar uit het niets. De fout werd alleen ontdekt omdat ze meer stemmen had ontvangen dan het aantal kiezers, wat wiskundig onmogelijk is.

Na onderzoek concludeerden onderzoekers dat een kosmische straal een enkele bit op positie 13 in het geheugen van de stemmachine had omgeklapt, waardoor de kandidaat 4.096 extra stemmen kreeg [1]. In binaire getallen verdubbelt elke bit de waarde, dus de bit op die positie werd berekend als 2^12, ofwel precies 4.096.

Zeldzaam betekent niet onmogelijk, zeker niet op schaal

Kosmische-straling-bitflips zijn ongelooflijk zeldzaam per bit, maar ze zijn niet onmogelijk. In 1996 schatten onderzoekers van IBM dat een gemiddelde desktop met 256 megabyte RAM mogelijk één kosmisch-straling-geïnduceerde bitflip per maand kon ervaren. Spoel door naar vandaag, waar moderne systemen doorgaans draaien met 16 gigabyte RAM (62,5 keer meer dan in de studie!), en het risico schaalt dienovereenkomstig. Combineer dat met miljoenen kosmische stralen die elke seconde de aarde raken, en het is slechts een kwestie van tijd voordat er één de verkeerde bit op het verkeerde moment raakt. Onderzoekers aan de Vanderbilt University bevestigden dit: hun onderzoek wees uit dat een routerpark van een internetprovider met 25 gigabyte geheugen tot wel elke 17 uur een bitflip kan ervaren [2].

Een "één op een miljoen"-gebeurtenis zal dagelijks plaatsvinden als je dagelijks meer dan een miljoen dingen doet. Bij cside scannen we dagelijks ruwweg meer dan 10 miljoen scripts op kwaadaardig gedrag. Zelfs als een bitflipfout een kans van één op 100 miljoen heeft, betekent scannen op dat volume dat deze onmogelijk lijkende kansen in werkelijkheid heel reëel zijn.

Hoewel geheugen van enterprise-kwaliteit dankzij de adoptie van foutcorrigerend geheugen (error-code correcting memory), dat enkelbitsfouten vaak kan detecteren en corrigeren, mogelijk niet meer vatbaar is voor kosmische-straling-bitflips, is consumentenhardware doorgaans niet beschermd. In een wereld waarin miljoenen acties plaatsvinden, betekent 'zeldzaam' simpelweg dat het slechts een kwestie van tijd is.

Kosmische weerbaarheid en het omarmen van veerkracht

Gegeven dat kosmische bitflips een kwestie van statistiek zijn, hoe bouw je systemen die het onverwachte verwachten? Het antwoord ligt in het ontwerpen voor fouttolerantie. NASA-ruimtevaartuigen voeren kritieke berekeningen bijvoorbeeld drievoudig uit: meerdere processors voeren dezelfde operatie uit, en als één daarvan door een losgeslagen bitflip afwijkt, stemmen de andere twee het proces weg. Dichter bij huis kan ECC-geheugen een rol spelen bij het beschermen van routers, servers en cloudinfrastructuur tegen enkelbitsfouten (en soms zelfs tweebitsfouten detecteren!). Maar zoals alles heeft ECC-geheugen zijn eigen beperkingen. Het beschermt doorgaans niet het CPU-register, het GPU-geheugen of de netwerkbuffers. Zelfs in enterprise-omgevingen met ECC-geheugen kunnen meerbitsflips of fouten op logicaniveau onopgemerkt blijven. Daarom is een gelaagde veerkrachtstrategie belangrijk. Bij cside passen we dezelfde filosofie toe op client-side beveiliging. Ook al is een misvormd script of een edge-case exploit individueel zeldzaam, het dagelijks scannen van miljoenen JavaScript-bestanden betekent dat ze in totaal niet zeldzaam zijn.

Op schaal zijn kosmische-straling-bitflips een kwestie van waarschijnlijkheid, niet van zekerheid. Een kans van één op een miljoen wordt onvermijdelijk zodra een systeem miljarden operaties uitvoert, of dat systeem nu een database, een verkiezingsmachine of een client-side browser is. Aan de client-side schaalt onvoorspelbaarheid met volume, dus beveiligingssystemen moeten ervan uitgaan dat er uiteindelijk iets misgaat, en zo gebouwd zijn dat ze dat opvangen wanneer het gebeurt.

Referenties:

[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

Een single-event upset, of SEU, is een zachte fout waarbij een hoogenergetisch deeltje, vaak afkomstig van kosmische straling, een geheugencel of transistor raakt en een enkele binaire bit omdraait van 0 naar 1 of van 1 naar 0. Het laat geen fysieke schade aan de hardware achter, maar het kan opgeslagen data stil beschadigen of logica veranderen, waardoor een applicatie zich anders gedraagt of zelfs een beveiligingsfunctie wordt uitgeschakeld totdat het getroffen geheugen wordt overschreven.

Per bit zijn ze uiterst zeldzaam, maar het totale tempo is niet triviaal. Een ruwe schatting uit de sector legt het rond één wisseling per gigabyte RAM per maand op zeeniveau. IBM-onderzoekers schatten dat een desktop uit het midden van de jaren negentig met 256 MB geheugen er ongeveer één per maand kon zien, en de Vanderbilt University stelde vast dat een routerpark van 25 GB er ongeveer elke 17 uur één kon meemaken. Meer geheugen en meer machines betekenen in totaal meer wisselingen.

Nee. Geheugen met foutcorrigerende code (ECC) detecteert en corrigeert de meeste fouten van één bit en kan sommige fouten van twee bits signaleren, wat het waardevol maakt voor servers, routers en cloudinfrastructuur. Maar het dekt doorgaans niet de CPU-registers, het GPU-geheugen of de netwerkbuffers, en fouten van meerdere bits of op logisch niveau kunnen erlangs glippen. Consumentenhardware heeft meestal helemaal geen ECC. ECC is één belangrijke verdedigingslaag, geen volledige garantie tegen elke zachte fout.

Ze worden ontworpen voor fouttolerantie in plaats van uit te gaan van perfecte hardware. Gangbare maatregelen zijn ECC-geheugen, opslag met checksums of hashes die corruptie bij het lezen opvangt, idempotente verwerking van verzoeken zodat een herhaalde bewerking niet dubbel telt, en redundante berekening. NASA-ruimtevaartuigen voeren kritieke berekeningen bijvoorbeeld uit op meerdere processoren en laten twee die het eens zijn een derde die afwijkt overstemmen. Het doel is fouten detecteren en herstellen, niet doen alsof ze nooit voorkomen.

Ga ervan uit dat bij voldoende volume er uiteindelijk iets fout gaat, en bouw om het op te vangen in plaats van elk mogelijk geval te voorkomen. Praktische patronen zijn het valideren van invoer en uitvoer, checksums op data onderweg en in rust, idempotente schrijfacties, genoeg context loggen om een eenmalige gebeurtenis te onderzoeken, en monitoren op afwijkingen die je niet op verzoek kunt reproduceren. Een gebeurtenis van één op een miljoen wordt routine zodra een systeem miljoenen bewerkingen per dag uitvoert, dus veerkracht wint het van het najagen van zekerheid.

Dat hangt af van waar je risico ligt. ECC-geheugen is de eerste stap voor servers en langlopende infrastructuur die toestand in RAM bewaren. Checksums en hashes zijn het belangrijkst voor data die verplaatst of bewaard wordt, omdat ze corruptie opvangen die ECC niet kan zien zodra data het geheugen verlaat. Redundante berekening past bij veiligheidskritieke berekeningen die niet stil fout mogen gaan. De meeste volwassen systemen combineren alle drie in lagen in plaats van er één te kiezen, omdat elk een gat dekt dat de andere openlaten.

Ze zijn een kleine restoorzaak, ver achter race conditions, geheugenfouten, wisselvallige tests en omgevingsverschillen. Zoek eerst de gangbare verklaringen. Beschouw een zachte hardwarefout pas als kandidaat nadat je reproduceerbare softwarefouten hebt uitgesloten en hebt bevestigd dat het symptoom een enkele, niet-terugkerende bitwijziging is die past bij de SEU-waarschijnlijkheid bij jouw blootstelling. Op planeetschaal duikt die kleine rest echter toch regelmatig op, dus wuif hem niet volledig weg.

cside scant ruwweg meer dan 10 miljoen scripts elke 24 uur, dus het is gebouwd op dezelfde aanname die dit artikel beschrijft: bij dat volume zijn zeldzame fouten onvermijdelijk en moeten ze worden opgevangen in plaats van weggewenst. Het platform behandelt een misvormd script of een randgeval-exploit als iets dat in het totaal zal opduiken, ook al is elk afzonderlijk geval onwaarschijnlijk, en de scanpijplijn is ontworpen om afwijkend gedrag van scripts van derden te signaleren in plaats van erop te vertrouwen dat elke invoer correct gevormd is.

Ja, dat is de kern van het ontwerp. cside haalt scripts van derden op en analyseert ze aan zijn kant en hasht de payloads uit de echte sessie, zodat een wijziging die alleen onder specifieke omstandigheden afgaat toch als een verschil met de bekende goede versie naar voren komt. Omdat een gedrag van één op een miljoen gangbaar wordt bij miljoenen scripts per dag, gaat het platform ervan uit dat randgevallen zullen voorkomen en is het gebouwd om ze zichtbaar te maken in plaats van een deel te bemonsteren en te hopen dat de rest schoon is.

cside wordt geïmplementeerd als een enkele first-party JavaScript-tag, of via de agentloze Scan Method, zonder DNS-wijziging. Het staat niet voor je verkeer en het routeert of proxyt je bezoekers niet. In plaats daarvan haalt het de scripts van derden op en analyseert het ze op de infrastructuur van cside en leest het het scriptgedrag in de echte sessie, zodat de zware analyse aan de kant van cside gebeurt terwijl je pagina's normaal blijven laden voor je gebruikers.

Je voegt één lichte first-party JavaScript-tag toe aan je site, zonder DNS-wijziging en zonder dat er iets via cside wordt gerouteerd. Wil je liever helemaal geen script toevoegen, dan kan de agentloze Scan Method je pagina's extern monitoren. Vanaf daar haalt cside je scripts van derden op en analyseert ze, en houdt het hun gedrag in de echte sessie in de gaten op manipulatie of skimming, zodat client-side dekking snel begint zonder de manier waarop je site verkeer aan bezoekers levert opnieuw te ontwerpen.

cside wordt afgerekend op gebruik, meestal op basis van het aantal sessies of paginaweergaven, met niveaus die meeschalen naarmate je verkeer groeit en een gratis plan om te beginnen. Er zijn geen kosten verbonden aan het toevoegen van een DNS-wijziging of een proxy, want cside gebruikt geen van beide. Voor een offerte afgestemd op je verkeer en de dekking die je nodig hebt, kun je het beste met het cside-team praten in plaats van te gissen op basis van een vaste catalogusprijs.

Monitor en beveilig je third-party scripts

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

Start gratis, of probeer Business met een proefperiode van 14 dagen.

cside-dashboardinterface met scriptmonitoring en beveiligingsanalyses
Related Articles
Boek een demo

Wil je dit doornemen met een engineer?

Dertig minuten, op je eigen site. Geen slides.

Boek een persoonlijke demo om te zien:

Hoe je in 1 dag voldoet aan PCI DSS-vereisten 6.4.3 en 11.6.1
Waarom scripts van derden een beveiligingsrisico zijn voor jou en je bezoekers
Hoe je privacy- en toestemmingslekken (AVG, CCPA) bij elke derde partij monitort
Hoe je misbruik van aanmeldingen, account sharing en chargeback-fraude stopt met device intelligence
Hoe je AI-agents en bots die je site bereiken in realtime detecteert en beheerst

Liever gewoon een vraag stellen?

Vrije momenten zoeken…

Alleen echte mensen. Wij merken het.

Lukt het boeken niet? Agenda in een nieuw tabblad openen

Wat wil je oplossen?

Vertel het ons in één zin, dan komen we terug met iets bruikbaars in plaats van een standaardverhaal.

Waar we meestal mee helpen:

Zien welke scripts van derden op je site draaien
Bewijs voor PCI DSS 6.4.3 en 11.6.1
Bots, AI-agents en accountovername

Liever meteen een moment inplannen? Kies een tijdstip