Falha da Cloudflare: Revelando a falsa descentralização da indústria cripto

4 grandes falhas em 18 meses: por que o dilema da centralização é tão difícil de resolver?

Fonte: rekt news

Tradução: Saoirse, Foresight News

18 de novembro de 2025, 6h20 da manhã, horário da Costa Leste dos EUA. Muitos de nós experimentaram uma interrupção na rede.

Não foi uma interrupção gradual, nem houve qualquer sinal de alerta. Num segundo você estava a navegar no telemóvel, a negociar, a conversar com inteligência artificial; no segundo seguinte, tudo o que via eram páginas de erro 500.

O Twitter travou a meio de um tweet, o ChatGPT deixou de responder no meio de uma conversa, e o Claude simplesmente ficou bloqueado.

Até o Downdetector — aquele site que você consulta quando todas as plataformas estão com problemas — não carregava, incapaz de lhe dizer que “todos os serviços estão em baixo”.

De repente, 20% da internet mundial desapareceram, tudo porque a Cloudflare, que deveria proteger a internet contra ataques, acidentalmente “atacou-se” a si própria.

Uma alteração de configuração rotineira (atualização de permissões da base de dados) desencadeou uma vulnerabilidade oculta no sistema de proteção contra bots, e num instante, o “porteiro” passou a barrar toda a gente.

Em outubro, quando a Amazon Web Services (AWS) causou a queda da Coinbase, os utilizadores de Twitter do setor cripto ainda zombavam dos males da “centralização”.

Mas e quando a falha da Cloudflare explodiu em novembro? Pelo menos nas primeiras horas, o mundo cripto ficou em silêncio absoluto.

Afinal, quando a infraestrutura de que o Twitter depende está toda em baixo, nem sequer é possível discutir no Twitter a “fragilidade da infraestrutura”.

Vários serviços críticos ficaram parados (sistemas de transporte colapsaram), algumas interfaces empresariais apresentaram falhas, e exploradores de blockchain como Arbiscan e DeFiLlama também mostravam erros 500 — mas a blockchain em si não deu sinais de qualquer interrupção de consenso.

Quando a revolução “descentralizada” que você defende pode ser paralisada pelo tamanho de um ficheiro de configuração de uma empresa, quem é que realmente controla tudo?

Linha do tempo da falha: de “alteração de configuração” a “colapso da internet”

11:05 UTC: alteração de controlo de acesso à base de dados concluída.

23 minutos depois, às 11:28 UTC, a alteração chegou ao ambiente dos utilizadores e começaram a surgir os primeiros registos de erro no tráfego HTTP dos utilizadores.

Ou seja: a falha já tinha ocorrido, só que ninguém sabia ainda onde estava o problema.

Às 11:48 UTC, a página oficial de estado da Cloudflare finalmente admitiu “falha em serviços internos” — o que, em linguagem empresarial, significa: “está tudo um caos, e toda a gente percebe”.

O efeito dominó foi imediato: a alteração destruiu a camada de gestão de bots da Cloudflare e, ao carregar um ficheiro funcional com o dobro do tamanho, o serviço de proxy entrou em colapso.

Os sistemas a jusante também caíram: Workers KV (serviço de armazenamento chave-valor) e Access (controlo de acesso) não conseguiam ligar-se ao proxy; a taxa de erros disparou em toda a rede, e com o aumento da carga das ferramentas de monitorização, a utilização da CPU atingiu o pico.

O tráfego continuava a chegar aos nós de borda da Cloudflare — mas o serviço de proxy já não respondia.

A Cloudflare pensou inicialmente que estava a ser atacada, e que se tratava de um ataque DDoS de escala massiva.

Mais estranho ainda: até a página oficial de estado, totalmente alojada fora da infraestrutura da Cloudflare, ficou em baixo, levando os engenheiros a suspeitar de um ataque coordenado aos sistemas centrais e de monitorização.

Mas não era o caso. Não houve ataque externo, o problema era interno.

Pouco depois da recuperação dos serviços, o CTO da Cloudflare, Dane Knecht, publicou um pedido de desculpas público, classificando o incidente como “totalmente inaceitável” e culpando uma alteração de configuração rotineira — que desencadeou o colapso da camada de proteção contra bots.

