Um conjunto de falhas críticas na extensão de assinatura digital da Connective — software usado na Bélgica para autenticação com cartão de identidade eletrónico (eID) e para assinaturas eletrónicas qualificadas — permitia que qualquer página web lesse dados do cartão de identidade e do cartão de pagamento da vítima, recuperasse o código PIN do eID e, no pior cenário, executasse código no computador sem qualquer clique adicional. A investigação foi apresentada publicamente no DEF CON 34, em Las Vegas, depois de um processo de divulgação coordenada que se arrastou por vários meses e no qual, segundo o relato público, não foi atribuído qualquer identificador CVE.
Resposta rápida: A extensão de assinatura da Connective, da Nitro Software Belgium, com mais de dois milhões de utilizadores, não validava a origem dos pedidos: qualquer site ou iframe podia comunicar com o componente nativo instalado no computador, ler o eID e o cartão Maestro, obter o PIN e desencadear execução remota de código. O fabricante corrigiu o problema em fases, com a última medida concluída no final de julho de 2026. Se utiliza este software, atualize-o para a versão mais recente ou remova a extensão e o componente nativo se já não precisar deles.
O que é a extensão Connective e onde é que ela está instalada
Trata-se de uma extensão de browser acompanhada de um componente nativo (native host) instalado no sistema operativo, cuja função é fazer a ponte entre páginas web e o leitor de cartões físico. A extensão de assinatura da Connective tem mais de dois milhões de utilizadores, sobretudo na Bélgica, permite que sites comuniquem com cartões eID e cartões de pagamento Maestro e, de acordo com material de divulgação da própria empresa, é utilizada por 8 dos 10 maiores bancos belgas e por mais de 60 organismos e departamentos públicos, servindo de base a assinaturas qualificadas eIDAS. Os investigadores esclarecem que estes números de adoção provêm da comunicação comercial da Connective/Nitro Software Belgium e que a contagem de mais de dois milhões de utilizadores ativos semanais é confirmada pelas listagens na Chrome Web Store e na loja do Edge.
O peso institucional do fornecedor é parte da história: a Nitro Software Belgium, empresa responsável pelo software, é um prestador qualificado de serviços de confiança inscrito na Lista de Confiança eIDAS da UE, o nível de confiança mais elevado previsto no regulamento.
Sem verificação de origem: qualquer separador podia falar com o seu leitor de cartões
O problema estrutural identificado é simples de descrever e difícil de desculpar: o componente nativo não verificava quem estava do outro lado. Qualquer site ou iframe conseguia ler os dados do eID e do cartão Maestro do utilizador e recuperar o PIN do eID, que o binário devolvia à página dentro de um token que transportava simultaneamente o texto cifrado e a chave necessária para o decifrar.
Segundo a análise técnica publicada, o activationToken não estava associado a uma origem, o que permitia ler cartões eID e Maestro ligados ao computador sem consentimento nem conhecimento do utilizador. O pinToken era enviado do componente nativo para a extensão e desta para a página web quando o utilizador introduzia o PIN na caixa de diálogo nativa, ficando assim exposto ao site; a sua estrutura revelou-se não um simples identificador, mas um contentor com dados codificados. A investigação recorreu à descompilação em Ghidra para identificar o comando que solicitava esse token e os respetivos argumentos.
As consequências práticas são graves porque o modelo de confiança do eID assenta numa premissa simples. Esse modelo pressupõe que o PIN só é introduzido em software que o utilizador escolheu executar e que as chaves só são usadas para operações que ele realmente pretendia; tudo o que está a jusante herda essa premissa, incluindo a chave de não-repúdio que produz assinaturas qualificadas eIDAS, juridicamente equivalentes a uma assinatura em papel — o que significa que, havendo falsificação, cabe à vítima provar que não foi ela.
Execução remota de código disfarçada de download de PDF
A falha mais severa nem sequer dependia de haver um cartão inserido. Qualquer site podia desencadear execução remota de código (RCE) do tipo drive-by, levando o binário nativo a carregar e executar uma biblioteca fornecida pelo atacante; o utilizador apenas veria um download de ficheiro, por exemplo um PDF, enquanto estava a ser comprometido.
De acordo com a investigação, não era necessária qualquer configuração invulgar para explorar esta RCE, nada impedia que o ataque se propagasse como um verme — roubando tokens de sessão e enviando a ligação a outros utilizadores com a extensão instalada — e não era exigida ao utilizador qualquer ação de risco: bastava visitar um site com a extensão e o componente nativo presentes no sistema.
Cronologia da correção e da divulgação
| Data | Acontecimento |
|---|---|
| Início de 2026 | Comunicação inicial das falhas ao fabricante (as correções finais surgiram 146 dias depois, segundo o relato da divulgação) |
| 8 de maio de 2026 | Primeira correção: validação de origem através de servidor remoto para aprovar pedidos dos sites antes da execução de comandos |
| 19 de maio de 2026 | A Nitro contacta os investigadores a pedir adiamento da divulgação pública enquanto clientes on-premise aplicavam a correção |
| Final de julho de 2026 | Conclusão das medidas de segurança finais |
| 6 a 9 de agosto de 2026 | Apresentação pública da investigação no DEF CON 34, em Las Vegas |
A primeira correção, de 8 de maio de 2026, acrescentou uma verificação de origem via servidor remoto, mas não resolveu a RCE nem a fuga do pinToken — passou apenas a limitar essas capacidades aos sites aprovados. A empresa pediu depois, a 19 de maio, o adiamento da publicação. Segundo o relato da divulgação pública, o conjunto de correções ficou concluído 146 dias após o reporte inicial, com as medidas finais no final de julho, e não foram atribuídos identificadores CVE às falhas. O DEF CON 34 decorreu entre 6 e 9 de agosto de 2026, no LVCC West Hall.
Um ponto relevante para a comunidade de investigação: os autores agradecem ao CCB, o centro de cibersegurança belga, a aprovação da publicação da série de vulnerabilidades ao abrigo da proteção legal da cláusula de safe harbour, sublinhando que não precisavam explicitamente dessa cobertura, mas que é útil tê-la. O procedimento legal belga permite ao CCB receber reportes sobre produtos ou serviços TIC sujeitos ao direito belga, mesmo quando a organização não tem política de divulgação nem programa de recompensas, desde que o investigador respeite condições como limitar-se a ações necessárias e proporcionais, atuar sem intenção fraudulenta e notificar a organização visada e o próprio CCB.
Sem CVE, sem IOC: o que isso significa na prática
Não foram publicados indicadores de comprometimento (IOCs) nem regras de deteção associadas a estas falhas, nem existe, à data, evidência pública de exploração maliciosa. A ausência de CVE tem, no entanto, um custo operacional: sem identificador, as equipas de TI dificilmente conseguem seguir o problema em ferramentas de gestão de vulnerabilidades, em SBOMs ou em inventários de software. Para quem administra parques informáticos, a recomendação prática é auditar as extensões instaladas e os respetivos componentes nativos, em vez de esperar por um alerta automático.
Medidas de mitigação recomendadas
- Atualizar a extensão de assinatura e o componente nativo da Connective para a versão mais recente distribuída pelo fabricante, em todos os postos de trabalho.
- Remover extensão e componente nativo em máquinas onde deixaram de ser necessários — software de assinatura instalado e esquecido é superfície de ataque permanente.
- Inventariar todas as extensões de browser com permissão de
nativeMessaginge restringir a instalação por política (ADMX/MDM), permitindo apenas extensões aprovadas. - Retirar o cartão de identidade do leitor quando não está a ser usado e desconfiar de qualquer pedido de PIN que não corresponda a uma ação que iniciou.
- Rever registos de assinaturas eletrónicas e de autenticações em serviços críticos, caso existam suspeitas de utilização indevida.
Porque é que isto importa em Portugal
O caso belga não tem, até agora, impacto direto conhecido em serviços portugueses, mas a arquitetura visada é familiar: em Portugal, a autenticação com Cartão de Cidadão assenta igualmente numa aplicação local instalada no computador, num leitor de cartões e num canal entre o browser e esse componente. É precisamente nessa fronteira — página web para aplicação nativa — que os investigadores encontraram o problema, e é aí que qualquer organização deve concentrar a sua análise de risco. O mesmo raciocínio aplica-se à Chave Móvel Digital e, no horizonte próximo, às carteiras europeias de identidade digital previstas no eIDAS 2.
Para entidades abrangidas pelo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2), este episódio ilustra bem dois deveres estruturantes: a gestão de risco da cadeia de fornecimento e o tratamento de vulnerabilidades em produtos de terceiros, incluindo software de assinatura fornecido por prestadores de serviços de confiança. Um incidente com origem numa extensão de browser pode desencadear obrigações de notificação ao CNCS/CERT.PT se afetar a prestação de serviços essenciais ou importantes. E porque estamos a falar de dados de identificação civil e de cartões de pagamento, um cenário equivalente em território nacional entraria também no perímetro do RGPD, com potencial dever de notificação à CNPD e aos titulares dos dados.
Para PME, a lição é mais prosaica: o risco não está apenas nos servidores, mas nos plug-ins que os colaboradores instalam para assinar contratos, submeter faturas ou aceder a portais públicos. Um inventário atualizado das extensões e dos componentes nativos autorizados custa pouco e evita surpresas caras.
Perguntas frequentes
Estas falhas afetam o Cartão de Cidadão português?
Não há indicação de que este caso concreto afete o software português. As vulnerabilidades divulgadas dizem respeito à extensão de assinatura da Connective, da Nitro Software Belgium, usada sobretudo na Bélgica. O interesse para Portugal é sobretudo arquitetural: o padrão «extensão de browser mais aplicação nativa» é o mesmo que suporta a autenticação com Cartão de Cidadão.
Já existe correção disponível?
Sim. O fabricante aplicou uma primeira correção a 8 de maio de 2026, com validação de origem dos pedidos, e concluiu as medidas finais no final de julho de 2026, segundo o relato da divulgação pública. Quem utiliza o software deve garantir que tem a versão mais recente instalada.
Foi atribuído algum CVE a estas vulnerabilidades?
De acordo com o relato da divulgação pública, não foram atribuídos identificadores CVE às falhas. Isso dificulta o acompanhamento automático por parte das equipas de segurança, que devem por isso auditar manualmente as extensões e componentes nativos instalados no seu parque informático.
Uma assinatura eletrónica qualificada podia mesmo ser falsificada?
Segundo a investigação, a recuperação do PIN a partir do token devolvido à página web permitia gerar autorizações que, com o cartão físico inserido no leitor, tornavam possível produzir assinaturas juridicamente vinculativas. É esse o ponto mais sensível: numa assinatura qualificada, o ónus de provar que não foi o titular a assinar recai sobre a vítima.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pelos investigadores responsáveis pela descoberta, pela organização do DEF CON 34 e pelo Centre for Cybersecurity Belgium (CCB).