Ir para o conteúdo principal
Voltar ao arquivo

Edição 21 · 26 de outubro de 2026

Edition 21

Uma edição especial. Em vez de cinco histórias, a semana já triada: o que está a ser explorado, o que está exposto, o que toca e o que isso significa para o momento em que age.

Por Christophe Mazzola, CISO em exercício e fundador da Cyber Academy.

Receba o próximo GRC Brief na sua caixa de entrada.

Subscrever The GRC Brief

PAN-OS: horas, se essa interface de gestão estiver exposta à internet.

A 14 de outubro, a Palo Alto Networks divulgou a CVE-2026-0322, uma falha de injeção de código na interface de gestão do PAN-OS que permite a um atacante autenticado com privilégios elevados executar código como root na firewall. CVSS 8.6. A empresa já tinha observado o que designa de exploração muito limitada, e a CISA adicionou-a ao catálogo de vulnerabilidades exploradas conhecidas no mesmo dia, com prazo federal de 17 de outubro. Afeta firewalls PA-Series e VM-Series, bem como o Panorama. Não é necessária nenhuma configuração especial para ser vulnerável. A orientação da Palo Alto é restringir o acesso de gestão a endereços internos de confiança, ou a um único jump box.

Fonte: Palo Alto Networks · Advisory, 14 Oct 2026

A minha análise

Explorada: sim, como zero-day, antes de ter tido conhecimento. Exposta: apenas onde a interface de gestão é acessível a partir do exterior. Toca: o dispositivo que aplica o seu perímetro, ao nível de root. Veredicto: horas se essa interface responder a partir da internet, dias atrás de um jump box. E note o que a pontuação fez aqui. 8.6 é High, o que na maioria das políticas dá 30 dias, enquanto a CISA deu três às agências federais. Se a sua tabela de SLA tivesse sido o único input, teria agendado a tomada de controlo de uma firewall ativamente explorada para novembro. O controlo compensatório não tem custo e a Palo Alto recomenda-o há anos: retire a interface de gestão da internet hoje à noite e aplique o patch no seu próprio calendário depois disso.

PHP2Shell: horas, e já chegou tarde.

A 21 de outubro, o projeto PHP publicou uma versão de emergência para duas falhas críticas no núcleo do PHP, CVE-2026-109618 e CVE-2026-109619, ambas classificadas com 9.2, ambas permitindo a um atacante não autenticado executar código como worker web. São acionadas durante o parsing do pedido pelo PHP, antes de qualquer código da aplicação ser executado. Os detalhes vazaram a 20 de outubro, um dia antes da divulgação planeada, o que forçou a antecipação da versão. Os honeypots da Amazon registaram uma tentativa de exploração a 17 de outubro, quatro dias antes de qualquer anúncio. A Cloudflare passou de dezenas de milhares de tentativas nos 45 minutos após a divulgação para milhões na manhã seguinte. Corrigido nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. O PHP 8.1 e versões anteriores não recebem correção.

Fonte: PHP · Emergency release, 21 Oct 2026

A minha análise

Explorada: sim, quatro dias antes da divulgação. Exposta: qualquer sistema que sirva pedidos web via PHP, o que na maioria das organizações significa o site de marketing que ninguém gere. Toca: execução de código como conta web, no host. Veredicto: horas, e a versão honesta é que a sua janela fechou antes de a advisory existir. Dois pontos a reter para além da aplicação de patches. O Apache mod_php foi validado para execução completa de código nas configurações predefinidas; comece por aí. E se alguma parte do seu parque ainda executa PHP 8.1 ou anterior, não há correção a caminho, o que torna isto uma decisão de aceitação de risco com um nome associado, não uma tarefa de patching.

Node.js: dias, e verifique as imagens base dos seus contentores.

No mesmo dia, o Node.js publicou correções para dez CVEs nas suas linhas 22, 24 e 26. A mais grave é a CVE-2026-111497, uma escrita fora dos limites no descodificador Brotli incluído. Um stream malformado faz com que o descodificador continue a acrescentar input a um buffer interno de oito bytes, o que pode corromper a memória do processo e permitir execução remota de código em qualquer aplicação que descomprima dados Brotli fornecidos por um atacante. Outros três problemas de severidade elevada abrangem a validação de hostnames em certificados TLS e o tratamento de nomes DNS. Corrigido nas versões 22.23.4, 24.22.1 e 26.12.1. O Node.js 20 atingiu o fim de vida em abril e não recebe correções.