“Desiludimos os clientes e os utilizadores da internet em geral”, escreveu Knecht, “um serviço fundamental para a nossa proteção contra bots tinha uma vulnerabilidade latente, que colapsou após uma alteração de configuração rotineira, causando uma falha em larga escala na nossa rede e outros serviços. Não foi um ataque externo.”

No pico da falha, a Downdetector recebeu 11.183 relatórios de avaria.

Este “apagão digital” durou mais de 5 horas e meia, até às 17:06 UTC, quando o serviço foi totalmente restabelecido; mas já às 14:30, após a implementação global do ficheiro de configuração correto para gestão de bots, o impacto mais grave tinha sido mitigado.

Impacto da falha: do Web2 ao cripto, ninguém escapou

Plataformas Web2 foram as primeiras atingidas

A plataforma X recebeu 9.706 relatórios de falha.

Os utilizadores não viam a linha do tempo habitual, mas sim o aviso de erro “Ops, algo correu mal”.

O ChatGPT ficou “em silêncio” a meio da conversa, sem responder a comandos.

O serviço de streaming Spotify foi interrompido, a plataforma de design Canva bloqueou os designers, e Uber e Door Dash (plataformas de entregas) também apresentaram anomalias.

Até os jogadores não escaparam: utilizadores de League of Legends foram desconectados a meio do jogo.

Chegou a circular que as máquinas de autoatendimento do McDonald’s também mostraram erros — coincidindo com o pico do almoço e a falha de infraestrutura.

O setor das criptomoedas também não ficou “imune”.

Plataformas cripto paralisadas em massa

O frontend da Coinbase colapsou completamente, restando aos utilizadores apenas uma página de login que não carregava.

O site e a app móvel da Kraken também “caíram” — consequência direta da falha global da Cloudflare.

A BitMEX publicou no seu painel de estado: “Estamos a investigar a causa da falha, o desempenho da plataforma está degradado, mas os fundos dos utilizadores estão seguros.” — O mesmo guião, só muda a exchange.

Etherscan não carregava, Arbiscan estava completamente fora do ar.

O painel de análise de dados da DeFiLlama apresentava erros internos de servidor de forma intermitente.

Até a Ledger publicou um aviso de que, devido à falha da Cloudflare, a disponibilidade de alguns serviços estava reduzida.

A única “exceção”: o próprio protocolo blockchain

Mas os seguintes sistemas não foram afetados:

Segundo relatos, Binance, OKX, Bybit, Crypto.com, KuCoin e outras grandes exchanges não tiveram falhas no frontend, as transações on-chain decorreram normalmente — e, ao mesmo tempo, a blockchain manteve-se totalmente operacional, sem qualquer sinal de interrupção de consenso.

O protocolo blockchain continuou a funcionar de forma independente — o problema não estava na cadeia, mas sim na infraestrutura Web2 usada para aceder à blockchain.

Se a blockchain continua a funcionar, mas ninguém consegue aceder a ela, as criptomoedas estão realmente “online”?

Análise aprofundada: como uma consulta à base de dados paralisou 20% da internet?

A Cloudflare não aloja websites, nem fornece servidores cloud como a AWS.

O seu papel é o de “intermediário” — entre o utilizador e a internet, servindo 24 milhões de websites através de nós em 120 países e 330 cidades, processando 20% do tráfego global da internet.

A mensagem de marketing da Cloudflare é: posiciona-se como “escudo e acelerador da internet”, oferecendo proteção DDoS 24/7, proteção contra bots, roteamento de tráfego, firewall global de aplicações web (WAF), terminação TLS, computação edge baseada em Workers e serviços DNS — tudo numa rede unificada de “segurança-desempenho”.

Na prática: detém 82% do mercado de proteção DDoS, largura de banda total dos nós edge de 449 Tbps, e está ligada a inúmeros ISPs e fornecedores de cloud em todo o mundo.

O cerne do problema: quando o intermediário falha, todos os serviços por trás tornam-se “inacessíveis”.

