MEO: ataque em massa provoca falhas na internet e rede móvel

Linha Temporal das Anomalias BGP (A partir de 08/09/2026)
8 a 10 de setembro de 2026 – O Acumular de “Stuck Routes” (Rotas Presas):
Os sistemas globais de monitorização começaram a registar flutuações e anúncios incompletos (path error leaks) na Europa Ocidental. Isto acontece quando um operador tenta remover uma rota para engenharia de tráfego, mas os routers em trânsito não propagam o withdrawal (retirada de anúncio).
Houve então o impacto, do tráfego direcionado a Portugal (com forte foco nas subredes da MEO / AS8657) começou a entrar em caminhos subótimos através de operadores de trânsito internacional. O utilizador final sentiu isto como latência elevada intermitente e falhas pontuais a carregar sites e serviços alojados fora do país.

12 de setembro de 2026 – O Incidente do BGP.Exchange:
A plataforma pública de coordenação e monitorização de rotas “BGP.Exchange” sofreu uma intrusão de segurança (com o seu portal e canais inundados de mensagens abusivas e de cariz político).
O Impacto, do peering através deste ecossistema ficou severamente comprometido, quebrando vários túneis VPN de engenharia e perturbando a visibilidade em tempo real que muitos ISPs usam para mitigar route leaks.

13 a 14 de setembro de 2026 – As Falhas de Infraestrutura e Fuga de Rotas em Cadeia (Gana):
O Ministério das Comunicações do Gana reportou um volume crítico de cortes físicos em cabos de fibra ótica internacionais de alta capacidade. Para contornar estas quebras, operadoras locais — como a Ghana Telecommunications (AS29614) — alteraram as políticas de reencaminhamento.
Houve então o Impacto, que ao tentar desviar tráfego por caminhos alternativos, ocorreu um Route Leak massivo. Prefixos de rede que deveriam manter-se em âmbito restrito foram anunciados indevidamente para a Internet pública.

14 de setembro de 2026 – O “Apagão” e a Explosão de Anúncios na MEO:
O ponto crítico. Os dados de telemetria mostram uma autêntica explosão de eventos BGP. Num único prefixo da rede MEO (como o bloco 2.80.0.0/14), os registos passaram de uma média normal de 17 eventos diários para mais de 3.650 anúncios em poucas horas.
Houve então o Impacto da rede internacional foi inundada por tabelas de encaminhamento inválidas vindas da rota EUA-Gana. Embora a operadora tenha comunicado publicamente a ocorrência de um “ataque distribuído em massa” (DDoS), a comunidade técnica mantém que a raiz de toda esta instabilidade e o colapso do tráfego internacional residiram no route leak acumulado desde a semana anterior.

No primeiro evento estão envolvidos seis prefixos associados à AS1273, Vodafone Group PLC, tendo a AS29614, Ghana Telecommunications Company Limited, como AS responsável pela fuga e a AS8657, MEO, como rede que recebeu e propagou as rotas. No segundo estão envolvidos cinco prefixos associados à AS37468, Angola Cables, igualmente com a AS29614 como AS responsável pela fuga e a AS8657 como destinatária.
Envolvidos também leaks nos EUA – Cox Communications no mesmo dia.

e o seguinte texto publicado já por cidadaos pela ciberseguranca:
Não confundir uma route leak que é dirigida para uma determinada rede com um BGP hijack dos prefixos dessa mesma rede seria tecnicamente incorrecto.

Também é importante colocar a dimensão dos eventos em perspectiva. Cinco e seis prefixos constituem uma quantidade muito reduzida quando comparada com a dimensão da tabela global de encaminhamento. Esses eventos, considerados isoladamente, não são prova suficiente para explicar uma interrupção de conectividade à escala nacional! O impacto de uma route leak, contudo, não depende exclusivamente do número de prefixos: depende também da importância desses prefixos, do tráfego que transportam, da preferência BGP atribuída às rotas e da extensão da sua propagação.
Há casos onde nos route collectors observam apenas as rotas que lhes são anunciadas pelos respectivos peers, pelo que uma ocorrência pode ter visibilidade limitada.
Mas há 2 eventos que confirmam que ocorreram anomalias de encaminhamento envolvendo a AS29614 e a AS8657, mas não permitem, por si só, concluir que essas anomalias tenham provocado uma falha generalizada da Internet em Portugal! Para estabelecer essa relação causal seria necessário demonstrar que as rotas afectadas eram efectivamente utilizadas pela MEO para alcançar uma parcela significativa da Internet e, sobretudo, encontrar evidência independente de alteração ou perda de conectividade coincidente com o período da alegada interrupção.
A conclusão mais rigorosa é, portanto, que houve (de facto) duas route leaks detectadas e envolvendo a MEO.
mas os dados disponíveis não demonstram que essas route leaks tenham sido a causa da interrupção nacional de conectividade. A coincidência temporal é uma pista para investigação, não uma prova de causalidade garantida.

