En kodeendring som skulle automatisere en rutineoppgave hos Cloudflare endte i stedet med å slette adresseregistreringer for over tusen kunder. Den 20. februar 2026 klokken 17:48 UTC forsvant 1.100 av selskapets 4.306 BYOIP-prefikser (Bring Your Own IP) fra det globale internett, trukket tilbake via BGP-protokollen (Border Gateway Protocol). Det tok Cloudflares ingeniører seks timer og syv minutter å rydde opp, og i oktober 2026 dukket et liknende problem opp igjen. For bedrifter i Norge og Norden som lener seg på Cloudflares nettverk for å holde tjenester oppe, er hendelsen et påminnelse om hvor sårbar selve ruteinfrastrukturen på internett fortsatt er.
Saken er interessant av to grunner. Den første er den tekniske rotårsaken: en enkelt tom parameterverdi i et API-kall fikk systemet til å tolke samtlige kunderegistrerte IP-prefikser som sletteklare. Den andre er mønsteret. Analysebyrået CRN plasserte hendelsen på sin liste over de ti største skyutfall i 2026, og statusmålinger fra tredjeparter viser at Cloudflare hadde nye BYOIP-relaterte driftsproblemer så sent som 6. og 7. oktober 2026, bare dager før denne artikkelen ble skrevet.
Hva skjedde 20. februar 2026?
Cloudflares egen hendelsesrapport beskriver utfallet som en BYOIP-feil, altså et problem knyttet til tjenesten der kunder kan ta med sine egne IP-adresser inn i Cloudflares nettverk i stedet for å bruke adresser Cloudflare selv eier. Klokken 17:48 UTC begynte en bakgrunnsprosess å trekke tilbake kundeprefikser fra BGP-tabellene, og dermed ble tjenestene bak disse adressene usynlige for resten av internett. Trafikk som normalt ble dratt mot Cloudflares nettverk, fant ingen rute dit og endte i stedet i det som kalles BGP path hunting, der forbindelser leter seg fram gjennom andre nettverk til de til slutt gir opp og tidsavbrytes.
Av Cloudflares totalt 4.306 globale BYOIP-prefikser ble 1.100 trukket tilbake, altså rundt 25 prosent. Det er ikke hele Cloudflare-nettverket som gikk ned, men for de kundene det gjaldt var effekten total: trafikken forsvant fullstendig i stedet for å bare bli tregere. Ifølge sekundære driftsovervåkere ble blant annet tjenester tilknyttet Uber, Workday, Minecraft, Wikipedia og Microsoft Outlook rapportert som påvirket i perioden, selv om disse navnene ikke står i Cloudflares egen offisielle rapport og bør leses som tredjepartsobservasjoner heller enn bekreftede fakta.
Tidslinjen: Seks timer og syv minutter fra kodefeil til full gjenoppretting
Det som gjør denne saken spesielt godt dokumentert, er at Cloudflare publiserte en detaljert tidslinje i sin offisielle hendelsesrapport. Den defekte koden ble faktisk slått sammen inn i kodebasen allerede 5. februar, 15 dager før den ble rullet ut og utløste feilen. Tabellen under viser nøkkelpunktene fra selve hendelsesdøgnet.
| Klokkeslett (UTC) | Status | Hva skjedde |
|---|---|---|
| 17:46 | Utrulling | Addressing API-versjonen med den defekte bakgrunnsprosessen rulles ut |
| 17:56 | Nedetid starter | Prefikser begynner å bli trukket tilbake fra BGP i stort tempo |
| 18:13 | Internt varsel | Cloudflare-ingeniører kobles inn etter feil på one.one.one.one |
| 18:21 | Eskalering | Teamet som eier Addressing API varsles og starter feilsøking |
| 18:46 | Årsak identifisert | Den defekte bakgrunnsprosessen stoppes manuelt av en ingeniør |
| 20:20 | Delvis gjenoppretting | Rundt 800 av de 1.100 prefiksene reannonseres og kommer tilbake |
| 23:03 | Full gjenoppretting | De resterende cirka 300 prefiksene fikses manuelt, hendelsen avsluttes |
Legg merke til gapet mellom 18:46, da feilen ble identifisert og stoppet, og 23:03, da alt var tilbake til normalt. Over fire timer gikk med til selve gjenopprettingen, ikke til å finne feilen. Det sier noe om hvor vanskelig det er å reversere en automatisert endring som allerede har forplantet seg ut i et globalt nettverk.
Rotårsaken: Et tomt API-parameter slettet nesten alt
Den tekniske forklaringen er nesten absurd enkel. Cloudflare hadde bygget en automatisk ryddeprosess som jevnlig skulle sjekke hvilke BYOIP-prefikser kundene selv hadde markert for fjerning, og deretter slette dem fra systemet. Tidligere var denne oppgaven gjort manuelt av supportpersonell, men som en del av et internt initiativ for å redusere risikofylte manuelle operasjoner, ble den automatisert.
Problemet lå i selve API-kallet. Ryddeprosessen spurte endepunktet med parameteren pending_delete, men uten å gi den en verdi. På serversiden ble denne tomme strengen tolket som “ingen filtrering”, og i stedet for å returnere kun de prefiksene som faktisk sto i kø for sletting, returnerte Addressing API samtlige 4.306 BYOIP-prefikser i hele systemet. Ryddeprosessen tok deretter denne fullstendige listen og begynte systematisk å behandle alle som sletteklare, inkludert aktive tjenestebindinger, helt til en ingeniør fanget opp avviket og stanset prosessen.
// Forenklet fra Cloudflares egen hendelsesrapport
resp, err := d.doRequest(ctx, http.MethodGet, "/v1/prefixes?pending_delete", nil)
// På serversiden:
if v := req.URL.Query().Get("pending_delete"); v != "" {
// Skulle filtrere, men v er tom streng ("") når parameteren
// ikke har en verdi - alle prefikser returneres i stedet
prefixes, err := c.RO().IPPrefixes().FetchPrefixesPendingDeletion(ctx)
...
}Dette er en klassisk feilklasse i programvareutvikling: et skille mellom “parameter ikke satt” og “parameter satt til tom verdi” som ikke ble fanget opp i testmiljøet. Cloudflare skriver selv at testdataene i staging-miljøet ikke dekket scenarioet der selve bakgrunnsprosessen, uavhengig av brukerinput, endret kundedata på egen hånd. Testene for den vanlige selvbetjeningsflyten for BYOIP fungerte helt fint, men ingen testet hva som skjer når en autonom bakgrunnsjobb gjør feil.
Hvilke Cloudflare-tjenester ble rammet?
Fordi BYOIP er en infrastrukturtjeneste som flere andre Cloudflare-produkter bygger på, spredte feilen seg til mer enn bare CDN-trafikk. Core CDN og sikkerhetstjenester tapte trafikk fordi besøkende ikke lenger ble dratt mot Cloudflares nettverk. Spectrum, som proxyer ikke-HTTP-trafikk som spill og TCP/UDP-tjenester, kunne ikke lenger rute pakker siden adressene manglet. Dedicated Egress, brukt av kunder som sender utgående trafikk via egne IP-er, klarte ikke å nå sine destinasjoner. Magic Transit, Cloudflares DDoS-beskyttelse for hele nettverk, lot sluttbrukere oppleve rene tidsavbrudd fordi de beskyttede applikasjonene ikke lenger var annonsert på internett.
Ikke alle BYOIP-kunder ble rammet samtidig. Endringen ble rullet ut gradvis, ikke øyeblikkelig til alle maskiner, så Cloudflare fikk stanset prosessen før hele kundebasen var truffet. Det begrenset skadeomfanget, men skiller likevel ikke denne hendelsen fra å være alvorlig: 25 prosent av en global adressepool forsvant fra internett i over seks timer, og det er et tall de fleste sky- og nettverksleverandører vil kalle en kritisk hendelse.
Hvorfor tok gjenopprettingen over seks timer?
Ikke alle de 1.100 rammede prefiksene var i samme tilstand, og det kompliserte reparasjonen. Noen kunder hadde kun fått prefiksene trukket tilbake og kunne selv reannonsere dem via dashbordet, et grep som ga en rask delvis bedring rundt 19:19 UTC. En annen gruppe hadde også tapt noen av tjenestebindingene sine og befant seg i en mellomtilstand der bare deler av konfigurasjonen fungerte. Den tredje og verste gruppen hadde tapt alle tjenestebindinger, slik at ingen tjeneste lenger var koblet til prefiksene deres i det hele tatt. Disse kundene kunne ikke fikse noe selv, siden dashbordet ikke har noe å skru på når bindingen er borte.
For den siste gruppen måtte Cloudflare kjøre en global konfigurasjonsoppdatering på tvers av hele kantnettverket for å gjenopprette tjenestebindingene maskin for maskin. Det er denne prosessen som forklarer hvorfor hendelsen varte til 23:03 UTC, nesten fire og en halv time etter at selve årsaken var identifisert og stoppet klokken 18:46. En programvarefeil hadde dessuten fjernet adressekonfigurasjon fra enkelte edge-servere, så noen kunder opplevde fortsatt økt forsinkelse og feil selv etter at prefiksene formelt var reannonsert, fordi tilstanden måtte propageres tilbake til kantnoden på nytt.
Cloudflare bekrefter: Ikke et cyberangrep
Gitt hvor dramatisk og plutselig trafikken forsvant for de rammede kundene, var det naturlig at mange først fryktet et angrep. Cloudflare slo dette fast tydelig i sin offisielle hendelsesrapport: “Problemet ble ikke forårsaket, direkte eller indirekte, av et cyberangrep eller skadelig aktivitet av noe slag,” skriver selskapet.
Selskapet var også konkret om selve feilmekanismen. “Denne endringen fikk Cloudflare til å trekke tilbake kundeprefikser uten å mene det,” heter det i rapporten, som er gjengitt via Cloudflares offisielle meldinger under hendelsen. Beskrivelsen samsvarer med det tekniske bildet: “En undergruppe av kunder som bruker Cloudflares Bring Your Own IP-tjeneste (BYOIP), fikk sine ruter til internett trukket tilbake via Border Gateway Protocol (BGP).”
Når selve mitigeringen var i gang, beskrev Cloudflare prosessen slik: “Cloudflares ingeniører reverserte endringen, og prefiksene stoppet å bli trukket tilbake da vi begynte å observere feil.” Rapporten, slik den er sitert via en uavhengig postmortem-arkivering, inneholder også en kort, uvanlig direkte beklagelse fra selskapet: “Vi sviktet dere i dag.” Det er en kort setning, men den fanger godt hvor seriøst Cloudflare behandlet en feil som i praksis var selvforskyldt og teknisk unngåelig.
Code Orange: Fail Small – initiativet som skulle forhindre nettopp dette
Det mest ironiske elementet i saken er at selve endringen som utløste feilen, var en del av et internt Cloudflare-initiativ kalt Code Orange: Fail Small. Målet med programmet er å gjøre konfigurasjonsendringer tryggere ved å fjerne risikable manuelle prosesser og erstatte dem med automatikk som ruller ut gradvis og stoppes automatisk ved tegn på problemer. Initiativet er delt i tre spor: innføre kontrollerte utrullinger for alle konfigurasjonsendringer som når nettverket, fjerne sirkulære avhengigheter som hindrer tilgang under hendelser, og teste feiltilstander for alle systemer som håndterer nettverkstrafikk.
Endringen som forårsaket utfallet 20. februar hørte til det første sporet: å flytte en risikabel, manuell oppgave over til en automatisert og helseovervåket utrulling. Men de helsekontrollene som skulle fange opp nettopp dette avviket, var fremdeles under utvikling parallelt med at endringen ble rullet ut. Etter hendelsen har Cloudflare beskrevet tre konkrete oppfølgingstiltak: strengere validering av API-parametere slik at en tom streng ikke lenger kan tolkes som “ingen filter”, separasjon mellom kundekonfigurasjon og operasjonell tilstand i databasen, og innebygde sikringsmekanismer som automatisk stopper utrullingen dersom endringer skjer for raskt eller påvirker uvanlig mange objekter samtidig.
Historien gjentar seg: Nye BYOIP-problemer i oktober 2026
Åtte måneder etter februarhendelsen dukket et nytt, mindre BYOIP-problem opp. Ifølge uavhengige statusmålere som overvåker Cloudflares driftshistorie, rapporterte kunder mellom 6. og 7. oktober 2026 at de ikke klarte å oppdatere sine BGP-prefikser, verken for å annonsere eller trekke dem tilbake. Hendelsen ble erklært løst 7. oktober klokken 15:24 UTC. I samme periode registrerte statustjenester også en separat rutingfeil som startet 6. oktober omkring 13:34 UTC og varte i nesten to timer, samt et nettverksytelsesproblem i Columbus som strakk seg over ni timer fra 7. oktober klokken 02:48 UTC.
Disse oktoberhendelsene er mindre godt dokumentert enn februarutfallet, siden Cloudflare foreløpig ikke har publisert en like detaljert offentlig postmortem for dem. Men mønsteret er tydelig: samme produktområde, samme type symptom, samme risikoflate rundt BGP-annonsering av kundeprefikser. For et selskap som nettopp har brukt store deler av 2026 på å styrke nettopp denne delen av infrastrukturen gjennom Code Orange-programmet, er en ny BYOIP-relatert feil på under et år et dårlig tegn, uavhengig av hvor liten den endte med å bli.
Cloudflares driftshistorie i 2026: Mønsteret bak feilene
Februarhendelsen var ikke isolert. Ifølge Help Net Security, som siterte Cloudflares eget andre kvartal-rapport for 2026, logget selskapets statusside 13 separate hendelser mellom 7. og 14. august samme år. De berørte blant annet R2-objektlagring, Durable Objects, Workers KV, Workers AI og nettverksytelse på fire kontinenter. Det er viktig å skille mellom disse mindre, produktspesifikke avvikene og en global BGP-feil som februarhendelsen: de 13 augusthendelsene representerer driftsstøy i en enorm, kompleks plattform, mens BYOIP-utfallet var en strukturell svikt som rammet selve muligheten til å nås fra internett.
Satt i kontekst av andre skyleverandørers 2026-hendelser, er ikke Cloudflare unikt utsatt. Azures Sweden Central-region opplevde en driftsstans på nesten seks timer som rammet 18 regioner, og AWS ga opp data i Bahrain etter at krigsrelaterte forhold gjorde infrastrukturen der uholdbar. Det som gjør Cloudflare-saken spesielt interessant for sikkerhetsmiljøet, er at rotårsaken ligger i internett-rutingens mest grunnleggende lag, BGP, og ikke i en enkelt regional datasenterfeil.
Markedseffekten: Vekst tross nedetid
Interessant nok ser ikke februarutfallet ut til å ha skadet Cloudflares forretningsmessige momentum i særlig grad. Selskapets andre kvartal i 2026 viste en omsetning på 696,1 millioner dollar, en vekst på 36 prosent fra året før, ifølge tall gjengitt av Help Net Security. Cloudflare la i samme periode til over 80.000 nye betalende kunder, en vekst i kundebasen på 74 prosent år over år, og rapporterte rundt 4.698 “store kunder” som hver betaler mer enn 100.000 dollar årlig.
Det betyr ikke at nedetiden var kostnadsfri. SLA-kompensasjon, tapt tillit blant de direkte rammede BYOIP-kundene og ekstra ingeniørtimer brukt på Code Orange-arbeidet har en reell pris, selv om den ikke vises tydelig i kvartalstallene. Men for et selskap som drifter over 335 datasentre i 125-pluss land og håndterer over 20 prosent av global webtrafikk, demonstrerer veksttallene at enkeltstående infrastrukturfeil, selv alvorlige, ikke nødvendigvis endrer kundenes langsiktige vendor-valg. Det sier mer om hvor få reelle alternativer som finnes i samme skala, enn om hvor liten feilen var.
Konkurrentene: Hvordan håndterer AWS, Azure og Google Cloud BYOIP?
Alle de store skyleverandørene tilbyr en variant av BYOIP. AWS lar kunder annonsere egne IPv4-blokker gjennom EC2 og tilknyttede nettverkstjenester. Azure kaller sin løsning Custom IP Prefixes, med samme grunnfunksjon: kunden eier adresseblokken, men leverandøren annonserer den. Google Cloud tilbyr en liknende BYOIP-funksjon for egne offentlige IPv4-prefikser brukt sammen med utvalgte nettverkstjenester.
Ingen av disse tre har, så langt tilgjengelig dokumentasjon viser, hatt en bekreftet BGP-tilbaketrekkingsfeil av samme type og skala som Cloudflares februarhendelse i 2026. Google Cloud hadde riktignok et nettverks- og BGP-relatert utfall 20. august 2026 som varte omtrent 2,4 timer, men det finnes ingen offentlig bekreftelse på at dette spesifikt gjaldt BYOIP-prefikser. Det er verdt å presisere at det å ha en BYOIP-funksjon ikke automatisk betyr samme risiko: feilmodusen hos Cloudflare var spesifikk for hvordan selskapets Addressing API og automatiserte ryddeprosesser fungerte internt, ikke en generell svakhet i selve BYOIP-konseptet.
| Leverandør | BYOIP-løsning | Dokumentert BGP-utfall i 2026 | Varighet / årsak |
|---|---|---|---|
| Cloudflare | Bring Your Own IP (BYOIP) | Ja, 20. februar og 6.-7. oktober | 6 t 7 min / internt API-feil, ikke angrep |
| AWS | Bring Your Own IP (BYOIP) | Ingen tilsvarende dokumentert i tilgjengelige kilder | Ikke relevant |
| Microsoft Azure | Custom IP Prefixes | Ingen tilsvarende dokumentert i tilgjengelige kilder | Ikke relevant |
| Google Cloud | Bring Your Own IP | Nettverks-/BGP-utfall 20. august, ikke bekreftet BYOIP-spesifikt | Ca. 2,4 timer |
Hva betyr dette for norske og nordiske bedrifter?
Tilgjengelige kilder gir ingen fullstendig liste over hvilke norske eller nordiske virksomheter som bruker Cloudflares BYOIP-tjeneste spesifikt, og det ville være feil å hevde noe konkret om enkeltbedrifter uten dokumentasjon. Det som derimot er godt dokumentert, er konsentrasjonsrisikoen i seg selv. Cloudflare dekker i dag over 335 byer i mer enn 125 land, kobler til over 13.000 nettverk og når rundt 95 prosent av verdens internettbrukere innen omtrent 50 millisekunder. Når en så sentral aktør feiler på selve rutingslaget, er konsekvensen ikke begrenset til caching og CDN, den kan ramme selve muligheten en virksomhet har til å være tilgjengelig på internett.
For norske IT- og sikkerhetsansvarlige er den praktiske lærdommen todelt. For det første bør enhver virksomhet som bruker BYOIP eller tilsvarende adressefunksjoner hos en enkelt leverandør, ha en plan for hva som skjer dersom adressene plutselig forsvinner fra ruting, uavhengig av årsak. For det andre løser ikke en multi-CDN-strategi automatisk alt: dersom DNS, sertifikater, identitetshåndtering og brannmurregler fortsatt ligger hos samme leverandør, flytter man bare risikoen, man fjerner den ikke. En reell reduksjon av konsentrasjonsrisiko krever at flere av disse lagene faktisk er uavhengige av hverandre.
BGP-sikkerhet: RPKI, ASPA og veien videre
Februarhendelsen illustrerer en viktig, ofte oversett detalj i debatten om internett-rutingens sikkerhet: RPKI (Resource Public Key Infrastructure) løser ikke dette problemet. RPKI validerer om et autonomt system har rett til å annonsere en bestemt rute i utgangspunktet, men den hindrer ikke et nettverk som allerede er autorisert fra å trekke tilbake sine egne prefikser ved en feil. Cloudflares egne tekniske blogginnlegg om BGP-sikkerhet peker på flere kompletterende tiltak: BGP Roles og Only to Customer-attributtet definert i RFC 9234, som lar rutere avvise visse typer feilaktige ruteannonseringer automatisk, samt ASPA, en kryptografisk mekanisme som skal validere at en rute faktisk følger en gyldig leverandør-til-kunde-sti.
Ingen av disse mekanismene ville nødvendigvis stoppet februarhendelsen, fordi feilen ikke kom fra en ekstern aktør som forsøkte å kapre ruter, men fra Cloudflares egen interne automatisering som feilaktig fjernet legitime annonseringer. Det er en påminnelse om at ruteintegritet og driftsrobusthet er to forskjellige problemer som krever to forskjellige løsninger: kryptografisk validering stopper angripere, mens kretsbrytere, gradvis utrulling og bedre API-design stopper feil som denne.
Fem spådommer for resten av 2026 og 2027
- Cloudflare vil fortsette å publisere detaljerte, tekniske hendelsesrapporter for alvorlige utfall, siden åpenheten rundt februarhendelsen har blitt godt mottatt i sikkerhetsmiljøet og trolig lønner seg for selskapets rykte.
- Flere elementer av Code Orange: Fail Small-programmet, særlig skille mellom kundekonfigurasjon og operasjonell databasetilstand, vil bli ferdigstilt i løpet av 2026 og 2027, drevet av presset fra nettopp denne hendelsen.
- Oktoberhendelsene tyder på at BYOIP-relaterte driftsproblemer ikke er helt borte, og det er sannsynlig at Cloudflare vil oppleve minst én til to mindre, men dokumenterte BYOIP-forstyrrelser i løpet av de neste tolv månedene mens ombyggingen pågår.
- Flere nordiske virksomheter og offentlige etater vil trolig revurdere sin leverandørkonsentrasjon på DNS, CDN og adressetjenester, særlig i lys av at norske myndigheter allerede har skjerpet krav til digital robusthet gjennom annen regulering i 2026.
- Konkurrentene AWS, Azure og Google Cloud vil bruke hendelsen markedsmessig, men vil samtidig stå under økt press til å dokumentere sine egne sikringsmekanismer rundt BYOIP og BGP-annonsering mer åpent enn tidligere.
Ofte stilte spørsmål
Hva er BYOIP hos Cloudflare?
BYOIP, Bring Your Own IP, lar kunder bruke sine egne IP-adresseblokker gjennom Cloudflares nettverk i stedet for adresser Cloudflare selv tildeler. Kunden eier og er registrert for adressene, men Cloudflare annonserer dem via BGP slik at trafikken rutes gjennom selskapets infrastruktur.
Var februarhendelsen et resultat av et hackerangrep?
Nei. Cloudflare slo fast i sin offisielle rapport at problemet ikke ble forårsaket, direkte eller indirekte, av et cyberangrep eller skadelig aktivitet. Årsaken var en intern programvarefeil i en automatisert ryddeprosess.
Hvor mange kunder ble rammet av BYOIP-feilen 20. februar 2026?
Rundt 1.100 av Cloudflares totalt 4.306 globale BYOIP-prefikser ble trukket tilbake, omtrent 25 prosent av den totale poolen. Ikke alle berørte kunder opplevde samme alvorlighetsgrad, siden noen bare tapte selve annonseringen mens andre også tapte tjenestebindingene sine.
Hvorfor tok det over seks timer å fikse feilen?
Selve årsaken ble funnet og stoppet etter under en time, klokken 18:46 UTC. Resten av tiden gikk til å gjenopprette ulike kundetilstander, der de hardest rammede kundene krevde en global konfigurasjonsoppdatering på tvers av hele kantnettverket for å få tilbake tjenestebindingene sine.
Skjedde det en ny BYOIP-feil i oktober 2026?
Uavhengige statusmålere registrerte et nytt, mer begrenset BYOIP-relatert problem mellom 6. og 7. oktober 2026, der kunder ikke kunne oppdatere BGP-prefiksene sine. Hendelsen ble erklært løst 7. oktober klokken 15:24 UTC, men Cloudflare har foreløpig ikke publisert en like detaljert offentlig postmortem for den som for februarhendelsen.
Har AWS, Azure eller Google Cloud hatt liknende BYOIP-feil?
Det finnes ingen offentlig dokumentert BGP-tilbaketrekkingsfeil av samme type og omfang hos AWS eller Azure i 2026. Google Cloud hadde et nettverks- og BGP-relatert utfall i august 2026, men det er ikke bekreftet at dette var spesifikt knyttet til BYOIP-funksjonen.
Kan RPKI forhindre en liknende hendelse i fremtiden?
Ikke på egen hånd. RPKI validerer om et nettverk er autorisert til å annonsere en bestemt rute, men hindrer ikke et allerede autorisert nettverk fra feilaktig å trekke tilbake sine egne prefikser. Det kreves andre mekanismer, som kretsbrytere og gradvis utrulling av endringer, for å stoppe denne typen interne driftsfeil.