O CTO da Cloudflare, Dane Knecht, foi direto na plataforma X:

“Vou ser direto: hoje, devido a problemas na rede Cloudflare, muito tráfego que depende de nós foi afetado. Desiludimos os clientes e os utilizadores da internet em geral.”

O CEO Matthew Prince foi ainda mais direto:

“Hoje foi a pior falha da Cloudflare desde 2019... Em mais de 6 anos, nunca tivemos uma falha que impedisse a maior parte do tráfego central de passar pela nossa rede.”

Raiz técnica da falha

Tudo começou com uma atualização rotineira de permissões da base de dados. Às 11:05 UTC, a Cloudflare fez uma alteração no seu cluster de base de dados ClickHouse para aumentar a segurança e fiabilidade — permitindo que utilizadores com “acesso implícito” vissem explicitamente os metadados das tabelas.

Onde estava o problema? A consulta à base de dados que gera o ficheiro de configuração do serviço de proteção contra bots da Cloudflare não filtrava o “nome da base de dados”.

A consulta que gere o tráfego de ameaças começou a devolver entradas duplicadas — uma do banco de dados padrão, outra do armazenamento r0 subjacente. Isso fez com que o ficheiro funcional duplicasse de tamanho, passando de cerca de 60 para mais de 200 características.

A Cloudflare tinha um limite codificado de 200 características para pré-alocação de memória, achando que “era muito acima do uso real de cerca de 60”. É o típico pensamento de engenharia: definir uma margem de segurança “suficientemente folgada”, até que o inesperado acontece.

O ficheiro de tamanho excessivo atingiu esse limite, o código Rust colapsou, com o erro: “thread fl2_worker_thread panicked: called Result::unwrap() on an Err value” (thread fl2_worker_thread colapsou: chamada de Result::unwrap() num valor Err).

O sistema de proteção contra bots é um componente central da camada de controlo da Cloudflare. Quando colapsa, o sistema de health check que informa o balanceador de carga sobre “quais servidores estão operacionais” também falha.

Pior ainda: este ficheiro de configuração é regenerado a cada 5 minutos.

Só quando a consulta era executada nos “nós do cluster já atualizados” é que gerava dados errados. Assim, a cada 5 minutos, a rede da Cloudflare alternava entre “normal” e “falha” — ora carregava o ficheiro correto, ora o errado.

Esta “oscilação” levou os engenheiros a pensar que estavam sob ataque DDoS — erros internos normalmente não causam ciclos de “recuperação e colapso”.

Por fim, todos os nós ClickHouse foram atualizados, e todos os ficheiros gerados estavam errados. A “oscilação” parou, dando lugar a uma “falha total e estável”.

Sem sinais de sistema precisos, o sistema entrou em “modo conservador”, marcando a maioria dos servidores como “não saudáveis”. O tráfego continuava a chegar, mas não era corretamente encaminhado.

Os nós edge da Cloudflare recebiam os pedidos dos utilizadores — mas não conseguiam processá-los.

“Não foi um ataque externo”, Knecht enfatizou repetidamente, “não houve comportamento malicioso, nem ataque DDoS. Apenas uma consulta à base de dados sem filtro, coincidindo com uma atualização de permissões, e isso causou a falha.”

A Cloudflare prometia “99,99% de disponibilidade” — mas desta vez, não cumpriu.

É mesmo verdade.

História repete-se: 4 grandes falhas em 18 meses, por que o dilema da centralização persiste?

20 de outubro de 2025 — Falha da AWS dura 15 horas. Falha de resolução DNS na base de dados DynamoDB da região leste dos EUA, levando à paralisação da Coinbase, lentidão na Robinhood, interrupção do Infura (afetando MetaMask), e redes blockchain como Base, Polygon, Optimism, Arbitrum, Linea, Scroll todas offline. Apesar dos fundos on-chain estarem seguros, muitos viam o saldo da conta como “zero”.

29 de outubro de 2025 — Falha na Microsoft Azure. Problema de sincronização de configuração no Azure Front Door, levando à queda do Microsoft 365, Xbox Live e serviços empresariais.

