72 horas de vulnerabilidades: o que corrigir, o que rodar e que certificados trocar

Entre segunda-feira, 19, e quinta-feira, 22 de outubro de 2026, foram publicados oito incidentes que afetam infraestrutura muito comum: duas falhas críticas no PHP, uma release de segurança do Node.js com dez CVE, um RCE sem autenticação no GitLab com CVSS 10.0, uma violação das variáveis de ambiente da Railway, uma versão maliciosa do LiteLLM no PyPI e no Docker Hub, o aviso da PingCAP sobre o TiDB Cloud, a revogação de 404.607 certificados da GoDaddy e a desconfiança em oito CA intermédias da eMudhra.

Como manchetes, são oito notícias. Para quem mantém servidores, são três tarefas: atualizar, rodar segredos e rever certificados. Este post organiza-as assim, com as versões corrigidas e os comandos para verificar.

Resumo: quem tem de fazer o quê

1. Atualizar runtimes e servidores

PHP: php2shell

Um post no Hacker News divulgou a 20 de outubro os identificadores de duas falhas críticas do PHP antes do fim do embargo, e o projeto antecipou a publicação para 21 de outubro às 14:00 UTC. A CVE-2026-109618 é uma corrupção de memória quando o PHP fica sem memória a meio de processar o pedido; a CVE-2026-109619 é um use-after-free entre pedidos do mesmo worker. As duas exploram-se sem autenticação, afetam todas as instalações que servem PHP pela web e são piores com mod_php, onde a Rapid7 indica que se exploram antes de o código da aplicação correr. A Wiz demonstrou RCE contra WordPress, Drupal e Joomla. As versões corrigidas são 8.5.12, 8.4.27, 8.3.36 e 8.2.35; se usa os pacotes da sua distribuição Linux, consulte o aviso do fornecedor, que em muitos casos corrigiu antes. Se não puder atualizar hoje, a mitigação oficial temporária é session.upload_progress.enabled=0 no php.ini ou no pool do FPM (não serve ini_set nem .user.ini) e reiniciar todos os workers. Se preferir delegar a atualização: patch de segurança PHP.

Node.js: Brotli e hostnames TLS

A 21 de outubro o Node.js publicou dez CVE para as linhas 26.x, 24.x e 22.x. As quatro altas:

• CVE-2026-111497: escrita fora de limites no descompressor Brotli, com possibilidade de RCE. O Express 5 e o fetch() descomprimem Brotli automaticamente, por isso basta que o seu servidor receba, ou o seu código descarregue, uma resposta comprimida manipulada.
• CVE-2026-106069 e CVE-2026-105483: a verificação do hostname de um certificado TLS pode ser contornada. Um cliente Node pode aceitar um certificado válido emitido para outro domínio.
• CVE-2026-105482: dns.resolve trunca os nomes que contêm um carácter NUL.

Versões corrigidas: v26.12.1, v24.22.1 e v22.23.4. O Node 20 e o 25 estão fora de suporte e não recebem patch: se ainda os usa, a correção é uma atualização de versão maior. Não há exploração reportada. Se ainda está no 20 ou no 25 e prefere não fazer o salto sozinho, veja patch de segurança Node.js.

node --version
# em Docker, o que conta é a imagem base:
docker run --rm a-sua-imagem node --version

NGINX: um ano com muito trabalho

O NGINX acumula em 2026 vários lotes de avisos. Em maio saiu a CVE-2026-42945, “NGINX Rift”: a plataforma de IA da DepthFirst encontrou-a em cerca de seis horas, e a falha vinha da versão 0.6.27, publicada em 2008. O nginx.org classifica-a como de gravidade média; a Cloud Security Alliance e a Help Net Security dão-na como crítica (9.2), e a VulnCheck viu tentativas de exploração desde 16 de maio. Foi corrigida na 1.31.0 e na 1.30.1.

O lote de outubro traz mais cinco CVE: CVE-2026-15176, 93479, 95101 (request smuggling em HTTP/3), 97629 (falsificação de sessão TLS que salta a verificação do certificado de cliente) e 97205. São corrigidas na 1.31.7+ e 1.30.6+. Enquanto atualiza, o nginx.org sugere evitar $request_filename e alias (15176) e usar capturas com nome em vez de capturas sem nome nos blocos location com regex (93479). A atualização e a revisão dessa configuração estão em patch de segurança NGINX.

