Na tarde e noite de 14 de setembro de 2026, muitos milhares de utilizadores em todo o território nacional ficaram sem acesso à Internet fixa, sem rede móvel de dados e, em alguns casos, sem televisão. A MEO concentrou a esmagadora maioria dos relatos, mas a NOS, a Vodafone e a DIGI também registaram volumes anómalos. Às 22h58, através da agência Lusa, a MEO confirmou ter sido “alvo de um ataque em massa” que provocou “congestionamento e degradação da rede internacional”, assegurando que não houve intrusão nem acesso a dados de clientes.

Quase vinte e quatro horas depois, continua a não existir qualquer comunicação pública do Centro Nacional de Cibersegurança (CNCS), do CERT.PT, da ANACOM ou do Governo sobre um incidente que afetou infraestrutura crítica nacional. A CpC entende que o problema mais grave deste episódio não é técnico: é a ausência de um mecanismo de informação pública em tempo real sobre incidentes que atingem serviços essenciais como acesso à internet de particulares e empresas.

O que sabemos:

Durante a madrugada de 13 para 14 de setembro registaram-se as primeiras anomalias com vários utilizadores espalhados por todo o país relatando falhas a partir das 23h30 de domingo e uma interrupção generalizada da rede MEO por volta das 02h20, com cortes sucessivos de conectividade ao longo de várias horas.

Um padrão aparentemente recorrente nos relatos foi a falha de resolução de nomes em IPv4: um número relevante de utilizadores refere ter restabelecido o acesso apenas mudando os servidores de DNS da operadora para resolvers públicos, o que aponta para degradação ao nível dos DNS recursivos da operadora e não apenas para perda de conectividade de trânsito.

Na tarde de segunda-feira, 14 de setembro, os relatos voltam a surgir. O Correio da Manhã noticiou mais de 4 700 registos no Downdetector pelas 17h35. O ECO reportou um pico de 7 376 registos relativos à MEO pelas 18h26, acompanhado de 322 registos da NOS, 272 da Vodafone e 46 da DIGI por volta das 18h21. Foram reportados problemas em Lisboa, Porto, Braga, Coimbra, Sintra, Viseu, Viana do Castelo, Gaia, Paredes, na região Oeste e no Funchal.

O ECO assinalou ainda um dado que merece destaque: no momento do incidente, nenhuma das operadoras tinha qualquer alerta nos seus sites. A página de ocorrências da MEO apresentava como última atualização uma entrada de 28 de janeiro relativa à tempestade Kristin; a da NOS remontava a 9 de junho. Os clientes que procuraram informação oficial no canal criado precisamente para esse efeito não encontraram nada de relevante, apenas informação comercial absolutamente irrelevante.

Às 22h58 de 14 de setembro, a MEO emitiu, através da Lusa, a única declaração pública conhecida: fora “alvo de um ataque em massa” que causou “congestionamento e degradação da rede internacional”; foram “de imediato ativadas todas as medidas de mitigação e recuperação”; e do ataque “não resultou qualquer intrusão nem acesso a dados da MEO e seus clientes”. (www.rtp.pt/noticias/cultura/meo-alvo-de-ataque-em-massa-garante-que-nao-houve-acesso-a-dados-de-clientes_n1765431)


O que a MEO não disse (e podia)

O comunicado é lacónico. Não qualifica o ataque (“ataque em massa” não é um termo técnico) e a MEO não confirmou tratar-se de um ataque de negação de serviço distribuída (DDoS), ainda que a descrição de congestionamento da rede internacional seja compatível com um ataque volumétrico. Não indica a hora de início, a hora de reposição, o volume de tráfego envolvido, os vetores utilizados, a origem observada nem o número de clientes afetados. Não refere se o incidente foi notificado ao CNCS, ao CERT.PT ou à ANACOM. E não explica por que razão os canais oficiais de estado de serviço permaneceram silenciosos durante todo o período crítico.

A hipótese BGP: o que os dados mostram e o que não mostram:
Circulou nas redes sociais, com alguma insistência, a tese de que o apagão teria sido causado por um incidente de encaminhamento BGP com origem no Gana. É necessário rigor neste ponto, porque a tese não é sustentada pelos dados públicos disponíveis.

O sistema de deteção de anomalias de encaminhamento da Cloudflare Radar registou efectivamente dois eventos de BGP route leak na janela temporal em causa: o evento 614080, detectado às 22h45 de 13 de setembro, e o evento 614156, detectado às 01h13 de 14 de setembro: https://radar.cloudflare.com/routing/anomalies/event/leak-614080 https://radar.cloudflare.com/routing/anomalies/event/leak-614156

A Cloudflare define uma route leak como a propagação de anúncios de encaminhamento para além do seu âmbito previsto.

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. A terminologia da própria Cloudflare é importante: “From” identifica a rede de onde as rotas foram aprendidas, “By” a AS que efectuou a fuga e “To” a AS que recebeu e propagou as rotas.

Assim sendo, estes eventos não demonstram um sequestro dos prefixos da MEO. A AS8657 surge como destinatária das rotas que a Cloudflare classificou como leaked. Confundir uma route leak dirigida para uma determinada rede com um BGP hijack dos prefixos dessa mesma rede seria tecnicamente incorrecto. A própria Cloudflare trata route leaks e origin hijacks como categorias distintas de anomalias BGP.

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.

Por outro lado, a ausência de uma anomalia facilmente identificável nos dados públicos do RIPE RIS ou do RouteViews deve ser tratada como ausência de confirmação, e não como prova de que a route leak não ocorreu. Os route collectors observam apenas as rotas que lhes são anunciadas pelos respectivos peers, pelo que uma ocorrência pode ter visibilidade limitada. A própria Cloudflare combina dados históricos do RouteViews e do RIPE RIS com outras fontes de observação, incluindo fontes internas em tempo real.

Consequentemente, os dois eventos da Cloudflare 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 pela Cloudflare 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. A CpC não teve, contudo, acesso aos dados de origem e assinala esta observação como não verificada.

A conclusão mais prudente (com o pouco que se sabe a 15.09.2026) é que:
os dois route leaks documentados são factuais (aconteceram de facto);
a sua causalidade em relação ao apagão não está demonstrada.
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 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.