Julho de 2024 — Atualização do Windows da CrowdStrike (empresa de segurança) com falha. Avaria causou cancelamento de voos, atrasos em hospitais, congelamento de serviços financeiros, e demorou dias a recuperar totalmente.

Junho de 2022 — Última grande falha da Cloudflare. Várias exchanges cripto suspenderam serviços — o mesmo padrão, só mudou o ano.

Julho de 2019 — Falha anterior da Cloudflare. Coinbase offline, CoinMarketCap inacessível — foi o primeiro “sinal de alerta” ignorado por todos.

Em apenas 18 meses, ocorreram 4 grandes falhas de infraestrutura.

Quatro falhas, a mesma lição: infraestrutura centralizada leva a “falhas centralizadas”.

Quatro falhas, que poderiam ter acelerado a transição do setor cripto para a descentralização — mas o setor ainda depende da infraestrutura de três empresas.

Quantos avisos serão necessários para que o setor passe de “assumir que falhas podem acontecer” para “construir sistemas assumindo que falhas vão acontecer”?

A “mentira” da descentralização: protocolo descentralizado não significa acesso descentralizado

Já lhe pintaram este cenário:

“Finanças descentralizadas, moeda resistente à censura, sistemas sem confiança, sem ponto único de falha, ‘se não são as tuas chaves, não são as tuas moedas’, código é lei.”

Mas a realidade de 18 de novembro foi um choque: uma manhã de falha na Cloudflare paralisou parte dos serviços do setor cripto durante horas.

Verdade técnica:

Nenhum protocolo blockchain foi reportado como tendo falhado. A rede Bitcoin funcionou normalmente, a rede Ethereum também — a cadeia em si não teve qualquer problema.

Realidade do uso:

Interfaces de exchanges colapsaram, exploradores de blockchain caíram, interfaces de carteiras falharam, plataformas de análise de dados ficaram offline, e interfaces de negociação mostravam erros 500.

Os utilizadores não conseguiam aceder à blockchain “descentralizada” que supostamente “possuíam”. O protocolo funcionava — desde que conseguissem “chegar até ele”.

Estas afirmações podem soar duras para muitos...

O COO da SovereignAI, David Schwed, foi implacável:

“Agora uma falha da Cloudflare, semanas atrás uma falha da AWS, tudo isto mostra: não podemos simplesmente terceirizar a ‘resiliência’ da infraestrutura a um único fornecedor. Se a sua organização precisa de operar 24/7, tem de construir a infraestrutura assumindo que falhas vão acontecer. Se o seu plano de continuidade de negócio é só ‘esperar o fornecedor recuperar’, isso é pura negligência.”

“Pura negligência” — não é acaso, nem lapso, é negligência.

Jameson Lopp foi direto ao ponto:

“Temos uma excelente tecnologia descentralizada, mas tornámo-la extremamente frágil ao concentrar a maioria dos serviços em poucos fornecedores.”

O que Ben Schiller disse na última falha da AWS aplica-se agora:

“Se a sua blockchain fica offline por causa de uma falha da AWS, então não é suficientemente descentralizada.”

Troque “AWS” por “Cloudflare”, o problema é o mesmo — o setor nunca aprende.

Por que escolher “conveniência” em vez de “princípio”?

Construir infraestrutura própria implica: comprar hardware caro, garantir energia estável, manter largura de banda dedicada, contratar especialistas em segurança, implementar redundância geográfica, montar sistemas de recuperação de desastres, monitorizar 24/7 — tudo exige muitos recursos.

Usar a Cloudflare só exige: clicar num botão, inserir o cartão de crédito, e em minutos está tudo pronto.

A proteção DDoS é responsabilidade de terceiros, a disponibilidade é garantida por terceiros, a escalabilidade é preocupação de terceiros.

Startups querem “ir rápido para o mercado”, VCs exigem “eficiência de capital” — todos escolhem a “conveniência”, não a resiliência.

Até ao momento em que a “conveniência” deixa de ser conveniente.

A falha da AWS em outubro gerou debates intermináveis sobre “descentralização” no Twitter.

E a falha da Cloudflare em novembro? Silêncio absoluto.

Não por “reflexão filosófica”, nem por “ponderação profunda”.

