Tailscale confirma falhas; Laravel corrige bypass crítico
Falha confirmada sem patch no Tailscale, bypass crítico no Laravel e segredos roubados em massa no GitHub.
O resumo de 30 segundos
- Tailscale confirmou as 11 falhas relatadas sem divulgação coordenada; correção prometida em 24 horas, ainda sem CVE ou versão patchada.
- PHP2Shell segue sem correção nas versões 8.1 e anteriores; fornecedores como QNAP, Oracle e IBM publicam patches para produtos que embutem PHP.
- Laravel corrigiu bypass crítico de autenticação de API: sem token, atacante entrava como qualquer usuário. Atualize para 12.68.0 ou 13.29.0.
- Causa do ataque ao LiteLLM veio à luz: chave de administração vazada em maio e nunca revogada permitiu sequestrar o pipeline de release.
- Grupo Gheist injetou workflows maliciosos em 13.500 branches do GitHub; segredos apareciam em logs que os atacantes apagavam segundos depois.
Tailscale confirma falhas reais e promete correção em 24 horas
A Tailscale confirmou que as 11 falhas apontadas pela auditoria Tailworm, publicadas sem aviso prévio em 25 de outubro, são reais. A empresa classificou os problemas como sérios, em sua maioria escalada de privilégio, e disse esperar corrigir em até 24 horas.
O ataque pressupõe um dispositivo já invadido: a partir dele, o invasor obtinha acesso de administrador em outros servidores via Tailscale SSH, segundo testes em laboratório. Não havia versão corrigida numerada em 27 de outubro; equipes devem aplicar as mitigações enquanto a correção não sai.
Para o time técnico
Onze falhas no cliente Tailscale (tailscaled, Tailscale SSH, serve, app connectors) e no headscale, divulgadas sem coordenação pela pesquisadora Erica Windisch, da Cyberdione Labs. Condições de corrida no servidor SSH embutido no tailscaled, que roda com root, permitem escalada de privilégio e movimento lateral via encaminhamento de porta.
- Afetados
- tailscale v1.104.2 e headscale v0.29.5 (versões testadas no relatório Tailworm)
- Exploração
- não observada
- Correção
- Nenhuma versão numerada em 27/10/2026; Tailscale mira correção em 24 horas. Mitigações: TS_SSH_DISABLE_FORWARDING=1 no serviço tailscaled e reinício, regras de SSH restritas, remoção de capacidades de app connector não usadas e limites de memória no headscale exposto
O que fica: Confiança na rede privada não substitui teste regular: um host invadido alcançou servidores de toda a frota.
Fontes: Tailscale, @TheHackersNews, @IntCyberDigest, @The_Cyber_News
No radarAcompanhe este incidente ao vivo →PHP2Shell: onda de correções chega a produtos que embutem PHP
O aviso da JPCERT/CC (centro de resposta a incidentes do Japão), atualizado em 26 de outubro, lista correções para produtos que embutem PHP: QNAP, Oracle, Check Point, IBM SevOne, PAN-OS em Siemens RUGGEDCOM e Peplink. As falhas PHP2Shell já têm exploração confirmada na internet.
Versões antigas seguem expostas: o PHP corrigiu nas versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mas as sem suporte, 8.1 e anteriores, exigem migração. Segundo a Unit 42, em um governo europeu atacantes tentaram virar administradores de domínio em cerca de duas horas.
Para o time técnico
CVE-2026-109618 (OOM bailout para UAF) e CVE-2026-109619 (corrupção de estado para UAF): RCE sem autenticação, CVSS 9.2. A Unit 42 confirma pós-exploração conduzida com agentes de IA, marcada por comandos com delimitadores como ==SHELLUSER== e ==PASSWD==, acesso a hashes de senha e segredos de MFA e túnel NTLM-relay para o Active Directory.
- CVE
- CVE-2026-109618, CVE-2026-109619
- Afetados
- PHP 5.4 a 8.5.11 em todos os branches servindo requisições web; versões EOL 8.1 e anteriores sem correção do projeto PHP; produtos QNAP, Oracle, IBM SevOne, PAN-OS em Siemens RUGGEDCOM APE1808 e Peplink
- Exploração
- ativa confirmada
- Correção
- PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35; pacotes Ubuntu, RHEL (RHSA-2026:87151), Peplink, IBM e demais fornecedores; migrar versões EOL para branch com suporte
Fontes: JPCERT/CC, @DailyDarkWeb, @zerodayalpha
No radarAcompanhe este incidente ao vivo →Laravel corrige bypass de autenticação no TokenGuard
O Laravel corrigiu uma falha crítica no TokenGuard, o mecanismo padrão de autenticação de API por token. Em certas configurações de banco MySQL e MariaDB, um atacante sem credenciais entrava como qualquer usuário existente, sem conhecer o token dele.
O efeito é tomada de conta: vale para qualquer rota protegida por esse guard, com nota CVSS 9.2. A correção saiu em 23 de outubro nas versões 12.68.0 e 13.29.0; aplicações com API por token em MySQL ou MariaDB devem atualizar e revisar logs.
Para o time técnico
CVE-2026-114509: bypass de autenticação no TokenGuard com credenciais de API não-string. Dependendo do comportamento de comparação do MySQL/MariaDB, a consulta aceita credencial inválida e autentica como usuário arbitrário existente. Há PoC pública e mais de 2,8 milhões de superfícies Laravel expostas mapeadas na internet no último ano, segundo o @fofabot.
- CVE
- CVE-2026-114509
- Afetados
- laravel/framework < 12.68.0; >= 13.0.0, < 13.29.0
- Exploração
- PoC pública
- Correção
- Atualizar laravel/framework para 12.68.0 (linha 12) ou 13.29.0 (linha 13) e revisar logs de autenticação de API
O que fica: Falha de autenticação passa anos em produção até alguém testar o login com entradas fora do padrão.
Fontes: laravel/framework, @fofabot, NVD
No radarAcompanhe este incidente ao vivo →403 sites do governo indiano seguem com certificados revogados da eMudhra
A Tensorust encontrou 403 sites do governo indiano ainda exibindo certificados revogados da eMudhra (certificadora digital da Índia), após o comprometimento de autoridades que emitem certificados digitais. A eMudhra pediu desculpas e anunciou revisão por especialistas.
Com as chaves privadas recuperáveis, quem as tiver pode emitir certificados que sistemas sem atualização aceitam como genuínos e interceptar conexões HTTPS. Go, Node.js, Python, Electron, NSS e Java publicaram versões que removem a confiança; nenhuma exploração foi relatada.
Para o time técnico
Chaves privadas de oito intermediários TLS da eMudhra (emSign) foram demonstradas como recuperáveis a partir dos certificados públicos em 17/10/2026 e os certificados revogados em 18/10. Java não verifica revogação por padrão, então aplicações Java e imagens Docker com Java embutido exigem correção própria (Web3Signer até 26.10.1, Teku até 26.10.2).
- CVE
- CVE-2026-111943, CVE-2026-91403, CVE-2026-115557, CVE-2026-114820
- Afetados
- Clientes que confiam nos intermediários ECC da eMudhra antes dos bloqueios de 17 a 21/10/2026; Go antes de 1.27.3/1.26.10; Electron antes de 44.9.1/43.8.1/42.11.16; certifi antes de 2026.10.19; pip antes de 26.2.2; uv antes de 0.13.4
- Exploração
- não observada
- Correção
- Go 1.27.3/1.26.10; Node.js 22.23.4/24.22.1/26.12.1; Electron 44.9.1/43.8.1/42.11.16; Python 3.15.2/3.14.10/3.13.18/3.12.16/3.11.18; certifi 2026.10.19; NSS 3.131.1; versões OpenJDK listadas; reconstruir imagens Docker com Java próprio e atualizar ca-certificates do sistema
Chave vazada em maio e nunca revogada causou ataque ao LiteLLM
O LiteLLM identificou a causa: uma chave de administração, exposta por acidente em maio e nunca revogada, permitiu sequestrar o pipeline de release que distribuiu a versão 1.107.0 maliciosa. A The Record estima dezenas de milhares de usuários atingidos.
A versão maliciosa ficou três horas no ar, com mais de 49.000 downloads no repositório PyPI, e roubava senhas de navegador, chaves de nuvem e chaves de IA. A Wiz relatou credenciais roubadas em uso cerca de 4,5 horas depois.
Para o time técnico
litellm==1.107.0 no PyPI e nas imagens Docker/GHCR (tags v1.107.0, latest, main-latest, main-stable) instalava info-stealer que exfiltrava senhas de navegador, chaves AWS/GCP/Azure, chaves SSH e GPG, variáveis de ambiente e chaves de API de IA para litellm[.]dev. O pipeline foi sequestrado com tokens do GitHub roubados após o vazamento da master key.
- Afetados
- litellm==1.107.0; imagens Docker/GHCR tags v1.107.0, latest, main-latest e main-stable na janela de 21/10/2026
- Exploração
- ativa confirmada
- Correção
- Fixar em 1.106.2 (última versão conhecida segura); 1.107.0 removida do PyPI, Docker Hub e GHCR; rotacionar toda credencial alcançável pela máquina afetada, incluindo tokens do GitHub, e bloquear litellm.dev
O que fica: Credencial vazada e esquecida virou ataque meses depois; rotação automática de chaves expostas custa menos que resposta.
Fontes: The Record, OSV, The Hacker News
No radarAcompanhe este incidente ao vivo →Falha do Brotli tem execução remota demonstrada e vira HTTP2Shell
Pesquisadores demonstraram execução remota de código explorando a falha do decodificador de compressão Brotli em uma build do Node.js, com dados comprimidos forjados. O cenário ganhou o apelido HTTP2Shell e a lista de software afetado segue crescendo.
Qualquer aplicação que descomprima dados Brotli de fontes não confiáveis, comum em respostas HTTPS, pode ter memória corrompida, dados lidos ou código executado por invasor sem autenticação. O GitHub avalia a falha como crítica, CVSS 9.2.
Para o time técnico
Escrita fora dos limites no decodificador Brotli do Google, CVE-2026-111497, apelidada Node2Shell/HTTP2Shell/Broccoli2Shell. Invasor não autenticado que forneça dados Brotli maliciosos pode derrubar o processo, vazar memória ou executar código. RCE foi demonstrada em build do Node.js; a falha foi reportada ao Node.js pelo Codex Security da OpenAI. Versões EOL do Node.js não recebem correção.
- CVE
- CVE-2026-111497, CVE-2026-105482, CVE-2026-105483, CVE-2026-106069, CVE-2026-105481, CVE-2026-106072, CVE-2026-106074, CVE-2026-106070, CVE-2026-106071, CVE-2026-106073
- Afetados
- Brotli 1.0.3 a 1.0.9, 1.1.0 e 1.2.0; Node.js 22.x antes de 22.23.4, 24.x antes de 24.22.1, 26.x antes de 26.12.1, linhas EOL 20.x/23.x/25.x sem correção; Bun antes de 1.4.4; Envoy e Istio com descompressor Brotli configurado; .NET, Visual Studio e PowerShell antes das atualizações de 25/10/2026
- Exploração
- PoC pública
- Correção
- Node.js 22.23.4/24.22.1/26.12.1; Bun 1.4.4; Brotli 1.2.1/1.1.1/1.0.10; PyPI Brotli 1.2.1 e brotlicffi 1.2.1.0; Envoy 1.40.0/1.39.3/1.38.6/1.37.8; Istio 1.29.9/1.30.6/1.31.2; atualizações Microsoft de 25/10; reiniciar serviços e reconstruir imagens de contêiner
Fontes: Microsoft, The Hacker News, @HacktronAI, @BleepinComputer, @IntCyberDigest
No radarAcompanhe este incidente ao vivo →PwnEscape: análise completa da fuga de VMs e correção em backports
A pwn.ai publicou a análise completa da PwnEscape, falha na parte do kernel Linux que atende a rede das máquinas virtuais. Descoberta por Paulos Yibelo no desafio de US$ 1 milhão da Vercel, ela permite a uma máquina virtual escapar do isolamento.
Com pacotes forjados, uma máquina virtual lê memória do servidor hospedeiro, derruba os ambientes da máquina ou obtém privilégios totais. A Vercel afirma que nenhum relato do desafio mostrou acesso a dados de clientes. A correção já está nos backports estáveis do kernel.
Para o time técnico
CVE-2026-99999: falha no lado host da pilha de rede do kernel Linux. Guests KVM/Firecracker enviam pacotes especialmente forjados para vazar memória do host, causar negação de serviço ou executar código com privilégios de root. Validada no desafio de sandbox da Vercel, com write-up técnico e PoC publicados.
- CVE
- CVE-2026-99999
- Afetados
- Kernels anteriores aos backports estáveis 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 e 7.2.11 (verificar pacotes do fornecedor)
- Exploração
- PoC pública
- Correção
- Commit upstream 6785011f8b16 e backports estáveis correspondentes; atualizar o kernel dos hosts de virtualização conforme os pacotes do distribuidor
Gheist rouba segredos de 13.500 branches do GitHub com tokens invadidos
O grupo Gheist usou tokens roubados para criar fluxos de trabalho maliciosos em mais de 13.500 branches e repositórios do GitHub, segundo pesquisa da Wiz publicada em 25 de outubro. Mais de 850 contas comprometidas foram usadas, de projetos pessoais a repositórios privados.
Cada workflow imprimia os segredos do repositório no próprio log, que os atacantes baixavam e apagavam segundos depois. A aprovação obrigatória do GitHub vale só para repositórios públicos, afirma a Wiz; nos privados os workflows rodaram até o fim.
Para o time técnico
Workflows maliciosos criados via GitHub Actions com tokens de acesso roubados de mais de 850 contas. Os workflows exibiam segredos do repositório nos logs de execução, baixados pela API e apagados em segundos. A Wiz observou credenciais de nuvem usadas horas depois para enumerar o AWS Secrets Manager; logs indicam mais de 900 comprometimentos confirmados, com varredura capaz de atingir milhões de alvos.
- Afetados
- Mais de 13.500 branches e repositórios; contas de projetos pessoais, repositórios privados e GitHub Enterprise Server
- Exploração
- ativa confirmada
- Correção
- Revogar tokens expostos, revisar branches e workflows desconhecidos, trocar todos os segredos acessíveis às contas comprometidas e verificar registros de acesso ao AWS Secrets Manager
O que fica: Segredo impresso em log de CI é segredo entregue; revisar workflows e rotacionar tokens precisa ser rotina.
Fontes: Infosecurity Magazine, @TheDFIRReport
No radarAcompanhe este incidente ao vivo →Pra fechar
O padrão do dia é o tempo entre falha e correção: versões PHP sem suporte, certificados revogados ainda ativos em sites de governo e uma chave vazada em maio que virou ataque em outubro. Quem testa pouco descobre o problema junto com o atacante. Achar, corrigir e retestar encurta esse intervalo.
Quanto tempo uma falha conhecida leva para ser corrigida aqui?
Na maioria dos casos desta edição, a janela ficou aberta por semanas ou meses.
Solicitar conversa