WordPress
6 artigos com esta tag
Falha do WordPress 7.1.4 CVE-2026-119977: corrigida uma condição de corrida na atualização do núcleo que pode levar à execução remota de código; verifique sua versão e as atualizações automáticas
Em 28 de outubro de 2026, o projeto WordPress lançou a versão de segurança 7.1.4, que corrige uma falha no processo de atualização do núcleo que pode levar à execução remota de código. Segundo o aviso de segurança do WordPress no GitHub, durante uma atualização do núcleo com pacote completo, o WordPress extraía os arquivos novos em um diretório previsível dentro da pasta de atualização acessível pela web, e um atacante sem autenticação que vença uma corrida contra essa extração poderia alcançar a execução remota de código (RCE). A correção está na 7.1.4 e foi portada para todos os ramos até o 4.7 (7.0.8, 6.9.11, 6.8.12 e assim por diante). A Wordfence, como CNA, publicou o CVE-2026-119977 em 31 de outubro, com nota CVSS v3.1 8,1 (alta) e complexidade de ataque alta; o aviso do WordPress a classifica como baixa e não informa nota. Segundo o SecurityWeek, um fornecedor de segurança para WordPress viu a primeira correspondência da sua nova regra de firewall nove minutos após implantá-la e registrou mais de 18.500 requisições direcionadas a locais temporários de atualização nas primeiras 21 horas; o fornecedor não relatou nenhum comprometimento bem-sucedido. A CISA incluiu o CVE em seu catálogo Known Exploited Vulnerabilities (KEV) em 3 de novembro (a entrada do KEV dá às agências federais dos EUA o prazo de 6 de novembro, e a CISA exige delas, além do patch, uma triagem forense conforme a BOD 26-04). Sites com atualizações automáticas em segundo plano devem se atualizar sozinhos; sites com elas desativadas devem atualizar manualmente pela tela Atualizações. A conclusão deste site: trate como explorado, atualize hoje e, se a sua atualização foi tardia, verifique sinais de comprometimento (conselho deste site).
[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.
Rank Math PRO 3.0.123 distribuído com malware (outubro de 2026): quem foi afetado e o que os donos de sites WordPress devem fazer
Em 16 de outubro de 2026 (UTC), o Rank Math anunciou que o Rank Math PRO v3.0.123, versão paga do seu plugin para WordPress, continha malware para um número limitado de usuários que o baixaram entre 20:02 UTC de 15 de outubro e 07:12 UTC de 16 de outubro. O malware poderia comprometer um site se o plugin fosse ativado e poderia recriar sua backdoor oculta sempre que o site fosse visitado. A empresa removeu os arquivos afetados e lançou a v3.0.124 limpa. A versão gratuita distribuída no WordPress.org não é afetada. Não foram divulgados nem o número de usuários afetados nem como o malware chegou aos arquivos. Até 20 de outubro, a última alteração do aviso foi em 19 de outubro, quando foi incluída uma nota de que a versão gratuita não é afetada. Conclusão deste site: trate qualquer site que tenha ativado uma cópia da 3.0.123 obtida durante o período afetado como comprometido e, ou restaure um backup feito antes do período, ou apague toda a pasta do plugin e faça a limpeza na ordem indicada pela empresa. Em qualquer caso, troque todas as credenciais que o site poderia acessar.
Acesso não autorizado a alguns servidores web do ConoHa WING (GMO Internet) (426 contas): dados nas áreas de servidor web dos clientes afetados e o que os donos de sites devem fazer hoje
Em 20 de setembro de 2026, a GMO Internet, Inc. anunciou que, em alguns servidores de hospedagem (servidores web) do seu serviço de hospedagem de aluguel ConoHa WING, um terceiro obteve acesso não autorizado às áreas de servidor web de alguns clientes e instalou um programa malicioso. 426 contas foram afetadas, e os dados envolvidos são os 'dados armazenados nas áreas de servidor web dos clientes'. O acesso e a instalação começaram em 3 de setembro; a empresa detectou o caso em 16 de setembro e, em 18 de setembro, identificou a causa e a abrangência e removeu os programas. Ela diz ter identificado a causa, mas não a divulgou. Dados de membros, contratos e pagamentos são gerenciados em um ambiente separado e não vazaram, segundo a empresa. O comunicado não diz se os dados das áreas de servidor web foram copiados. Os clientes afetados foram contatados individualmente no endereço de e-mail cadastrado, e os clientes que não foram contatados não são afetados. Não houve comunicado de acompanhamento até 15 de outubro. A visão deste site: primeiro verifique se você recebeu um e-mail individual e, se recebeu, siga as instruções dele. Depois, trate as credenciais guardadas na sua área de servidor web (a senha do banco de dados em wp-config.php, chaves de API em .env etc.) como lidas e troque-as, e procure arquivos, administradores e tarefas agendadas adicionados desde 3 de setembro.
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.
Segurança do WordPress — uma referência de hardening para produção
O WordPress tem a maior participação, então é o maior alvo, mas as vias de entrada são previsíveis (vulnerabilidades de plugins/temas, atualizações puladas, administradores fracos, painéis de administração expostos). Esta é uma referência de trabalho: (1) uma lista de verificação de hardening por ordem de prioridade (P0–P2), (2) orientação por área — atualizações automáticas, minimização de plugins/temas, administrador forte + 2FA, redução da exposição da administração (xmlrpc/enumeração via REST/edição de arquivos), wp-config e segredos, permissões de arquivo, HTTPS/backups, atualizações do PHP/dependências, e (3) uma lista de autoverificação. Apenas defensivo — sem passos de ataque.