servidor
15 artigos com esta tag
CVE-2026-98432 do kernel do Linux: um use-after-free de TCP acionável pela rede (CVSS 9.8); instale o kernel corrigido, reinicie e verifique o MPTCP
CVE-2026-98432 é um use-after-free no código TCP IPv4 do kernel do Linux, publicado em 15 de outubro de 2026. A CNA do projeto do kernel o pontua com CVSS v3.1 9.8 (rede, sem privilégios, sem interação do usuário). Segundo relatos, pesquisadores de uma empresa de IA demonstraram, em laboratório e conforme seu próprio relatório, a execução remota de código como root contra um servidor com um listener Multipath TCP (MPTCP). O BleepingComputer diz que a execução remota de código em servidores TCP comuns não foi demonstrada publicamente e que nenhuma exploração ativa foi confirmada, e este site não encontrou o CVE no catálogo KEV da CISA em 1º de novembro. As correções upstream estão em 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10 e posteriores. Em 1º de novembro, o Debian tem kernels corrigidos, a SUSE tem alguns, e Ubuntu e Red Hat listam as correções como em andamento. Desativar apenas o MPTCP não é uma correção completa. Conclusão deste site: atualize os servidores Linux expostos à internet conforme as correções forem chegando, reinicie e use uma medida provisória do fornecedor apenas até lá.
O que verificar após uma atualização de emergência do PHP: PHP web vs. PHP de linha de comando, set -e e códigos de saída do diff, e uma nova verificação de invasão
Durante a resposta de outubro de 2026 às vulnerabilidades críticas do PHP, um site administrado pelo operador deste site tinha atualizado o PHP web, mas o PHP de linha de comando usado pelo cron ainda apontava para uma versão antiga. Verifique o web e o CLI separadamente. Com set -e, diff e grep retornam status de saída 1 para 'diferenças encontradas' ou 'sem correspondência', o que interrompe o script; trate 0, 1 e 2 separadamente. Após a correção, execute a mesma lista de verificação de invasão em todos os servidores, e esclareça uma entrada de log suspeita comparando os arquivos ativos com a cópia conhecida como boa, implantada anteriormente.
VMware ESX CVE-2026-41709 (CVSS 2.7): a CISA lista como explorada essa falha de registro de baixa gravidade; aplique todo o VMSA-2026-0006 e verifique seus hosts
CVE-2026-41709 é uma falha de registro insuficiente no VMware ESX (CVSS 2.7, baixa): um atacante que já tem acesso de administrador pode realizar certas operações sem que elas fiquem registradas nos logs. A Broadcom a corrigiu no aviso VMSA-2026-0006 em 29 de julho de 2026, sem solução alternativa. Em 28 de outubro de 2026 (horário dos EUA) a CISA a incluiu em seu catálogo de vulnerabilidades exploradas conhecidas (KEV), com prazo de 11 de novembro para as agências federais dos EUA. O relatório de ameaças de uma empresa de segurança diz que um grupo ligado à China a usou como dia zero em várias invasões a organizações dos EUA, até o início de 2026, e a SecurityWeek descreve a finalidade como reduzir a visibilidade da trilha de auditoria; este site não verificou esse relatório de forma independente. A falha não dá entrada por si só, mas significa que os logs de um host afetado podem não mostrar o que um invasor fez. O mesmo aviso inclui duas falhas do vCenter com nota 9,8, uma das quais (CVE-2026-59310) a CISA listou como explorada em 18 de agosto, de modo que aplicar apenas a correção da falha do ESX deixa abertas as portas de entrada. Conclusão deste site: atualize ESX e vCenter para os builds corrigidos de todo o aviso, envie os logs dos hosts para um servidor separado e procure sinais de comprometimento em vez de confiar apenas nos logs.
Fragnesia do kernel do Linux (CVE-2026-46300): a CISA a lista como explorada com prazo em 31 de outubro; atualize o PHP e o kernel e reinicie
O CVE-2026-46300, apelidado de Fragnesia, é uma falha no kernel do Linux que permite a um usuário local com poucos privilégios obter root (CVSS v3.1 7.8, vetor de ataque local). Quando o kernel move fragmentos de dados entre buffers de rede, ele pode perder uma marca que indica que os dados são compartilhados com um arquivo na memória, e o código IPsec ESP pode então descriptografar sobre a cópia em cache de um arquivo somente leitura. O projeto do kernel publicou o CVE em 23 de maio de 2026, e as correções estão nos kernels 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 e 7.0.10 e posteriores. Em 28 de outubro de 2026 (horário dos EUA), a CISA a adicionou ao seu catálogo de vulnerabilidades exploradas conhecidas (KEV) com base em evidências de exploração ativa, com prazo de 31 de outubro para as agências federais dos EUA. A descrição da CISA diz que ela pode ser encadeada com as falhas do PHP CVE-2026-109618 e CVE-2026-109619 para implantar webshells PHP e executar comandos como root. Uma empresa de segurança relatou que essa cadeia foi usada contra 25 servidores (principalmente firewalls), e a SecurityWeek repetiu o relato; este site não verificou os números de forma independente. Ubuntu, Red Hat e Debian publicaram kernels corrigidos, e uma atualização do kernel só passa a valer depois de reiniciar. Conclusão deste site: se você roda sites PHP em Linux, atualize o PHP e o kernel, reinicie e procure webshells.
Vulnerabilidade CVE-2026-110447 no servidor CODE integrado do Nextcloud Collabora explorada: quem é afetado e o que fazer
Em 14 de outubro de 2026, os desenvolvedores do Collabora Online divulgaram a CVE-2026-110447, uma vulnerabilidade de injeção de comando do sistema operacional, sem autenticação, no app do Nextcloud Collabora Online - Built-in CODE Server (ID do app richdocumentscode). Por meio do proxy.php do app, comandos podem ser executados como o usuário do servidor web. A condição é que o servidor CODE integrado não esteja em execução, o que pode acontecer após reinicialização de contêiner, atualização ou falha. Versões anteriores à 26.4.303 são afetadas; a 26.4.303 foi lançada em 11 de setembro. Os desenvolvedores afirmam que desativar o app não impede o problema e pedem que os usuários atualizem ou removam o app. No Nextcloud 29 e versões anteriores, que já não recebem suporte, atualize o Nextcloud ou remova o app. Os desenvolvedores afirmam que servidores Collabora Online independentes, imagens Docker, pacotes RPM/DEB e Nextcloud All-in-One não são afetados. A pontuação CVSS v4.0 é 9,2. A CISA incluiu a falha em seu catálogo Known Exploited Vulnerabilities (KEV) em 23 de outubro, com prazo em 26 de outubro. Usuários relataram ataques a partir de cerca de 10 de setembro no repositório dos desenvolvedores e, segundo reportagens da imprensa, web shells foram plantados. Conclusão deste site: se o app CODE integrado estiver instalado, mesmo desativado, verifique a versão hoje, atualize ou remova o app e depois procure sinais de comprometimento desde 10 de setembro.
GitLab CVE-2026-110264 (CVSS 10.0) e a CVE-2026-97229 explorada: como verificar e atualizar um GitLab self-managed
Em 21 de outubro de 2026, o GitLab lançou as versões de correção crítica 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13 para a Community Edition (CE) e a Enterprise Edition (EE). A falha mais grave, a CVE-2026-110264 (CVSS 10.0), é um estouro de inteiro ao compilar uma expressão regular especialmente elaborada que, sob certas condições, poderia permitir que um usuário não autenticado executasse código arbitrário no servidor GitLab. Quase todas as versões a partir da 7.0 são afetadas. Em 29 de outubro, a CISA incluiu uma falha irmã, a CVE-2026-97229 (CVSS 10.0, CWE-190), em seu catálogo de Vulnerabilidades Exploradas Conhecidas (KEV), com prazo até 1º de novembro. É o mesmo tipo de bug (um estouro de inteiro no compilador de expressões regulares de CI/CD, alcançável por um usuário não autenticado); o GitLab a corrigiu antes, em 12 de outubro, nas versões 19.4.2, 19.3.5 e 19.2.8, e ela afeta apenas 19.2.0 a 19.2.7, 19.3.0 a 19.3.4 e 19.4.0 a 19.4.1. Quem ainda está abaixo da 19.4.2, 19.3.5 ou 19.2.8 está exposto a uma falha explorada. Atualizar para as versões recomendadas aqui (19.5.1, 19.4.3, 19.3.6, 19.2.9) também corrige a CVE-2026-97229. O GitLab.com já está corrigido; instalações self-managed precisam ser atualizadas. A mesma versão de 21 de outubro corrige duas falhas de gravidade Alta (CVSS 8.2 e 7.5) e outras, mas essas correções só chegam nas linhas 19.3.6, 19.4.3 e 19.5.1. A causa raiz está no motor de expressões regulares do Ruby (Onigmo), e o Ruby lançou 4.0.9, 3.4.12 e 3.3.13 em 23 de outubro. Aplicações que compilam uma regexp a partir de strings controladas pelo atacante são afetadas, e o Regexp.timeout não protege contra os bugs. Os avisos do GitLab não dizem que a CVE-2026-110264 tenha sido explorada, e ela não consta no KEV em 30 de outubro. A Alpine Linux relatou uma tentativa de ataque contra o seu próprio GitLab pela CVE-2026-97229 em 20 e 21 de outubro, e que atualizar apenas o GitLab (para a 19.3.6) não fechou a falha porque a correção também exigia um Ruby corrigido; reconstruiu a instância e não encontrou evidência de que código do invasor tenha sido executado. Conclusão deste site: atualize o GitLab self-managed hoje, após verificar as paradas obrigatórias de atualização, chegue à 19.3.6 ou posterior e, se você mesmo compila o GitLab ou usa seu próprio Ruby, confira que esse Ruby também seja 3.3.13, 3.4.12 ou 4.0.9 ou posterior. Aplicações Ruby devem migrar para um Ruby corrigido e parar de montar regexps a partir de entrada do usuário.
SiteGuard Server Edition CVE-2026-106931 explorada: quem é afetado e o que fazer
Em 14 de outubro de 2026, a EG Secure Solutions divulgou a CVE-2026-106931, uma vulnerabilidade de injeção de comandos do SO no recurso de estatísticas do SiteGuard Server Edition, seu firewall de aplicações web (WAF) baseado em host, e afirmou que a exploração já foi confirmada. A exploração pode permitir a execução de comandos arbitrários do SO com privilégios de root ou SYSTEM no servidor que executa o produto. São afetadas as versões Ver2.20 e posteriores com o recurso de estatísticas ativado (ele vem ativado por padrão): as edições Apache, Nginx e IIS anteriores à Ver8.00 Update5, e as edições FreeBSD Apache e Nginx anteriores à Ver7.00 Update6. A edição IIS da Ver3.10 até a Ver4.00 Update4 não é afetada. As correções são a Ver8.00 Update5 e a Ver7.00 Update6; para sistemas que não podem ser atualizados, há um patch disponível, inclusive para versões sem suporte. O fornecedor classifica a falha como de vetor de ataque local, com privilégios baixos necessários (CVSS v3.0 7,8; v4.0 8,5). O JPCERT/CC emitiu um alerta, dizendo ter confirmado que o produto é amplamente usado no Japão, e que desativar o recurso de estatísticas evita o problema. A CISA incluiu a falha em seu catálogo de Vulnerabilidades Conhecidas Exploradas (KEV) em 20 de outubro, com prazo até 23 de outubro. Conclusão deste site: se você usa o Server Edition, verifique hoje a versão e o recurso de estatísticas, salve os dados de diagnóstico antes de atualizar e depois aplique a versão corrigida ou o patch.
[Urgente] Falhas do PHP CVE-2026-109618 e CVE-2026-109619 já estão sendo exploradas e entram no catálogo KEV da CISA: atualize para 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 agora
Em 21 de outubro de 2026, a equipe de segurança do PHP lançou o PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, corrigindo duas vulnerabilidades críticas que podem permitir execução remota de código (RCE) sem autenticação, e pediu que todos os usuários atualizem imediatamente. O CVE-2026-109618 envolve o tratamento de falta de memória (out-of-memory), e o CVE-2026-109619 envolve estado interno obsoleto que sobrevive entre requisições; ambos têm nota 9,2 no CVSS v4.0. Todas as instalações do PHP que atendem requisições web estão em risco (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). A equipe considera o mod_php o de maior risco, citando um exploit demonstrado em que uma requisição sem autenticação dispara o ataque antes de qualquer código da aplicação ser executado. O PHP 8.1 e versões anteriores não recebem atualização oficial; a equipe disponibilizou backports mínimos de código-fonte para 7.4, 8.0 e 8.1. As distribuições Linux receberam os patches antecipadamente. Não há mitigação completa; atualizar é a única escolha segura. Em 22 de outubro, o IPA e o JPCERT/CC do Japão emitiram alertas, e a JVN publicou a JVNVU#99905564. A CISA, que não havia observado exploração quando publicou seu alerta pela primeira vez, incluiu as duas falhas no catálogo Known Exploited Vulnerabilities (KEV) em 26 de outubro, com prazo até 29 de outubro para as agências civis federais dos EUA. Segundo reportagens da mídia, honeypots de um pesquisador de segurança rodando o PHP 8.4.26 sem patch sob mod_php registraram execução remota de código bem-sucedida em 24 de outubro. Os honeypots de um grande provedor de nuvem já haviam registrado tentativas de exploração a partir de 17 de outubro, quatro dias antes da divulgação. Até onde este site conseguiu verificar, nenhuma invasão fora de honeypots havia se tornado pública até 27 de outubro. A maioria dos grandes provedores de hospedagem compartilhada do Japão anunciou que a correção foi aplicada, mas alguns, como a KAGOYA, ainda não. Em 23 de outubro, a equipe do PHP divulgou uma terceira questão (CVE-2026-115560) que os lançamentos de 21 de outubro não corrigem. Ela pode levar à execução de código somente com uma combinação específica de configuração e código da aplicação; a equipe considera isso improvável na prática, vai distribuir a correção e um aviso completo com a próxima versão regular, e recomenda definir session.upload_progress.enabled=0 até lá. As versões afetadas e uma pontuação CVSS não foram publicadas, e nenhuma exploração foi relatada. Até 29 de outubro (verificado no php.net), não havia versão com correção para essa questão. Em 28 de outubro, a CISA incluiu também no KEV a falha do kernel do Linux CVE-2026-46300 (prazo em 31 de outubro para as agências federais dos EUA) e disse que ela pode ser encadeada com estas duas falhas para implantar webshells de PHP e executar comandos como root. A visão deste site: a exploração já está confirmada, então confirme se você ou seu provedor atualiza o PHP de cada site e migre para a versão corrigida hoje. Verifique também os logs a partir de 17 de outubro em busca de sinais de invasão. Na hospedagem compartilhada, verifique o aviso de conclusão do seu provedor no site oficial.
A segurança do site afeta o SEO? Vulnerabilidades, sites invadidos, HTTPS e ranqueamento segundo a documentação oficial do Google
O Google não lista vulnerabilidades como fator de ranqueamento. O dano vem quando alguém as explora. Páginas de spam colocadas por um invasor fazem os resultados mostrarem "Este site pode ter sido invadido", malware ou phishing disparam o alerta "Site perigoso" no Chrome (outros navegadores mostram os próprios alertas da Navegação segura) e sites que violam as políticas contra spam podem ficar mais abaixo ou nem aparecer. Em 2014 o HTTPS foi anunciado como um sinal "muito leve", e a documentação atual do Google sobre experiência na página diz que, além das Core Web Vitals, os outros aspectos da experiência na página não ajudam diretamente um site a ranquear melhor. A visão deste site: para o SEO, gaste o seu tempo em não ser invadido e em perceber rápido se for, não em aumentar uma nota de segurança.
Como verificar se o seu site ou servidor foi invadido: verificações passo a passo para hospedagem compartilhada, WordPress e VPS, e o que fazer primeiro se encontrar algo
Verificar se um site foi invadido significa olhar tanto os sinais visíveis de fora quanto os rastros deixados dentro. Sinais: o relatório Problemas de segurança do Search Console, um rótulo 'Este site pode ter sido invadido' na busca, um aviso da hospedagem, administradores desconhecidos, redirecionamentos que acontecem só no celular ou a partir da busca. Rastros: usuários administradores, arquivos do núcleo modificados (wp core verify-checksums), histórico de login, authorized_keys, cron, portas em escuta, arquivos alterados recentemente. A visão deste site: não encontrar nada não prova que está limpo. Se encontrar algo, preserve as evidências antes de limpar, troque todas as credenciais a partir de um aparelho limpo, restaure um backup anterior à invasão ou reconstrua, feche o ponto de entrada e só então peça uma revisão.
Você deixou um arquivo de segredo em um diretório público? Audite seu webroot
Qualquer coisa no seu webroot pode ser baixada pela URL por qualquer um. Um JSON de token/credenciais esquecido, um .env ou um backup significam exposição instantânea — e se veio de um template compartilhado, todo site tem o mesmo arquivo. Correção: coloque no diretório público só o que pode ser compartilhado, mantenha segredos fora do webroot com permissão 600 e, ao achar um, audite todos os sites e hosts.
Inventário de segurança: 7 verificações que quem roda vários servidores ignora
Para operadores solo/pequenos, incidentes vêm menos de controles ausentes do que de estado não rastreado. A fronteira é o PC que guarda suas chaves. Priorize o 2FA conforme qual conta pode recuperar as outras (o e-mail primeiro), liste qual chave SSH abre qual servidor e apague duplicatas, chaves sem uso e cadastros esquecidos, remova senhas em texto puro da nuvem, remedie de forma reversível uma de cada vez e mantenha segredos fora do registro. Inventarie antes de adicionar ferramentas.
Git auto-hospedado vs. GitHub: qual é de fato mais seguro?
Auto-hospedar o Git não te torna 'mais seguro' — realoca o risco. A classe de exposição pública acidental desaparece, mas aplicar patches no servidor, backups e detecção de segredos pré-commit passam para você. A escolha certa se você continua fazendo esse trabalho; pior que o GitHub se você o negligencia. A visão deste site: a auto-hospedagem só funciona junto com seus controles compensatórios.
Menor privilégio para chaves SSH: mantenha as chaves de root de produção fora de ambientes efêmeros que podem ser comprometidos
Cadastrar uma chave de root em produção a partir de um ambiente efêmero e comprometível (pod de GPU, runner de CI, VM descartável) significa que, no momento em que o ambiente é comprometido, um atacante ganha root em produção. Correção: sem chaves de root em ambientes efêmeros; remova chaves quando não usadas; se precisar de novo, use um usuário sem root mais uma chave restrita a comando que limita a chave a uma operação. Trate uma chave reutilizada como seu ativo mais crítico e nunca construa um cenário em que uma chave vazada abre todos os servidores.
Mantendo o .env fora da web pública em hospedagem compartilhada
A correção principal: corpo do app fora do docroot, só public/ exposto. Bloqueie o acesso com .htaccess primeiro, torne-o permanente reestruturando e então autoverifique. A visão deste site: isto não é o deslize de uma pessoa, mas um layout perigoso que virou padrão em todo o setor — corrija com processo, não com vigilância. bootstrap-redirect vence o symlink.