nginx -v

GitLab self-managed: CVSS 10.0

A 21 de outubro o GitLab publicou a CVE-2026-110264: um overflow de inteiro ao compilar uma expressão regular manipulada permite a um utilizador sem autenticação executar código no servidor. Afeta CE e EE desde a versão 7.0, de 2014. O GitLab.com e o GitLab Dedicated já estão corrigidos; as instalações próprias têm de passar para 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 ou 18.11.13, conforme o ramo. A 22 de outubro não se conhece exploração.

Nove dias antes, a 12 de outubro, o GitLab já tinha corrigido outro 10.0 (CVE-2026-97229, também com expressões regulares em CI/CD) na 19.2.8, 19.3.5 e 19.4.2, e para esse há PoC público. Se não aplicou aquele, as versões novas desses ramos incluem também essa correção. Para que sejamos nós a atualizar: atualizar GitLab self-managed.

Porque aparecem tantas falhas antigas

Duas das falhas desta lista existiam há mais de uma década: a do GitLab desde 2014 e a NGINX Rift desde 2008. No caso do NGINX sabemos como foi encontrada: uma ferramenta de IA demorou cerca de seis horas. O FIRST (Forum of Incident Response and Security Teams) prevê fechar 2026 com cerca de 66.000 CVE, e atribui parte da subida a ferramentas de IA que procuram falhas sozinhas. A mesma fonte avisa que outra parte é contabilidade (bases de dados que catalogam mais e registam falhas antigas) e que a proporção de CVE explorados se mantém estável. Para uma equipa pequena, isso significa que a lista de avisos para ler cresce mais depressa do que a de urgências, e que compensa ter um inventário de versões para saber num minuto se um aviso o afeta.

2. Rodar segredos, por ordem

Três incidentes da lista expõem credenciais em vez de código:

• A Railway detetou a 21 de outubro atividade anómala nos sistemas que guardam as variáveis de ambiente dos seus clientes. Um terceiro conseguiu aceder a variáveis cifradas e nalguns casos decifrá-las. A Railway pausou todos os deploys e pede para rodar credenciais. Não publicou quantos clientes foram afetados nem como os atacantes entraram.
• O LiteLLM 1.107.0, publicado a 21 de outubro no PyPI e no Docker Hub, contém um ladrão de credenciais e um carregador remoto que se ativa ao arrancar qualquer processo Python do host, não só o LiteLLM. Os atacantes publicaram-no com tokens OAuth do GitHub CLI roubados a três engenheiros. A tag do GitHub não contém o código malicioso, que só está nos pacotes publicados. É a segunda vez este ano.
• A PingCAP informa que, entre 9 de setembro e 7 de outubro, alguém usou credenciais roubadas de uma conta de serviço para entrar em sistemas internos e copiar dados e código-fonte: metadados de contas e projetos, texto do editor SQL, registos de faturação e valores cifrados de API keys. Não há evidência de impacto nos dados guardados no TiDB. O grupo FulcrumSec diz ter 10,6 TB; a PingCAP não o confirmou.

A ordem importa, porque rodar uma chave num host que continua comprometido só entrega ao atacante a chave nova.

1. Conter. Com o LiteLLM 1.107.0, pare o serviço e reconstrua o host ou o contentor a partir de uma imagem limpa com a versão fixada em 1.106.2 (litellm==1.106.2 no requirements.txt, ou a tag de imagem exata, nunca latest). O carregador corre com qualquer processo Python, por isso remover só o pacote não chega.
2. Fazer inventário. Liste o que estava nesse host ou nessas variáveis: chaves de fornecedores de LLM, credenciais da cloud, palavras-passe de base de dados, tokens de CI, webhooks, chaves do gateway de pagamento. Na Railway, a lista são as variáveis de cada serviço e ambiente.
3. Começar pelo que abre mais portas. Primeiro, credenciais com permissões amplas (IAM ou contas root da cloud, tokens de CI/CD e do GitHub, utilizadores de base de dados), depois as APIs de terceiros.
4. Emitir, implementar, revogar. Crie a credencial nova, implemente-a e revogue a antiga. Com os deploys da Railway em pausa, revogar antes de poder atualizar a variável deixa o serviço em baixo até voltarem; para chaves de pagamento ou da cloud, uma paragem curta custa menos do que deixar viva uma chave divulgada.
5. Ver o uso da chave antiga. Reveja os registos de acesso do fornecedor (CloudTrail, o painel da API, os logs da base de dados) desde o dia do incidente.