Mas porque, ao querer reclamar, perceberam que a plataforma habitual (Twitter) também estava em baixo devido à falha de infraestrutura.

Quando o “ponto único de falha” é a própria plataforma onde se goza dos “pontos únicos de falha”, não há como reclamar.

Quando a camada de acesso depende da infraestrutura de três empresas, duas das quais tiveram falhas no mesmo mês, a “descentralização ao nível do protocolo” é irrelevante.

Se os utilizadores não conseguem aceder à blockchain, o que é que estamos realmente a “descentralizar”?

Dilema do monopólio: três empresas controlam 60% do mercado cloud — e o futuro do setor cripto?

A AWS controla cerca de 30% do mercado global de infraestrutura cloud, a Microsoft Azure 20%, e a Google Cloud 13%.

Três empresas controlam mais de 60% da infraestrutura cloud que sustenta a internet moderna.

O setor cripto, que deveria ser a solução para a “centralização”, depende agora da infraestrutura mais centralizada do mundo.

Lista de “dependências centralizadas” do setor cripto

• Coinbase — depende da AWS;
• Binance, BitMEX, Huobi, Crypto.com — todas dependem da AWS;
• Kraken construiu a infraestrutura na AWS, mas ainda assim foi afetada pela falha da CDN da Cloudflare.

Muitas exchanges que se dizem “descentralizadas” operam, na verdade, sobre infraestrutura centralizada.

Há uma diferença fundamental entre as falhas de outubro e novembro:

Na falha da AWS, a plataforma X (ex-Twitter) continuou operacional, permitindo aos utilizadores cripto zombar da “fragilidade da infraestrutura”.

Mas na falha da Cloudflare, a plataforma X também ficou offline.

Quando a plataforma usada para “gozar dos pontos únicos de falha” é ela própria parte do problema, não há como rir.

Este tom irónico fez com que o debate do setor nem sequer começasse.

Três grandes falhas em 30 dias, e os reguladores já estão atentos.

Questões centrais para os reguladores

• Estas empresas são “instituições de importância sistémica”?
• Os serviços backbone da internet devem ser regulados como “serviços públicos”?
• Que riscos surgem quando “grande demais para falhar” se aplica à infraestrutura tecnológica?
• Se a Cloudflare controla 20% do tráfego global, isso é um problema de monopólio?

Corinne Cath-Speth, da organização Article 19, foi clara na última falha da AWS: “Quando um fornecedor falha, serviços críticos caem — os media ficam inacessíveis, apps seguras como Signal param, e a infraestrutura que sustenta a sociedade digital desmorona. Precisamos urgentemente de diversificar a cloud.”

Em suma: os governos estão a perceber que poucas empresas podem paralisar a internet.

Na verdade, já existem alternativas descentralizadas — só ninguém as quer usar.

Por exemplo, Arweave para armazenamento, IPFS para transferência de ficheiros distribuída, Akash para computação, Filecoin para alojamento descentralizado.

Por que as soluções descentralizadas não “pegam”?

Desempenho inferior às soluções centralizadas, com latência perceptível para o utilizador.

Baixíssima adoção, e a experiência de utilizador é muito mais complexa do que “clicar em ‘deploy to AWS’”.

O custo geralmente é superior ao aluguer de infraestrutura dos “três gigantes” (AWS, Azure, Google Cloud).

A realidade é:

Construir infraestrutura verdadeiramente descentralizada é extremamente difícil, muito mais do que se imagina.

A maioria dos projetos só fala em “descentralização”, mas raramente a implementa. Escolher soluções centralizadas é sempre mais simples e barato — até que quatro falhas em 18 meses mostram o preço oculto do “simples e barato”.

O CEO da OORT, Dr. Max Li, apontou a hipocrisia do setor num artigo recente na CoinDesk:

“Para um setor que se orgulha da ‘descentralização’ e proclama as suas vantagens, depender fortemente de plataformas cloud centralizadas e frágeis é, em si, uma hipocrisia.”

A solução que propõe: adotar uma estratégia de cloud híbrida, dispersando sistemas críticos das exchanges por redes descentralizadas.