Importa também corrigir uma afirmação que circulou em relação ao AS3243, o principal sistema autónomo de retalho da MEO. Esse ASN origina 1 844 224 endereços IPv4 distribuídos por 28 prefixos, de acordo com os dados públicos de encaminhamento. Este número é de endereços IP, não de utilizadores.

Foi ainda reportado por terceiros que a alcançabilidade do AS3243 teria caído para zero durante o incidente, recuperando para cerca de noventa por cento após mitigação. Este padrão é mais compatível com um ataque volumétrico seguido de mitigação do que com uma fuga de rotas.

Os dois route leaks documentados são factuais (aconteceram de facto);
A explicação avançada pela própria operadora (“ataque” em massa com congestionamento da rede internacional e subsequente mitigação) é a hipótese mais consistente com o conjunto das observações disponíveis, mas ainda permanece por confirmar de forma independente.
Os dados que resolveriam a dúvida existem mas são privados à MEO.

O enquadramento legal aplicável

Este incidente ocorre num quadro jurídico que mudou substancialmente há poucos meses e que, a respeito deste incidente, importa recordar:

O Decreto-Lei n.º 125/2025, de 4 de dezembro, aprovou o Regime Jurídico da Cibersegurança, transpondo a Diretiva NIS2. O diploma entrou em vigor em 3 de abril de 2026. Os fornecedores de redes públicas de comunicações eletrónicas são qualificados como entidades essenciais, o escalão mais exigente do regime.

Sobre essas entidades impende um dever de notificação faseada de incidentes significativos: alerta precoce no prazo de vinte e quatro horas a contar do conhecimento do incidente, notificação completa no prazo de setenta e duas horas e relatório final no prazo de um mês, com relatórios intercalares caso o incidente permaneça em curso. As comunicações são efetuadas através da plataforma do CNCS. O incumprimento do dever de notificação constitui infração autónoma, independentemente da qualidade técnica da resposta ao incidente, e as coimas para entidades essenciais podem atingir dez milhões de euros ou dois por cento do volume de negócios anual mundial.

A este regime acresce, no setor das comunicações eletrónicas, o regime de segurança e integridade das redes e serviços previsto na Lei n.º 16/2022, de 16 de agosto, e regulamentado pela ANACOM, que prevê igualmente deveres de notificação ao regulador setorial e, em determinadas circunstâncias, de informação ao público.

Nenhuma destas normas obriga, infelizmente, a operadora a informar os seus clientes em tempo real durante o incidente. É precisamente essa a lacuna que este episódio expõe.

O que poderia ter sido feito

Pela operadora, durante o incidente. A página de ocorrências https://www.meo.pt/ocorrencias devia ter sido atualizada nos primeiros minutos. Uma página de estado de serviço que não é atualizada durante um apagão nacional desta escala não cumpre a sua função e, pior, transmite ao cliente a informação errada de uma falsa normalidade. A atualização devia ter sido replicada por SMS, pela aplicação e pelas redes sociais, todos canais que, note-se, permanecem acessíveis a quem perdeu o acesso fixo mas mantém rede móvel de outro operador. O atendimento telefónico saturou e isso é inaceitável com relatos de esperas superiores a uma hora e vinte minutos. Uma mensagem gravada informativa e honesta, em substituição do assistente automático que chegou a atribuir a falha (falsamente) a “falhas de potência na fibra ótica”, teria evitado dezenas de milhares de chamadas inúteis.

Pela operadora, quanto à resiliência do DNS. A quantidade de relatos que descrevem recuperação de serviço através da simples mudança para DNS resolvers públicos sugere que a infraestrutura de DNS recursivo constituiu um ponto único de falha ou, pelo menos, um amplificador do impacto. A separação da infraestrutura de resolução da infraestrutura de trânsito, com capacidade de degradação graciosa, é prática corrente e deve ser auditada.

Pelas autoridades. O https://www.cncs.gov.pt/ podia ter emitido uma comunicação pública ainda no dia 14 mas a 15 ainda nada sobre o que aconteceu estava na homepage do site. Não era necessário divulgar informação sensível: bastava confirmar que tinham conhecimento do incidente, que estavam em articulação com o operador e que a situação estava a ser acompanhada. O silêncio de uma autoridade nacional de cibersegurança durante um incidente que afeta serviços essenciais em todo o território é, em si mesmo, um problema de confiança institucional. A https://www.anacom.pt/, enquanto regulador setorial, devia igualmente ter confirmado publicamente que estava a recolher informação junto das operadoras.

