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.
Nesta edição
- 01PAN-OS: horas, se essa interface de gestão estiver exposta à internet.
- 02PHP2Shell: horas, e já chegou tarde.
- 03Node.js: dias, e verifique as imagens base dos seus contentores.
- 04eMudhra: não existe patch. Este é um problema de inventário.
- 05As três frases de que o seu comité executivo necessita esta semana.
Receba o próximo GRC Brief na sua caixa de entrada.
Subscrever The GRC BriefPAN-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.