As plataformas cloud centralizadas têm vantagens de desempenho e escala — mas quando estão em causa milhares de milhões de dólares e cada segundo de negociação conta, a resiliência é muito inferior à das soluções distribuídas.

Só quando o custo da “conveniência” for suficientemente alto para mudar o comportamento do setor, o “princípio” vencerá a “conveniência”.

Claramente, a falha de 18 de novembro não foi suficientemente grave, nem a da AWS em 20 de outubro, nem a da CrowdStrike em julho de 2024.

Até que ponto a “infraestrutura descentralizada” deixará de ser um tema para se tornar um requisito obrigatório?

Em 18 de novembro, o setor cripto não “falhou” — a blockchain funcionou perfeitamente.

O verdadeiro “fracasso” foi a mentira coletiva do setor: achar que se pode construir “aplicações imparáveis” sobre infraestrutura que pode falhar; achar que “resistência à censura” faz sentido quando três empresas controlam o “acesso”; achar que “descentralização” é real quando um ficheiro de configuração da Cloudflare decide se milhões podem negociar.

Se a blockchain continua a gerar blocos, mas ninguém pode submeter transações, está mesmo “online”?

O setor não tem qualquer plano de contingência.

Quando há falha, só resta esperar que a Cloudflare repare, que a AWS recupere, que a Azure aplique o patch.

Este é o “plano de recuperação de desastres” do setor atualmente.

Imagine: e se a identidade digital estiver profundamente ligada à blockchain?

O Tesouro dos EUA está a promover a integração de credenciais de identidade em contratos inteligentes, exigindo KYC em cada interação DeFi.

Na próxima falha de infraestrutura, os utilizadores não perderão apenas o direito de negociar — perderão a capacidade de “provar a sua identidade” no sistema financeiro.

Uma falha de 3 horas pode tornar-se 3 horas sem conseguir carregar o CAPTCHA — só porque o serviço de verificação está na infraestrutura em baixo.

Os “rails de segurança” que os reguladores querem pressupõem “infraestrutura sempre online”. Mas a falha de 18 de novembro prova que esse pressuposto não existe.

Quando o problema do “excesso de vigilância” se torna óbvio, os profissionais de tecnologia viram-se para a “privacidade”.

Talvez seja hora de incluir a “resiliência da infraestrutura” nesse âmbito.

Não deve ser um “extra opcional”, mas um “requisito fundamental” — sem ele, nada mais importa.

A próxima falha já está a ser preparada — pode vir da AWS, Azure, Google Cloud, ou ser mais uma da Cloudflare.

Pode ser no próximo mês, ou na próxima semana. A infraestrutura não mudou, as dependências não mudaram, os incentivos do setor também não.

Escolher soluções centralizadas continua a ser mais barato, rápido e conveniente — até deixar de ser.

Quando a próxima alteração de configuração da Cloudflare desencadear outra vulnerabilidade oculta num serviço crítico, veremos o mesmo “filme”: páginas de erro 500 por todo o lado, negociações paradas, blockchain operacional mas inacessível, querer discutir “descentralização” no Twitter mas o Twitter está em baixo, promessas empresariais de “fazer melhor da próxima vez” que nunca se cumprem.

Nada mudará, porque a “conveniência” sempre vence a “prevenção de riscos” — até ao dia em que o preço da “conveniência” for impossível de ignorar.

Desta vez, o “porteiro” ficou paralisado durante 3 horas e meia.

Na próxima, a falha pode durar mais; na próxima, pode coincidir com um crash de mercado em que cada segundo conta; na próxima, até o sistema de autenticação pode ser afetado.

Quando a infraestrutura de que depende para sobreviver falha no momento em que menos pode perder, de quem é a culpa?

Fontes: The Guardian, Johnny Popov, PC Magazine, IT Professional, CNBC, Cloudflare, TechCrunch, Associated Press, CoinDesk, Tom’s Hardware, Dane Knecht, Tom’s Guide, Surya, Sheep Esports, TheBlock, Kraken, BitMEX, Ledger, Blockchain News, Statista, PC Scream, Jameson Lopp, Ben Schiller, Article 19, CoinTelegraph