Pelo sistema, estruturalmente. Portugal não dispõe de um painel público de estado das infraestruturas críticas de comunicações, à semelhança do que existe noutros Estados-Membros. Não dispõe de um protocolo de comunicação de crise que articule operadores, regulador e autoridade de cibersegurança. E não dispõe de qualquer obrigação de publicação, ainda que diferida e agregada, dos relatórios finais de incidentes significativos. Os cidadãos ficaram a saber o que aconteceu através do Downdetector e de fóruns na Internet…

Recomendações à Assembleia da República

A Iniciativa CpC: Cidadãos pela Cibersegurança dirige à Assembleia da República, e em particular às comissões parlamentares com competência em matéria de infraestruturas, administração interna e assuntos europeus, as seguintes recomendações.

Audição parlamentar. Requerer a audição, em sede de comissão, do presidente do Conselho Diretivo da ANACOM e do coordenador do Centro Nacional de Cibersegurança, com vista ao apuramento dos factos relativos ao incidente de 13 a 15 de setembro de 2026, designadamente se foi cumprido o dever de alerta precoce previsto no Regime Jurídico da Cibersegurança, qual a qualificação do incidente e que medidas de supervisão foram ou serão adotadas. Considerar igualmente a audição dos responsáveis da MEO.

Dever de informação ao utilizador em tempo real. Promover a alteração da Lei n.º 16/2022 de modo a consagrar um dever autónomo de informação pública, a cargo dos fornecedores de redes e serviços de comunicações eletrónicas, durante incidentes com impacto significativo. Esse dever deve incluir prazo máximo para a primeira comunicação, contado do momento em que a operadora tem conhecimento da degradação; obrigação de utilização de canal público estável e de acesso livre, independente da rede afetada; obrigação de atualização periódica enquanto durar o incidente; e proibição de informação enganosa gerada por sistemas automáticos de atendimento. O incumprimento deve ser sancionável de forma autónoma.

Transparência diferida dos relatórios de incidente. Consagrar a obrigação de publicação, pelo CNCS e pela ANACOM, de uma versão pública do relatório final de cada incidente significativo que afete serviços essenciais e um número relevante de utilizadores, expurgada de informação sensível para a segurança nacional ou para a segurança das redes, num prazo determinado após o encerramento do processo. A confidencialidade operacional é legítima; a confidencialidade permanente sobre a causa de um apagão nacional não é.

Higiene de encaminhamento como requisito regulatório. Determinar que a ANACOM, em articulação com o CNCS, estabeleça requisitos mínimos de segurança de encaminhamento para os operadores que exploram redes públicas em Portugal, incluindo a publicação de ROA para todos os prefixos próprios, a implementação de validação de origem de rotas com descarte de rotas inválidas, a filtragem de anúncios recebidos de pares e clientes, e a adesão às boas práticas internacionalmente reconhecidas nesta matéria. Fixar um calendário de conformidade e um mecanismo de reporte anual público do grau de adoção por operador.

Painel nacional público de estado das comunicações. Recomendar ao Governo a criação, sob responsabilidade da ANACOM, de um painel público de estado das redes de comunicações eletrónicas em Portugal, alimentado por dados de disponibilidade fornecidos pelas operadoras e por telemetria independente, acessível a qualquer cidadão e concebido para funcionar em condições de rede degradada.

Resiliência de resolução de nomes. Solicitar ao CNCS um levantamento sobre a arquitetura de resolução recursiva de DNS dos principais operadores nacionais e sobre a sua resiliência a eventos de congestionamento, acompanhado de recomendações setoriais.

Avaliação da execução do Regime Jurídico da Cibersegurança. Determinar que o Governo apresente à Assembleia da República, no prazo de noventa dias, um relatório sobre o primeiro semestre de aplicação do Decreto-Lei n.º 125/2025, incluindo o número de entidades registadas, o número de notificações de incidentes recebidas por setor, os prazos médios de notificação e os meios humanos e financeiros efetivamente afetos ao CNCS para o exercício das novas competências de supervisão.

Dimensão europeia. Recomendar que a delegação parlamentar portuguesa junto das instâncias europeias suscite, no quadro do grupo de cooperação NIS e da ENISA, a questão da coordenação transfronteiriça na resposta a incidentes de congestionamento com origem externa à União, matéria em que o presente episódio, envolvendo trânsito internacional e sistemas autónomos de países terceiros, constitui caso ilustrativo.

Este texto e recomendações baseia-se em fontes públicas consultadas em 15 de setembro de 2026: notícias do ECO, Correio da Manhã, Observador, Renascença, Jornal de Negócios, CNN Portugal e Diário de Notícias da Madeira; dados de encaminhamento da Cloudflare Radar e do serviço público de consulta de sistemas autónomos da Hurricane Electric; o serviço de verificação de adoção de RPKI da Cloudflare; e relatos de utilizadores recolhidos em fóruns públicos, que são tratados como indícios qualitativos e não como dados estatísticos. As afirmações que não foi possível verificar de forma independente estão expressamente assinaladas como tal ao longo do texto.