Se os seus serviços guardam as credenciais num gestor de segredos e não em variáveis escritas à mão, o passo 4 fica muito mais curto. É uma das coisas que revemos nos projetos de cloud e DevOps e ao desenhar APIs que dependem de chaves de terceiros. Se preferir que a rotação fique connosco, veja rotação de segredos e API keys expostas.

3. Certificados: GoDaddy e eMudhra

A GoDaddy revogou a 21 de outubro 404.607 certificados TLS das suas hierarquias GoDaddy e Starfield porque os OID de política e a URI do CPS desses certificados não coincidiam com o CPS publicado (Mozilla Bug 2082703). Ninguém roubou chaves; o problema é que um site com um desses certificados pode deixar de carregar se não instalar o de substituição.

A eMudhra, uma CA indiana, gerou em abril de 2025 oito certificados de CA intermédia TLS com chaves fracas por causa de uma falha na sua cerimónia de geração de chaves, e essas chaves foram recuperadas a partir dos certificados públicos. O Chrome bloqueou-os, a Apple a 19 de outubro e a Microsoft a 20; Go e Node.js publicaram uma desconfiança explícita (a release do Node de 21 de outubro já rejeita essas cadeias). Não há ataques confirmados contra utilizadores.

Para saber quem emitiu o seu certificado e quando expira:

echo | openssl s_client -connect oseudominio.com:443 -servername oseudominio.com 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -serial

• Se o issuer contiver GoDaddy ou Starfield, entre na sua conta GoDaddy, verifique se esse certificado tem uma substituição emitida e instale-a em todos os servidores, balanceadores e CDN onde estiver o antigo.
• Se o seu site depende de uma das intermédias da eMudhra, Chrome, Safari e Windows já não o aceitam e precisa de pedir um certificado a outra CA. Para ver a cadeia completa, intermédias incluídas, procure eMudhra nas linhas i: (emissor) desta saída:

echo | openssl s_client -connect oseudominio.com:443 -servername oseudominio.com -showcerts 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

• O caso que mais escapa é o de saída: um serviço seu em Node ou Go que chama uma API assinada por essas intermédias vai começar a falhar com um erro TLS depois de atualizar. Se depois do patch do Node aparecerem erros de certificado em chamadas de saída, verifique com o mesmo comando o domínio que está a chamar.

Se preferir não fazer isto sozinho

Na Soamee fazemos este trabalho nos projetos que mantemos: inventário de versões de PHP, Node, NGINX e GitLab; mitigação imediata onde ainda não é possível atualizar; atualização e verificação; revisão de indícios de comprometimento; rotação de segredos pela ordem acima e troca de certificados. Ninguém consegue deixar um servidor invulnerável, por isso não o prometemos. O que fica é um registo de que versão tem, o que foi alterado e o que falta.

Se tem servidores ou deploys e não sabe se algum destes oito avisos o afeta, conte-nos numa consultoria gratuita ou escreva-nos através do contacto.

Fontes

• PHP: php.net · Rapid7 · Huntress · NCSC
• Node.js: October 2026 Security Releases
• NGINX: nginx security advisories · CSA Research Note sobre a CVE-2026-42945 · Help Net Security, 18-mai-2026
• GitLab: Critical Patch Release 19.5.1 · The Hacker News sobre a CVE-2026-97229
• Railway: The CyberSec Guru
• LiteLLM: Wiz
• PingCAP: Security update, outubro 2026
• GoDaddy: CyberPress
• eMudhra: The Hacker News
• Previsão de CVE em 2026: Help Net Security, 15-jun-2026