Fonte: Node.js · October 2026 security releases

A minha análise

Explorada: sem relatos. Exposta: qualquer serviço que descomprima Brotli que não gerou, o que abrange mais sistemas do que pensa. Toca: o runtime sob as suas aplicações. Veredicto: dias, na sua via normal de emergência. O que complica é a distribuição. Cada contentor construído sobre uma imagem base node anterior a 21 de outubro carrega esta vulnerabilidade, pelo que a correção implica um rebuild e um redeploy em todo o parque, não uma atualização de pacote num único host. Esta versão também incluiu silenciosamente a revogação de confiança no certificado do item seguinte, o que é a prova mais clara de que o seu trust store vive dentro das suas dependências.

eMudhra: não existe patch. Este é um problema de inventário.

A 17 de outubro, um investigador reportou à Apple, Google, Microsoft, Mozilla e eMudhra que as chaves privadas de oito dos certificados intermédios da autoridade de certificação indiana podiam ser recuperadas a partir dos certificados públicos. Tinham sido geradas como inteiros de dimensão mínima. Scott Helme, que recuperou todas as oito num laptop em menos de um segundo, refere que uma delas é o número 4. Quem detenha a chave de um certificado intermédio pode assinar um certificado válido para qualquer domínio. Os certificados foram emitidos em abril de 2025, pelo que a janela de exposição abrangeu cerca de dezassete meses. O Chrome e o Firefox bloquearam-nos no mesmo dia, a Apple a 19, a Microsoft a 20. A eMudhra revogou-os a 18 e anunciou a 22 que abandona o negócio de certificados TLS.

Fonte: Scott Helme · 20 Oct 2026, with Mozilla bug 2083449

A minha análise

Explorada: sem abuso confirmado, embora ninguém possa dar conta de dezassete meses. Exposta: não os seus browsers, que foram corrigidos em horas. Toca: a confiança em si mesma, em todos os locais onde valida um certificado fora de um browser. Veredicto: este não tem prazo porque não tem patch, e é precisamente por isso que é o mais difícil. Os seus contentores, os seus appliances, os seus Java keystores e cada ambiente Python com a sua própria cópia do certifi têm cada um um trust store que alguém tem de atualizar. O Curl, o certifi, o Node.js, o Go e o ecossistema Rust publicaram todos a revogação de confiança separadamente. A questão que a sua organização tem de responder é onde confia em autoridades de certificação e quem pode alterar isso em todos os locais simultaneamente; a maioria não consegue responder à primeira metade. Um detalhe que merece reflexão: Helme afirma que um agente de IA recuperou as chaves a partir de um único prompt.

As três frases de que o seu comité executivo necessita esta semana.

Uma contagem de CVEs não diz nada a um board sobre o que pode fazer. Após uma semana como esta, três frases chegam. Se estamos expostos a alguma destas situações, sim ou não. O que fizemos e quando. O que decidimos deixar por agora e quem aprovou. A terceira é a que importa, e é a que quase nunca é dita em voz alta. Ao abrigo do Artigo 20 do NIS2, o órgão de gestão aprova as medidas de gestão do risco de cibersegurança, supervisiona a sua implementação e pode ser responsabilizado por falhas. Um diferimento de que nunca tomam conhecimento é uma decisão que tomou silenciosamente em seu nome.

Fonte: My full analysis · christophemazzola.fr

A minha análise

Não saiu desta semana apenas a aplicar patches. Escolheu, ou alguém escolheu por si. Por isso, registe a escolha. Um responsável identificado, o motivo, o controlo compensatório se existir e uma data para rever. Uma vulnerabilidade diferida com assinatura é uma decisão de risco. Sem ela, é uma omissão que terá de explicar mais tarde; e após oito dias como estes haverá muito a explicar. Escrevi o argumento completo, incluindo o motivo pelo qual as pontuações não decidiram nada e por que razão a maioria das políticas de patch teria classificado o vetor de ransomware como trabalho de segunda divisão. Link acima. A versão curta é que os seus scanners eram iguais aos de todos os outros esta semana. O que distinguiu as organizações foi saber quem tinha autoridade para decidir.

Gostou desta? Receba a próxima.

Aterre na próxima.

Cinco coisas que se moveram em GRC, todas as segundas. Análise honesta, sem reciclar comunicados.

Subscrever The GRC Brief