Falha no Runet em 8 de outubro de 2026: empresa de segurança Curator admite culpa

Em 8 de outubro de 2026, o Runet operou por muito tempo com sérias interrupções em todo o país. Vários sites não abriam, e serviços populares paravam de responder. A primeira explicação parecia óbvia: no mesmo dia, houve um ataque de drones ao data center do Yandex. Depois, o quadro mudou. A causa era a empresa de segurança da informação Curator. Ela admitiu a culpa e afirma já ter resolvido o problema que derrubou a internet para os russos.

Cronologia e versões

Quando uma falha atinge sites e serviços em todo o país, a busca quase sempre começa pelos maiores pontos da infraestrutura. A coincidência de horário com o ataque ao data center do Yandex parecia uma explicação pronta, e foi adotada como ponto de partida. Mas, segundo os relatos, um evento não tem ligação direta com o outro.

O que se sabe até agora:

• data do incidente: 8 de outubro de 2026;
• escala: toda a Rússia, por um período prolongado;
• sintomas: vários sites não abriam e serviços populares não funcionavam;
• primeira versão: consequências do ataque de drones ao data center do Yandex;
• versão final: a culpada é a empresa de segurança da informação Curator;
• status: a Curator admitiu a culpa e diz ter corrigido o problema.

É preciso manter duas coisas separadas nesta história. O ataque ao data center de fato ocorreu, e esse é um fato à parte. Mas, de acordo com os dados atuais, ele não explica a indisponibilidade em massa de serviços no país.

O que ainda não sabemos

A fonte se limita ao fato de a empresa ter admitido a culpa. Não há dados sobre o mecanismo da falha, sobre quais produtos ou serviços da Curator estiveram envolvidos, sobre quantas horas o incidente durou nem sobre quais empresas foram mais afetadas. Também não foi revelado o que exatamente a Curator fez para corrigir o problema, nem se o incidente pode ser considerado totalmente encerrado.

Enquanto essas perguntas não forem respondidas, qualquer conclusão sobre a natureza técnica da falha seria especulação. A redação aguarda uma análise oficial da própria empresa, das operadoras e dos serviços afetados.

Uma conclusão, porém, se impõe. Se o erro de um fornecedor de ferramentas de segurança da informação conseguiu interromper sites e serviços em escala nacional, então esses fornecedores fazem parte da cadeia de dependência crítica. Costuma-se lembrar disso só depois do incidente.

O que as equipes devem verificar

Para donos de serviços e diretores de TI, este episódio é um motivo para fazer uma auditoria rápida, sem esperar pelos detalhes.

• Liste os serviços externos que ficam no caminho do tráfego ou influenciam a disponibilidade: proteção, filtragem, DNS, CDN, provedores de certificados.
• Para cada um, defina o que acontece se ele falhar: o serviço continua funcionando, perde desempenho ou para por completo.
• Verifique se existe uma rota de contingência e quem decide fazer a troca. À noite e em fins de semana, o engenheiro de plantão precisa saber fazer isso.
• Configure monitoramento externo a partir de várias redes. Assim, você descobre rápido se o problema está com você, com o provedor ou em escala nacional.
• Prepare com antecedência um modelo de comunicação com os clientes. Em 8 de outubro, a primeira versão da causa estava errada, o que mostra o custo de explicações apressadas.

O quadro completo só surgirá depois da publicação de uma análise técnica. Por ora, o principal está claro: uma falha dessa dimensão pode começar não na pane mais visível, mas em um erro num serviço que os usuários nem sabem que existe.