O projeto PHP divulgou, em 23 de outubro de 2026, um alerta sobre uma nova vulnerabilidade que pode permitir a execução remota de código (RCE) em servidores web. Identificada como CVE-2026-115560, a falha foi anunciada apenas dois dias após o lançamento de atualizações emergenciais para corrigir as vulnerabilidades críticas conhecidas como PHP2Shell. Diferentemente das falhas anteriores, o novo problema afeta apenas aplicações que utilizam uma combinação incomum de configurações. Por considerar o risco de exploração baixo, a equipe do PHP decidiu não disponibilizar uma correção emergencial, recomendando uma medida temporária até a próxima atualização regular. A vulnerabilidade é independente das falhas CVE-2026-109618 e CVE-2026-109619, corrigidas em 21 de outubro nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Portanto, essas atualizações não corrigem o novo problema. Nova vulnerabilidade depende de configurações específicas Segundo o comunicado, a CVE-2026-115560 pode ser explorada apenas quando uma aplicação apresenta simultaneamente determinadas condições relacionadas ao gerenciamento de sessões. Primeiro, a configuração session.serialize_handler precisa estar definida como php_binary ou php_serialize. Em seguida, a aplicação deve alterar esse parâmetro dinamicamente para php, utilizando a função ini_set(), antes de executar session_start(). Além disso, o recurso de acompanhamento do progresso de uploads, chamado session upload progress, precisa permanecer habilitado. Esse mecanismo permite que aplicações acompanhem o andamento do envio de arquivos ao servidor e está ativado por padrão no PHP. A equipe responsável considera essa combinação de configurações pouco provável em ambientes reais. Aplicações que não modificam dinamicamente o manipulador de serialização de sessões não estão expostas a essa vulnerabilidade específica. PHP recomenda desativar recurso até próxima atualização Como medida preventiva, os mantenedores recomendam desabilitar temporariamente o acompanhamento do progresso de uploads por meio da seguinte configuração: session.upload_progress.enabled=0 A mesma recomendação já havia sido apresentada em 21 de outubro como mitigação para a CVE-2026-109619. Portanto, administradores que aplicaram essa configuração anteriormente e a mantiveram ativa não precisam realizar alterações adicionais para mitigar a nova vulnerabilidade. A correção definitiva será disponibilizada durante o ciclo regular de atualizações do PHP, acompanhada de um comunicado técnico completo. Até o momento, o projeto não informou quais versões são afetadas, quais atualizações incluirão a correção ou qual será a classificação de gravidade da CVE-2026-115560. Também não foi esclarecido se a nova vulnerabilidade compartilha a mesma causa técnica da CVE-2026-109619. Ataques contra falhas anteriores já somam milhões de tentativas Enquanto a nova vulnerabilidade permanece sem relatos de exploração, as duas falhas originais do PHP2Shell continuam sendo alvo de atividades maliciosas. A Amazon informou que seus honeypots identificaram uma tentativa de exploração em 17 de outubro, quatro dias antes da divulgação pública das vulnerabilidades. Já a Cloudflare registrou um crescimento expressivo nas tentativas de ataque após a publicação das falhas em 21 de outubro. Segundo a empresa, foram observadas dezenas de milhares de tentativas nos primeiros 45 minutos, número que chegou à casa dos milhões nas primeiras horas de 22 de outubro. Pesquisadores da Sophos e da Arctic Wolf também identificaram tentativas de utilizar as vulnerabilidades para instalar uma variante da botnet Mirai, malware conhecido por comprometer dispositivos e incorporá-los a redes utilizadas em ataques cibernéticos. Entretanto, essas tentativas não tiveram sucesso confirmado. Empresas como Previdian e Wordfence relataram atividades de varredura e sondagem, mas sem evidências de execução de código bem-sucedida. Pesquisadores também observaram dificuldades para desenvolver exploits confiáveis. É importante destacar que toda essa atividade está relacionada às vulnerabilidades PHP2Shell corrigidas em 21 de outubro, e não à nova CVE-2026-115560. Até agora, não foram registrados ataques explorando a nova falha, cuja correção permanece prevista para uma atualização regular do PHP.

Uma vulnerabilidade crítica na biblioteca Pillow, amplamente utilizada para processamento de imagens em Python, pode permitir que invasores executem comandos no sistema operacional de servidores por meio de nomes de arquivos manipulados. A falha, identificada como CVE-2026-112900, recebeu pontuação 9,2 no sistema CVSS e foi corrigida na versão 13.0.0, lançada em 16 de outubro de 2026. O problema está no processamento de imagens EPS (Encapsulated PostScript). Para abrir esses arquivos, o Pillow utiliza o Ghostscript, uma ferramenta externa responsável por converter documentos gráficos em imagens. Entretanto, a biblioteca encaminhava nomes de arquivos ao programa sem a validação adequada, permitindo que entradas manipuladas fossem interpretadas como instruções. Segundo o alerta de segurança, a exploração depende do nome do arquivo, e não do conteúdo da imagem. Isso significa que até um arquivo EPS legítimo pode representar um risco caso o invasor consiga controlar seu nome durante o processamento. A vulnerabilidade afeta as versões do Pillow de 2.6.0 até 12.3.0, mas sua exploração exige que o Ghostscript esteja instalado no servidor e que o atacante consiga manipular o nome do arquivo utilizado pela aplicação. Biblioteca registra 436 milhões de downloads mensais O Pillow está presente em aplicações web, sistemas de upload de imagens, ferramentas de criação de miniaturas, processamento de documentos e PDFs, além de projetos de inteligência artificial e aprendizado de máquina. Segundo a OX Security, empresa que destacou as vulnerabilidades em seu relatório, a biblioteca registra aproximadamente 436 milhões de downloads mensais, demonstrando sua ampla utilização no ecossistema Python. Embora os responsáveis pelo Pillow tenham classificado a CVE-2026-112900 como moderada devido às condições necessárias para exploração, o registro CVE atribuído pelo GitHub apresenta pontuação crítica de 9,2. Até o momento, não há evidências conhecidas de exploração ativa das vulnerabilidades corrigidas nesta atualização. Outras falhas críticas afetam JPEG e TIFF A versão 13.0.0 também corrige vulnerabilidades adicionais, incluindo problemas de corrupção de memória, reutilização de dados antigos após alterações no modo de imagem e estouros de buffer durante o processamento de arquivos JPEG e TIFF. Uma das falhas envolve o formato FlashPix (FPX) e pode permitir a execução de comandos maliciosos quando uma aplicação utiliza a função Image.open() para processar um arquivo especialmente preparado. A exploração depende da presença do pacote opcional olefile. Como o Pillow identifica esses arquivos pelo conteúdo, e não apenas pela extensão, aplicações que processam uploads não confiáveis podem ser afetadas sem necessidade de interação adicional do usuário. Outra vulnerabilidade, identificada como CVE-2026-112403, provoca um estouro de buffer durante a geração de miniaturas de imagens JPEG sem perdas. O problema pode causar o encerramento inesperado do processo, mas o alerta não confirma execução de código. Essa falha foi descoberta pela Anthropic utilizando o Claude para analisar a segurança de softwares de código aberto, com validação manual realizada pela Ada Logics. Uma terceira vulnerabilidade, CVE-2026-112393, está presente no Pillow desde 2013 e afeta operações que salvam imagens TIFF comprimidas diretamente na memória, utilizando recursos como io.BytesIO. Os pesquisadores conseguiram provocar falhas no processo e demonstraram execução de código ao combinar a vulnerabilidade com outro problema que permitia revelar endereços de memória. O salvamento de arquivos TIFF diretamente no disco não é afetado. Os registros CVE das vulnerabilidades relacionadas a EPS, TIFF e miniaturas JPEG apresentam pontuação 9,2, embora as condições de exploração sejam diferentes. A CISA também registra a existência de uma prova de conceito pública para a falha em TIFF. Atualização para Pillow 13.0.0 corrige vulnerabilidades A recomendação é atualizar a biblioteca para a versão 13.0.0 e reconstruir contêineres, pacotes e imagens-base que ainda incluam versões vulneráveis. A atualização pode ser realizada com o comando: pip install -U "Pillow>=13.0.0" A nova versão não oferece suporte ao Python 3.10, exigindo que ambientes nessa versão migrem para o Python 3.11 ou posterior. Enquanto a atualização não estiver disponível, os mantenedores recomendam remover o Ghostscript de servidores que processam uploads não confiáveis, impedir o uso de nomes de arquivos EPS controlados por usuários e adotar precauções nas operações de miniaturas JPEG e processamento de TIFF em memória. Para imagens JPEG não confiáveis, as alternativas incluem evitar determinadas chamadas a draft() e thumbnail(), carregar previamente os dados com load() ou utilizar reducing_gap=None, conforme o fluxo de processamento. As correções abrangem diferentes caminhos de exploração em uma biblioteca amplamente integrada a aplicações Python, especialmente serviços que recebem, convertem e armazenam imagens enviadas por usuários.

A cidade de Columbia, capital do estado americano da Carolina do Sul, enfrenta interrupções em diversos serviços públicos após um ataque cibernético comprometer sistemas da administração municipal. O incidente afetou plataformas utilizadas pelos moradores para pagamentos, solicitações de manutenção urbana e acesso a serviços governamentais. Segundo informações divulgadas ao Recorded Future News, o departamento de tecnologia da informação da prefeitura identificou atividades suspeitas em sua infraestrutura e acionou a South Carolina Law Enforcement Division (SLED), órgão estadual de investigação criminal que assumiu a apuração do incidente. Entre os sistemas afetados está o MyColaSC, plataforma digital utilizada pelos cidadãos para pagar contas de serviços públicos, comunicar problemas não emergenciais e acessar outros serviços municipais. O ataque também interrompeu os Sistemas de Informação Geográfica (GIS) e ferramentas utilizadas pelos serviços de atendimento e controle de animais. Com a indisponibilidade do MyColaSC, a prefeitura orientou os aproximadamente 150 mil habitantes da cidade a utilizar o atendimento telefônico para comunicar problemas como buracos nas ruas, árvores caídas e falhas na iluminação pública. Serviços essenciais continuam funcionando Apesar das interrupções, a administração municipal informou que os principais serviços de segurança pública e infraestrutura crítica permanecem operacionais. Entre eles estão o Departamento de Polícia de Columbia, o Corpo de Bombeiros de Columbia-Richland, as comunicações de emergência pelo número 911, os sistemas de abastecimento de água e o centro de pagamentos, incluindo os serviços de pagamento online. "A cidade de Columbia deseja assegurar aos moradores que os sistemas essenciais de segurança pública e serviços públicos continuam operacionais", declarou um representante da administração municipal. Até o momento, não há confirmação de que o incidente envolva ransomware, modalidade de ataque que pode criptografar sistemas e exigir pagamento para restaurar o acesso. A prefeitura não respondeu aos questionamentos sobre essa possibilidade, e nenhum grupo hacker havia reivindicado a autoria do ataque até quarta-feira (21). A SLED também não apresentou detalhes sobre a investigação e orientou que os pedidos de informação fossem encaminhados diretamente às autoridades municipais. Ataques contra governos locais aumentam nos Estados Unidos O incidente em Columbia ocorre em meio a uma sequência de ataques cibernéticos contra administrações públicas e instituições americanas. Na própria Carolina do Sul, o condado de Spartanburg já havia enfrentado um ataque de ransomware, enquanto um incidente recente provocou a interrupção de sistemas da AnMed, uma grande organização hospitalar sem fins lucrativos. Nas últimas três semanas, cidades e condados de Maryland, Novo México, Utah, Texas, Nebraska, Missouri, Alasca e Arizona também registraram indisponibilidade de serviços decorrente de ataques cibernéticos e incidentes envolvendo ransomware. Columbia está entre os maiores municípios afetados recentemente. Enquanto as autoridades investigam a origem e a extensão do comprometimento, parte dos serviços digitais permanece indisponível, exigindo alternativas de atendimento à população.

A Meta, controladora do Facebook, foi condenada pela Justiça do Novo México, nos Estados Unidos, a pagar US$ 25 bilhões em penalidades por mais de 43 milhões de violações de privacidade. A decisão, anunciada na quarta-feira (21), está relacionada ao escândalo da Cambridge Analytica, revelado em 2018, que envolveu a coleta indevida de informações pessoais de milhões de usuários da rede social. O juiz distrital Francis J. Mathew concluiu que a Meta e o Facebook fizeram declarações enganosas sobre a proteção dos dados dos consumidores. Segundo a decisão, a empresa assegurava aos usuários que eles tinham controle sobre suas informações pessoais, mas essa promessa não correspondia à realidade. "O Facebook prometeu aos usuários que eles controlavam seus dados. Isso era falso", escreveu o magistrado. A penalidade decorre de mais de 43 milhões de infrações à legislação estadual contra práticas comerciais desleais. O processo foi apresentado em 2021, após as revelações de que a Cambridge Analytica, consultoria política britânica, havia obtido dados de usuários do Facebook sem consentimento para construir perfis psicográficos, utilizados na análise de características comportamentais e preferências individuais. Escândalo da Cambridge Analytica envolveu 87 milhões de perfis A coleta de informações ocorreu por meio do aplicativo de teste de personalidade thisisyourdigitallife. Aproximadamente 300 mil pessoas participaram voluntariamente do questionário psicológico, mas o aplicativo também acessava informações associadas aos amigos desses participantes. Com esse mecanismo, a Cambridge Analytica conseguiu reunir dados de aproximadamente 87 milhões de perfis do Facebook, ampliando significativamente o alcance da coleta além dos usuários que haviam instalado o aplicativo. Em 2015, a Meta, então conhecida como Facebook, proibiu o aplicativo por violar as políticas da plataforma e enviou uma solicitação legal para que a Cambridge Analytica excluísse os dados coletados. Após a repercussão internacional do escândalo, a consultoria anunciou o encerramento imediato de suas operações em maio de 2018. A empresa também havia participado da campanha presidencial de Donald Trump em 2016. O procurador-geral do Novo México, Raúl Torrez, classificou a decisão como histórica para o estado e para os consumidores americanos. "Por muito tempo, poderosas empresas de tecnologia agiram como se seu tamanho e influência as colocassem acima do alcance da lei", declarou Torrez. Meta acumula bilhões de dólares em penalidades e acordos A condenação representa mais um capítulo de uma série de disputas judiciais envolvendo as práticas de privacidade da Meta. Em dezembro de 2022, a companhia concordou em pagar US$ 725 milhões para encerrar uma ação coletiva que a acusava de compartilhar indevidamente informações de usuários com a Cambridge Analytica. Anteriormente, em 2019, a Comissão Federal de Comércio dos Estados Unidos (FTC) havia aplicado uma multa de US$ 5 bilhões à empresa por comprometer a capacidade dos usuários de controlar sua privacidade no Facebook. Em agosto de 2026, a Meta também chegou a um acordo com praticamente todos os estados e territórios americanos, com exceção do Novo México e da Flórida, para pagar US$ 18 bilhões ao longo de dez anos e implementar medidas mais rigorosas de proteção de crianças e adolescentes no Facebook e Instagram. Desse montante, US$ 459 milhões estão relacionados a reivindicações envolvendo o caso Cambridge Analytica. Apesar da nova condenação, a disputa judicial ainda não está encerrada. O diretor jurídico da Meta, C.J. Mahoney, criticou a penalidade e informou que a empresa pretende recorrer da decisão. A condenação de US$ 25 bilhões, portanto, ainda poderá ser contestada judicialmente, enquanto a Meta enfrenta consequências financeiras e regulatórias relacionadas às suas práticas de tratamento de dados pessoais.

A empresa indiana de tecnologia eMudhra anunciou sua saída do mercado global de certificados SSL/TLS após um incidente de segurança que comprometeu a confiabilidade de oito certificados intermediários. A descoberta de chaves privadas extremamente fracas levou navegadores como Google Chrome e Mozilla Firefox, além da Apple, a bloquear os certificados afetados. A eMudhra é uma das poucas autoridades certificadoras raiz da Índia reconhecidas pelos principais navegadores. Seus certificados são utilizados para estabelecer conexões HTTPS, permitindo que usuários e servidores troquem informações por canais criptografados e autenticados. Segundo Google, Mozilla e outras empresas, as chaves vulneráveis poderiam permitir que invasores emitissem certificados HTTPS fraudulentos para domínios que não controlam. Caso conseguissem interceptar a conexão de um usuário, os criminosos poderiam se passar por sites legítimos e potencialmente acessar ou modificar informações transmitidas. A Cloudflare explicou que os certificados afetados eram amplamente reconhecidos por navegadores, sistemas operacionais e sua própria infraestrutura. A fragilidade das chaves permitiria criar certificados falsificados para diferentes domínios, comprometendo a confiança nas conexões autenticadas por essas autoridades. Chaves privadas utilizavam números extremamente simples O problema ganhou repercussão após o pesquisador de segurança Scott Helme publicar uma análise revelando falhas graves na geração das chaves criptográficas. Em um dos casos, uma chave privada que deveria utilizar um número aleatório de 384 bits tinha simplesmente o valor 4. Outras chaves utilizavam números igualmente previsíveis, como 56 e 115. A eMudhra informou que os certificados foram criados durante uma cerimônia de geração de chaves realizada em abril de 2025. Segundo a empresa, uma falha em uma das etapas do procedimento resultou na criação de chaves inadequadas. O problema permaneceu sem identificação durante aproximadamente 18 meses e passou por duas auditorias independentes. A vulnerabilidade somente foi descoberta quando um pesquisador conseguiu reconstruir as chaves privadas a partir das informações disponíveis. Na quinta-feira, o presidente da eMudhra, V. Srinivasan, afirmou que todos os certificados afetados foram revogados em até 14 horas após a descoberta. A companhia também declarou que não identificou invasões ou vazamentos de dados decorrentes do incidente. O Ministério de Eletrônica e Tecnologia da Informação da Índia iniciou uma investigação, mas defendeu a empresa diante das críticas, afirmando que algumas publicações nas redes sociais estavam exagerando os possíveis impactos. Entretanto, o CERT-In, órgão nacional de resposta a incidentes cibernéticos da Índia, alertou que a exploração das chaves poderia permitir a falsificação de sites, interceptação e alteração de comunicações, roubo de credenciais, exposição de informações sensíveis e fraudes financeiras. O órgão também destacou o risco de softwares maliciosos serem apresentados como assinados digitalmente por uma entidade confiável. Empresa anuncia retirada do mercado de certificados Após a repercussão, a eMudhra anunciou que deixará voluntariamente o mercado global de certificados SSL/TLS. Segundo Srinivasan, essa atividade representava apenas 1% da receita da companhia e vinha apresentando custos crescentes devido às exigências regulatórias e à complexidade operacional. O executivo também atribuiu parte da pressão enfrentada pela empresa à amplificação do incidente nas redes sociais. A eMudhra informou que trabalhará com desenvolvedores de navegadores e clientes para realizar a migração para outras autoridades certificadoras. Os serviços de revogação e verificação de certificados continuarão funcionando até que todos os documentos emitidos expirem ou sejam substituídos. A companhia também se comprometeu a concluir suas obrigações com os programas de autoridades certificadoras dos navegadores, incluindo a publicação de um relatório completo sobre a causa do incidente. O Google confirmou o compromisso de migração dos clientes afetados, mas informou que continua investigando se os demais certificados da eMudhra devem permanecer no Chrome Root Store, repositório de autoridades certificadoras confiáveis do navegador. Impacto pode atingir softwares e dispositivos por anos Para Brian Fox, cofundador da empresa de cibersegurança Sonatype, as consequências ultrapassam os navegadores, pois os repositórios de certificados confiáveis também estão incorporados a diversos produtos e sistemas. Cada aplicação ou dispositivo pode exigir atualizações, recompilações ou novas versões para eliminar a confiança nos certificados afetados. O problema é agravado pelo fato de muitas organizações não possuírem um inventário completo dos componentes que utilizam esses certificados. Fox classificou a situação como um problema de segurança da cadeia de suprimentos de software, e não apenas como um episódio de revogação de certificados. Embora as primeiras correções tenham começado a ser distribuídas poucos dias após a descoberta, identificar todos os sistemas afetados e garantir sua atualização continua sendo um desafio. O risco é especialmente relevante para versões antigas de software, contêineres esquecidos, dispositivos embarcados e ferramentas de fornecedores que mantêm seus próprios conjuntos de certificados confiáveis. Os certificados intermediários originais da eMudhra tinham validade prevista até abril de 2040. Isso significa que sistemas desatualizados que não verificam informações de revogação poderão continuar confiando nas cadeias de certificação afetadas até receberem as correções necessárias.

Webinar debate o que isso significa para o Brasil, onde 83,2% temem ser vítimas de fraude digital e quase metade abandona o site diante de um aviso de segurança Uma imagem que não carrega, um pop-up inesperado ou um endereço ligeiramente diferente: não é preciso um ataque real para que um consumidor desista de uma compra. O 2026 Liferay Broken Trust Report mostra que 75% das pessoas mudariam para um concorrente para concluir a mesma tarefa se um site parecer inseguro ou se comportar de forma estranha. A pesquisa foi realizada pela Liferay, fornecedora de Plataformas de Experiência Digital (DXP), em parceria com a Pollfish para entender o comportamento do consumidor diante de sites de compra. Os resultados foram apresentados ao mercado brasileiro no webinar “Liferay Broken Trust Report 2026: salve sua taxa de conversão”, realizado em 20 de outubro, com Anne Durey, Marketing Specialist da Liferay. Dados em destaque 75% mudariam para um concorrente se um site parecesse inseguro ou se comportasse de forma estranha 47% saem imediatamente ao ver um aviso de segurança do navegador (58% entre baby boomers; 70% entre os nascidos antes de 1942) 69% já interromperam uma compra por medo de golpe (78% entre 18 e 24 anos) 91% acreditam que até grandes marcas podem parecer falsas ou comprometidas 61% dizem que um único momento “estranho” muda a confiança na marca 32% apontam “o endereço parece ligeiramente diferente” como a forma mais rápida de perder a confiança Base: 1.000 adultos nos Estados Unidos, dezembro de 2025. A confiança se decide em segundos Diante de um site conhecido que se comporta de forma estranha, 40% das pessoas questionam imediatamente a segurança, 29% redobram a atenção e 28% saem na hora. Apenas 4% mal percebem. Os gatilhos são específicos: 39% apontam um aviso do navegador, 19% uma URL levemente diferente e 18% pop-ups inesperados. O efeito vai além da página: 61% afirmam que um único momento estranho muda o quanto confiam na empresa, e 71% consideram a confiabilidade do site um fator importante para confiar na companhia como um todo. “Os clientes são cautelosos por um bom motivo. Eles encontram golpes em toda parte, então pequenas incompatibilidades são lidas como um risco. A confiança é decidida em segundos pelo que a página faz e pelos sinais que ela mostra”, afirma Flávio Moitinho, General Manager da Liferay. Avisos de segurança: um ponto final para metade dos usuários Ao se deparar com um aviso de segurança em um site que já usou antes, 47% saem imediatamente, 29% pesquisam online se outras pessoas relatam o mesmo problema, 12% contatam a marca e apenas 4% continuam navegando. A rejeição cresce com a idade: 38% da Geração Z e 37% dos millennials abandonam o site, contra 46% da Geração X, 58% dos baby boomers e 70% dos nascidos antes de 1942. Em portais de saúde, seguros e serviços financeiros, onde o usuário consulta exames, apólices e faturas, o risco é ainda maior. Marca forte não basta; a venda é a primeira a sentir Para 91%, até marcas grandes e conhecidas podem parecer falsas ou comprometidas. Diante de uma loja conhecida com imagens faltando, layout deslocado ou botões instáveis, 29% sairiam imediatamente, 28% presumiriam que o site não é seguro e 22% suspeitariam de uma versão falsa. O impacto chega ao caixa: 69% já interromperam uma compra por receio de golpe, índice que sobe para 78% entre os jovens de 18 a 24 anos. Depois de quase cair em um golpe, 47% sentem irritação, 45% raiva e 42% frustração; e 11% dizem que nada reconstruiria sua confiança. Para quem quer recuperar o cliente, a pesquisa indica o caminho: 47% preferem uma mensagem clara explicando o que aconteceu e o que foi corrigido. Os sinais que mais tranquilizam, em ordem, são selos de segurança, nome de marca conhecida e design consistente. Por que isso pesa ainda mais no Brasil Embora a pesquisa tenha sido conduzida nos Estados Unidos, o comportamento descrito é reconhecido por qualquer equipe digital brasileira, e o cenário local tende a amplificá-lo: ● Medo consolidado: 83,2% dos brasileiros temem ser vítimas de fraude pela internet ou pelo celular, e o estelionato se tornou o principal crime patrimonial do país, com 2,26 milhões de ocorrências em 2025, segundo o Anuário Brasileiro de Segurança Pública 2026. ● Imitação em escala: só no primeiro trimestre de 2026, a Serasa Experian identificou 10.053 anúncios, perfis, páginas e aplicativos falsos em circulação. ● Pix: como a transação é irreversível, o custo percebido de errar é maior, e o usuário verifica mais antes de concluir. ● LGPD: o tratamento de dados virou assunto de conversa pública, e não apenas jurídico. “Para times brasileiros, estabilidade de página e continuidade de domínio não são higiene técnica, são parte da proposta de valor. Um portal de autoatendimento que apresenta um aviso de certificado em uma tela de pagamento perde o usuário antes que qualquer time de suporte saiba que houve um problema.” completa Moitinho. Cinco ações para reduzir o abandono ● Estabilizar o visual do site e buscar zero avisos em páginas críticas, com certificados válidos e HSTS. ● Provar autenticidade a cada visita, com continuidade de domínio no login e no pagamento e menos redirecionamentos. ● Reduzir a percepção de risco no checkout, sem pop-ups surpresa e com sinais breves de segurança ao lado dos botões de ação. ● Comunicar com clareza quando algo der errado, explicando o que aconteceu e que o comportamento normal foi restaurado. ● Adaptar a experiência por geração: eliminar telas de aviso para públicos mais velhos e padrões “parecidos com golpe” (pop-ups, redirecionamentos entre domínios, etapas extras) para os mais jovens. O relatório completo está disponível em liferay.com/pt/blog/broken-trust-report e a gravação do webinar disponível em https://www.liferay.com/pt/web/lr/webinar-liferay-broken-trust-report-2026-pt. Sobre a LiferayA Liferay é uma empresa global de software especializada em plataformas de Experiência Digital (DXP), capaz de auxiliar organizações a criar experiências completas e personalizadas através de sua plataforma líder de mercado, o Liferay DXP. Fundada em 2004, na Califórnia, com raízes em código aberto, a companhia evoluiu para uma estrutura multinacional com presença em 24 países e uma base de mais de 1.200 clientes globais, incluindo gigantes globais. A Liferay prioriza o sucesso do cliente e a inovação tecnológica a longo prazo, filosofia que se reflete em reconhecimentos consecutivos do Gartner: a empresa figura há mais de 14 anos no Quadrante Mágico do Gartner para Plataformas de Experiência Digital (DXP) e, em 2026, foi reconhecida como "Customers' Choice" no relatório Gartner Voice of the Customer for Digital Experience Platforms, com nota geral de 4,6 de 5 estrelas e 91% dos clientes dispostos a recomendar o Liferay DXP. Na América Latina, a Liferay possui uma operação consolidada há mais de 15 anos, tendo em Recife o maior escritório e principal centro de engenharia de software do mundo, oferecendo soluções robustas para portais de clientes, intranets e plataformas de integração complexas.

A equipe de inteligência de ameaças da Amazon identificou uma tentativa de exploração das vulnerabilidades críticas PHP2Shell em 17 de outubro de 2026, quatro dias antes da divulgação pública das falhas. A atividade foi registrada pelo MadPot, serviço de honeypots da empresa, enquanto novas tentativas de ataque continuam sendo observadas após a disponibilização das correções. Segundo CJ Moses, CISO da Amazon Integrated Security, a tentativa partiu do endereço IP 103.216.220[.]92, geolocalizado na Austrália e associado a uma rede comercial de anonimização. O uso dessa infraestrutura para atingir um honeypot sugere uma ação maliciosa, mas ainda não está claro como os responsáveis obtiveram informações sobre as vulnerabilidades antes de sua divulgação. As falhas, identificadas como CVE-2026-109618 e CVE-2026-109619, receberam pontuação 9,2 no CVSS v4.0 e foram descobertas por pesquisadores da Calif, OpenAI e Wiz, empresa pertencente ao Google. Ambas afetam o núcleo do PHP e podem permitir execução remota de código (RCE) sem autenticação. As vulnerabilidades atingem versões das séries PHP 7.x e 8.x e representam riscos para endpoints acessíveis em servidores vulneráveis, incluindo formulários, páginas de login e verificações de integridade. Como estão presentes no próprio interpretador PHP, a exposição independe do sistema de gerenciamento de conteúdo, framework ou plugins utilizados pela aplicação. De acordo com a CrowdStrike, ataques explorando essas falhas podem deixar poucos rastros digitais. Os processos do servidor permanecem estáveis, as respostas HTTP retornam código 200 e os logs das aplicações podem não registrar anormalidades, pois a exploração ocorre antes da execução do código da aplicação. Em determinados cenários, o único vestígio no servidor pode ser um erro fatal relacionado ao limite de memória, registrado no log de erros do servidor web. Esse evento pode ser interpretado como uma ocorrência comum, dificultando a identificação de sistemas comprometidos. Divulgação antecipada e novas tentativas de exploração A divulgação coordenada das vulnerabilidades estava inicialmente prevista para 22 de outubro de 2026, às 14h UTC. Entretanto, o vazamento antecipado dos identificadores CVE e de um código de prova de conceito (PoC) levou a PHP Foundation a antecipar a publicação das correções para 21 de outubro. Segundo a fundação, as duas falhas estão relacionadas a componentes centrais do PHP responsáveis pelo gerenciamento de memória e tratamento de erros. Essa característica tornou a correção particularmente complexa, devido à necessidade de preservar compatibilidade, desempenho e funcionamento das extensões de terceiros. No dia 21 de outubro, a Amazon detectou novas tentativas de exploração contra seus honeypots, com o primeiro registro por volta das 2h UTC. Outras atividades ocorreram nas seis horas seguintes, utilizando diferentes payloads e serviços de anonimização. As tentativas foram associadas aos endereços IP 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188 e 95.217.98[.]37. A diversidade das técnicas e infraestruturas utilizadas sugere a participação de múltiplos invasores, embora a Amazon ainda não tenha determinado se essas tentativas teriam sido bem-sucedidas em ambientes reais. A empresa de segurança ELLIO também identificou atividades relacionadas ao PHP2Shell. Seus sensores registraram a primeira requisição maliciosa em 21 de outubro, às 8h36 UTC, menos de uma hora depois de a Chainguard publicar imagens de software contendo as correções. A PHP Foundation acusou a Chainguard de violar o embargo de divulgação. A empresa havia recebido os patches antecipadamente para preparar atualizações destinadas aos clientes, mas a publicação precoce das imagens teria permitido que invasores analisassem as correções em formato binário antes da disponibilização oficial. Agências internacionais alertam para riscos A gravidade das vulnerabilidades levou organizações como o National Cyber Security Centre (NCSC), do Reino Unido, e a Cybersecurity and Infrastructure Security Agency (CISA), dos Estados Unidos, a recomendar a aplicação imediata das correções ou a retirada temporária de sistemas vulneráveis da internet. O FBI orientou administradores a monitorar atividades suspeitas em servidores web, especialmente processos PHP que iniciem shells de comando inesperadamente ou realizem downloads de arquivos. A agência também destacou a necessidade de ferramentas de monitoramento de processos para identificar possíveis explorações. A National Security Agency (NSA) alertou que as falhas podem proporcionar acesso direto ao sistema de arquivos e aos bancos de dados dos servidores afetados. A OpenAI, que classificou o PHP2Shell como um dos problemas de segurança mais impactantes dos últimos tempos, disponibilizou uma skill para o Codex capaz de verificar se sites ou binários PHP locais estão vulneráveis. As correções oficiais foram disponibilizadas nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Instalações mais antigas exigem atenção específica, pois diversas versões já não recebem suporte regular do projeto. Mais de 2,6 milhões de servidores PHP estão expostos à internet O alcance potencial das vulnerabilidades é significativo. Segundo a Cloudflare, o PHP está presente em quase 70% dos sites, incluindo aplicações baseadas em plataformas amplamente utilizadas, como WordPress e Magento. A exploração do PHP2Shell pode permitir execução de código malicioso, exposição de informações de clientes e interrupção de serviços, dependendo das permissões disponíveis no servidor comprometido. Um levantamento da VulnCheck identificou 2.608.039 hosts com PHP acessíveis pela internet. Desse total, mais de 700 mil executavam versões entre PHP 3.x e 7.3, enquanto aproximadamente 400 mil utilizavam PHP 7.4, 8.0 ou 8.1. Outros 403 mil servidores operavam versões das séries 8.2 a 8.5. Os números representam a distribuição de versões observadas pela empresa e não confirmam que todos os sistemas identificados estejam vulneráveis ou tenham sido comprometidos. A plataforma Pantheon informou ter bloqueado mais de 60 mil requisições suspeitas relacionadas às vulnerabilidades. A VulnCheck também identificou os endereços 85.11.167[.]243 e 45.198.224[.]169 utilizando o identificador de agente php2shell-scan/109618 para explorar a CVE-2026-109618 contra seus honeypots. Já o IP 109.71.252[.]97 foi associado a tentativas envolvendo ambas as falhas. A Cloudflare confirmou ataques direcionados a seus clientes, incluindo modificações sucessivas nos payloads para tentar contornar os mecanismos de proteção. A CloudLinux também disponibilizou pacotes corrigidos para as versões ea-php52 até ea-php85 e todas as versões alt-php. Empresas como Akamai, AWS, Arctic Wolf, Automattic, Cisco Talos, Corelight, Fastly, Google Cloud, Imperva, Palo Alto Networks Unit 42, Rapid7, Sophos, Vercel, watchTowr e Zscaler, entre outras, publicaram orientações e medidas de mitigação. Ilkka Turunen, Field CTO da Sonatype, destacou que as organizações precisam identificar onde o PHP é utilizado, definir responsáveis pelas atualizações e acelerar a implantação das correções. O especialista também observou que muitos ambientes antigos e distribuições de sistemas operacionais incorporam PHP, o que pode prolongar o processo de atualização. Para CJ Moses, da Amazon, o intervalo entre a divulgação de uma correção e o surgimento de exploits funcionais está diminuindo. A análise de patches e alertas com auxílio de inteligência artificial reduz o esforço necessário para desenvolver ataques, permitindo que mais invasores explorem vulnerabilidades em questão de horas ou minutos. A Amazon recomenda que as investigações de possíveis comprometimentos por PHP2Shell considerem atividades desde pelo menos 17 de outubro, e não apenas a data de divulgação pública das falhas.

Peter Steinberger, criador do OpenClaw e integrante da equipe técnica da OpenAI, revelou ter consumido aproximadamente US$ 10 milhões em tokens de inteligência artificial durante setembro de 2026. A declaração foi feita em 21 de outubro, durante a conferência Cloudflare Connect 2026, em São Francisco, nos Estados Unidos. O valor foi apresentado como uma estimativa dos custos de processamento de suas cargas de trabalho com IA, financiadas por investidores, e não como uma despesa pessoal. A revelação ocorreu durante uma conversa com Dane Knecht, diretor de tecnologia (CTO) da Cloudflare, e provocou surpresa entre os participantes do evento. Knecht comentou que Steinberger já havia reconhecido possuir um orçamento praticamente ilimitado para utilização de tokens, uma realidade distante da maioria dos desenvolvedores e empresas. O criador do OpenClaw respondeu que nem todo esse consumo necessariamente produz resultados úteis. A declaração chamou atenção para os custos envolvidos na operação de agentes autônomos de IA, especialmente em ambientes que executam grandes volumes de solicitações a modelos de linguagem. Infraestrutura de IA ainda enfrenta desafios de custo e escalabilidade Durante a conversa, Steinberger afirmou que a infraestrutura tecnológica ainda não acompanhou completamente a evolução dos agentes inteligentes. Para ele, muitas dessas operações deveriam ser executadas diretamente na nuvem, sem depender dos computadores pessoais dos usuários. Entretanto, a execução de agentes em ambientes de nuvem também apresenta desafios relacionados a custos operacionais, privacidade e conformidade regulatória. Dependendo da quantidade de tarefas e interações realizadas, o consumo de tokens pode representar uma despesa significativa. Outro tema abordado foi o impacto da inteligência artificial no desenvolvimento de software de código aberto. Knecht questionou se a crescente quantidade de contribuições geradas por IA poderia prejudicar o ecossistema open source, especialmente diante das reclamações de mantenedores sobre o recebimento de códigos de baixa qualidade. Steinberger argumentou que o processo de revisão de contribuições, conhecidas como pull requests, precisa evoluir. Segundo ele, desenvolvedores deveriam apresentar não apenas o código final, mas também informações que permitam compreender como chegaram à solução proposta. Essa transparência, na avaliação do criador do OpenClaw, aumentaria a confiança dos responsáveis pela manutenção dos projetos. Agentes de IA poderão antecipar necessidades dos usuários Questionado sobre a possibilidade de cada pessoa utilizar centenas de agentes inteligentes nos próximos anos, Steinberger demonstrou ceticismo em relação a esse número. Ele acredita que os usuários terão sistemas de inteligência artificial capazes de acompanhar suas atividades, oferecer assistência contínua e até antecipar necessidades antes que uma solicitação seja realizada. A proposta envolve agentes com maior autonomia para executar tarefas e tomar decisões, reduzindo a necessidade de comandos constantes. Segurança e permissões continuam sendo desafios A discussão também abordou os riscos de conceder acesso a informações sensíveis e recursos corporativos para agentes de IA. Steinberger reconheceu que a confiança nesses sistemas depende tanto da qualidade dos modelos utilizados quanto dos mecanismos de controle implementados ao seu redor. Segundo ele, melhorias recentes nos modelos permitiram reconsiderar decisões técnicas adotadas nas primeiras versões do OpenClaw. Entretanto, mesmo com avanços na mitigação de ataques de prompt injection, conceder permissões irrestritas aos agentes continua sendo uma prática arriscada. Uma das abordagens propostas pelo desenvolvedor consiste em utilizar um segundo agente de IA para avaliar e autorizar as ações solicitadas pelo primeiro. Nesse modelo, um agente responsável pela execução precisaria negociar determinadas permissões com outro sistema, que avaliaria se a operação é necessária ou se existe uma alternativa mais segura. Steinberger afirmou que essa interação pode fazer os próprios agentes reconsiderarem decisões e identificarem caminhos que respeitem os limites de segurança estabelecidos. A abordagem busca aumentar a confiança na execução autônoma de tarefas, embora a eficácia desses mecanismos continue dependendo da confiabilidade dos modelos e dos controles utilizados.

A Justiça federal dos Estados Unidos rejeitou um pedido do WhatsApp para responsabilizar a NSO Group, empresa israelense responsável pelo spyware Pegasus, por supostamente descumprir uma ordem judicial que proibia o uso da infraestrutura do aplicativo em operações de espionagem. A decisão, publicada em 16 de outubro de 2026 pela juíza Phyllis Hamilton, do Tribunal Federal do Norte da Califórnia, concluiu que o WhatsApp não apresentou provas suficientemente claras e convincentes para demonstrar que a NSO Group havia violado as restrições impostas anteriormente. O processo remonta a ataques realizados em 2019, quando o spyware Pegasus foi utilizado contra aproximadamente 1.400 usuários do WhatsApp. O malware é conhecido por sua capacidade de comprometer dispositivos por meio de técnicas zero-click, que dispensam qualquer interação da vítima. Em 2025, a Justiça determinou que a NSO Group interrompesse o uso não autorizado da infraestrutura do WhatsApp e impôs uma penalidade de US$ 4,4 milhões. A decisão reconheceu que a fabricante havia utilizado indevidamente os sistemas da plataforma para atingir usuários e, em determinados casos, instalar ferramentas de espionagem em seus dispositivos. Apesar da vitória judicial anterior, o WhatsApp voltou ao tribunal em junho de 2026, alegando que a empresa continuava realizando atividades de vigilância por meio de campanhas de spear phishing, técnica que utiliza mensagens direcionadas para induzir vítimas a acessar links maliciosos. WhatsApp identificou 23 contas suspeitas de ligação com a NSO Group A principal evidência apresentada pelo WhatsApp foi uma declaração de Andrew Blaich, engenheiro de segurança integrante da equipe de inteligência de ameaças da Meta. Segundo Blaich, a investigação identificou 23 novas contas no WhatsApp com características técnicas e comportamentais anteriormente associadas a testes realizados pela NSO Group. Entre os indícios estavam padrões de registro, informações sobre dispositivos e conexões com infraestrutura conhecida da fabricante do Pegasus. A Meta também atribuiu à NSO Group o envio de URLs maliciosas por meio do aplicativo em fevereiro e abril de 2026. A análise considerou características dos links, comportamentos de redirecionamento, modelos de mensagens e perfis dos alvos. Entretanto, a juíza considerou que as informações apresentadas não eram suficientes para comprovar o envolvimento da empresa nas atividades denunciadas. O WhatsApp justificou a ausência de detalhes técnicos pelo receio de revelar seus métodos internos de investigação. Segundo a plataforma, divulgar essas informações poderia comprometer sua capacidade de identificar e combater futuras operações de espionagem. Na decisão, Hamilton afirmou que a empresa assumiu um risco calculado ao limitar o nível de detalhamento das provas. A magistrada também considerou que a ordem judicial anterior não proibia claramente todas as formas de utilização de contas já existentes no WhatsApp. Justia Dockets & Filings Decisão provoca críticas de defensores da privacidade Organizações de defesa dos direitos digitais criticaram a decisão, argumentando que exigir a divulgação de métodos confidenciais de detecção pode beneficiar fabricantes de spyware e outros responsáveis por ataques cibernéticos. Natalia Krapiva, consultora jurídica sênior da Access Now, afirmou ao Recorded Future News que a exposição dessas técnicas poderia oferecer informações valiosas à NSO Group, a serviços de inteligência estrangeiros, desenvolvedores de exploits e criminosos interessados em compreender como ferramentas sofisticadas de espionagem são identificadas. Segundo Krapiva, obrigar empresas a revelar esses mecanismos para responsabilizar fabricantes de spyware poderia contribuir para a impunidade do setor. A preocupação tem precedentes. Em setembro de 2024, a Apple desistiu de uma ação judicial contra a NSO Group, justificando que a continuidade do processo poderia expor informações essenciais sobre seus mecanismos de segurança. A rejeição do pedido não anula a condenação anterior nem a ordem judicial contra a NSO Group. A decisão estabelece apenas que as evidências apresentadas pelo WhatsApp não foram suficientes para comprovar uma nova violação das restrições impostas. Até a publicação da reportagem original, WhatsApp e NSO Group não haviam respondido aos pedidos de comentários.

O GitLab lançou, em 21 de outubro de 2026, atualizações de segurança para corrigir uma vulnerabilidade crítica que pode permitir a execução remota de código (RCE) sem autenticação. A falha, identificada como CVE-2026-110264, recebeu pontuação máxima de 10,0 no CVSS e afeta versões do GitLab Community Edition (CE) e Enterprise Edition (EE) lançadas desde 2014. O problema está presente desde a versão 7.0 e representa um risco para instalações autogerenciadas da plataforma. Mesmo administradores que aplicaram as correções disponibilizadas em 12 de outubro precisam atualizar novamente seus ambientes, pois os patches anteriores não corrigem essa vulnerabilidade. De acordo com o comunicado do GitLab, a falha envolve um integer overflow (estouro de inteiro) durante a compilação de uma expressão regular especialmente manipulada. Em determinadas condições, essa condição pode permitir que um invasor execute código arbitrário no servidor sem possuir uma conta válida. A vulnerabilidade está relacionada ao Onigmo, mecanismo de processamento de expressões regulares utilizado pelo Ruby e incorporado aos pacotes distribuídos pelo GitLab. Como esse componente acompanha a plataforma há mais de uma década, a exposição alcança um conjunto amplo de versões. O GitLab ainda não detalhou as condições específicas necessárias para explorar a falha. Também não há confirmação de ataques explorando a CVE-2026-110264 até o momento da divulgação. Versões corrigidas do GitLab A empresa disponibilizou sete versões com a correção de segurança: Versões afetadas Versão corrigida 19.5 anteriores à 19.5.1 19.5.1 19.4 anteriores à 19.4.3 19.4.3 19.3 anteriores à 19.3.6 19.3.6 19.2 anteriores à 19.2.9 19.2.9 19.1 anteriores à 19.1.9 19.1.9 19.0 anteriores à 19.0.10 19.0.10 7.0 até versões anteriores à 18.11.13 18.11.13 ou versão posterior corrigida Quatro dessas atualizações foram disponibilizadas excepcionalmente para versões fora da política habitual de manutenção, que normalmente contempla a versão atual e as duas anteriores. As correções adicionais foram aplicadas às versões 18.11.13, 19.0.10, 19.1.9 e 19.2.9. Instalações muito antigas devem observar os caminhos de atualização exigidos pelo GitLab. GitLab Docs As instalações do GitLab.com já estão protegidas. Clientes do GitLab Dedicated que utilizam as versões internas 19.3.5-internal0 e 19.4.2-internal0, ou posteriores, também receberam as correções. Para auxiliar na identificação de possíveis tentativas de exploração, o GitLab publicou duas regras de detecção: "Onigmo native worker crash" e "Org mode render error burst". Ambas integram o framework de código aberto TLDR e utilizam regras no formato Sigma para analisar registros da aplicação. Como as condições necessárias para alcançar o componente vulnerável não foram detalhadas, os administradores não podem descartar a exposição apenas com base na configuração dos servidores. A empresa também não apresentou uma solução temporária que substitua a atualização. Quarta falha de execução de código identificada em um mês A CVE-2026-110264 é a quarta vulnerabilidade relacionada à execução de código no mecanismo de expressões regulares do GitLab relatada pelo pesquisador conhecido como joaxcar em aproximadamente um mês. Em 12 de outubro, a empresa corrigiu a CVE-2026-97229, também classificada com CVSS 10,0 e capaz de permitir execução de código sem autenticação, nas versões 19.2.8, 19.3.5 e 19.4.2. Anteriormente, em 23 de setembro, foram corrigidas as vulnerabilidades CVE-2026-93577 e CVE-2026-89078, ambas com pontuação 9,9 e exploração condicionada à autenticação. Diferentemente dessas três falhas, a CVE-2026-110264 também afeta versões anteriores à linha 19.2. Atualização também corrige falhas de autenticação O pacote de 21 de outubro reúne correções para 12 vulnerabilidades, incluindo a falha crítica e outros problemas classificados com severidade alta, média ou baixa, conforme o comunicado oficial. Entre elas está a CVE-2026-15723, com pontuação 8,2, que pode permitir a um usuário autenticado assumir outra conta quando os recursos de vinculação automática de identidades SAML e LDAP estão simultaneamente habilitados. Outra vulnerabilidade, CVE-2026-112212, classificada com pontuação 7,5, envolve envenenamento de cache nos endpoints OAuth e OpenID Connect. Em determinadas configurações com cache compartilhado, um invasor pode manipular fluxos de autenticação para redirecioná-los a servidores sob seu controle. A aplicação das atualizações também exige planejamento operacional. As versões 19.4.3 e 19.3.6 incluem migrações de banco de dados que podem provocar indisponibilidade durante a atualização de instalações com um único nó. Segundo o GitLab, ambientes distribuídos em múltiplos nós podem aplicar as correções sem interrupção, desde que utilizem o procedimento de atualização sem indisponibilidade (zero-downtime upgrade).

O PHP lançou atualizações emergenciais para corrigir duas vulnerabilidades críticas que permitem a invasores executar códigos remotamente em servidores web sem necessidade de autenticação. As falhas, conhecidas como PHP2Shell, foram identificadas como CVE-2026-109618 e CVE-2026-109619, receberam pontuação 9,2 no CVSS v4.0 e já são alvo de tentativas de exploração. As correções foram disponibilizadas em 21 de outubro de 2026, nas versões PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Segundo a equipe de segurança do projeto, a atualização é a única medida capaz de corrigir completamente as vulnerabilidades. O problema está no próprio mecanismo de execução do PHP, e não em aplicações específicas. Isso significa que até sites com código seguro, incluindo páginas simples, podem ser vulneráveis caso utilizem uma versão afetada. O aviso oficial aponta que praticamente todas as versões desde o PHP 5.4 são atingidas. As vulnerabilidades afetam diferentes formas de execução da linguagem, incluindo PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. O cenário mais crítico envolve servidores Apache que utilizam mod_php, nos quais uma das técnicas demonstradas permite executar código malicioso por meio de uma única requisição não autenticada, antes mesmo que a aplicação seja iniciada. No PHP-FPM, as condições de exploração variam. Uma das vulnerabilidades foi considerada potencialmente explorável, embora não tenha sido demonstrada uma cadeia completa de ataque nesse ambiente. A outra teve execução de código comprovada tanto no mod_php quanto no PHP-FPM, mas neste último caso depende de uma operação realizada pela aplicação. Além da execução remota de código, os pesquisadores demonstraram que as falhas podem permitir a leitura de informações diretamente da memória dos processos PHP. Entre os dados potencialmente expostos estão senhas, tokens de autenticação, chaves de API e certificados utilizados por outras requisições, mesmo sem que o invasor consiga executar comandos no servidor. As descobertas foram realizadas por pesquisadores da Wiz Research, Calif e da equipe Codex Security, da OpenAI, que trabalharam em conjunto com o time de segurança do PHP e especialistas do Google Gemini para desenvolver as correções. Cloudflare e watchTowr identificam tentativas de exploração A Cloudflare informou ter detectado tráfego associado a tentativas de exploração das vulnerabilidades antes da publicação dos patches. A empresa implementou regras emergenciais de proteção, ativadas por padrão às 03h02 UTC de 21 de outubro, e observou invasores modificando suas cargas maliciosas para tentar contornar os bloqueios. A watchTowr também confirmou, em uma atualização publicada às 14h19 UTC, que estava observando tentativas ativas de exploração das duas vulnerabilidades. Apesar dessa atividade, não havia confirmação pública de comprometimento bem-sucedido de servidores específicos até a última atualização das informações. As falhas também ainda não constavam no catálogo Known Exploited Vulnerabilities (KEV) da CISA no momento das verificações citadas. O cenário levou algumas organizações a suspender serviços preventivamente. A BambooHR retirou sua plataforma do ar nos Estados Unidos, Canadá e Irlanda, alertando que operações relacionadas à folha de pagamento poderiam ser interrompidas. Na Holanda, serviços públicos como MijnOverheid e DigiD, além do site da Câmara Baixa do Parlamento, do centro nacional de cibersegurança e de sistemas educacionais, também ficaram temporariamente indisponíveis. Segundo a emissora NOS, as interrupções foram adotadas como precaução, sem confirmação de ataques bem-sucedidos. Quais versões do PHP precisam ser atualizadas? A equipe do PHP confirmou as seguintes versões corrigidas: Versão do PHP Primeira versão corrigida PHP 8.5 8.5.12 PHP 8.4 8.4.27 PHP 8.3 8.3.36 PHP 8.2 8.2.35 As versões PHP 8.1 e anteriores não recebem mais atualizações regulares do projeto. Entretanto, a equipe disponibilizou correções de código-fonte adaptadas para as séries 7.4, 8.0 e 8.1, permitindo que fornecedores e administradores responsáveis por compilações próprias implementem as mudanças. Distribuições Linux também podem incorporar as correções aos seus pacotes sem modificar o número principal da versão instalada. Por isso, administradores devem consultar os avisos de segurança e históricos de alterações dos fornecedores para verificar se os respectivos CVEs foram corrigidos. A atualização precisa ser aplicada ao ambiente de execução do PHP, seguida da reinicialização dos serviços e processos persistentes afetados. Atualizar plataformas como WordPress ou Laravel, isoladamente, não elimina as vulnerabilidades. Medidas temporárias não substituem atualização O comunicado oficial apresenta configurações que podem reduzir determinados caminhos de exploração, mas ressalta que nenhuma delas oferece proteção completa. Para a CVE-2026-109618, as recomendações incluem utilizar memory_limit=-1, manter limites reduzidos para post_max_size e restringir o tamanho das requisições nos servidores web ou proxies. A equipe também alerta que limites de recursos como RLIMIT_AS e RLIMIT_DATA não devem ser utilizados como substitutos, pois podem acionar o mesmo comportamento vulnerável. Para a CVE-2026-109619, é recomendado desativar o Session Upload Progress por meio da configuração session.upload_progress.enabled=0 e reiniciar os processos PHP. Na versão 8.5, também é indicada a configuração fatal_error_backtraces=0. Essas mudanças podem bloquear caminhos conhecidos de ataque, mas não impedem todas as variantes. O recurso Session Upload Progress, ativado por padrão, participa de uma das técnicas confirmadas de exploração, porém sua desativação não protege contra a CVE-2026-109618. Após instalar as correções, administradores também devem revisar as configurações de memória. A atualização introduz um limite rígido que pode encerrar processos quando atingido, impedindo inclusive a execução de rotinas de finalização. Entre os possíveis indicadores de atividade suspeita estão requisições multipart incomuns, erros de limite de memória, respostas HTTP 500 repetidas, cookies PHPSESSID anormalmente grandes e reinicializações inesperadas de processos PHP. Vazamento antecipou divulgação das falhas A divulgação coordenada das vulnerabilidades estava inicialmente prevista para 22 de outubro, mas informações publicadas antecipadamente em 20 de outubro levaram o projeto PHP a antecipar as atualizações. Segundo a PHP Foundation, a situação foi agravada quando a Calif publicou acidentalmente um vídeo demonstrando um exploit funcional, por volta das 20h UTC de 20 de outubro. Na manhã seguinte, às 07h41 UTC, a Chainguard disponibilizou imagens de software contendo as correções, permitindo que terceiros analisassem as mudanças antes da publicação oficial. A PHP Foundation também revelou que os primeiros sinais do problema relacionado à CVE-2026-109618 haviam sido identificados durante uma auditoria externa realizada em 2024. Na ocasião, a possibilidade de exploração foi considerada teoricamente, mas não havia sido demonstrado um método concreto de execução remota de código. O desenvolvimento de uma correção enfrentou dificuldades porque diferentes alternativas poderiam comprometer a compatibilidade do PHP, introduzir riscos de negação de serviço ou exigir alterações em extensões de terceiros. A discussão permaneceu sem resolução durante meses, situação que a fundação classificou como uma falha estrutural em seus processos de decisão e recursos disponíveis. As investigações conduzidas em 2026 demonstraram a viabilidade prática dos ataques e aceleraram a implementação das correções. Segundo os pesquisadores, ferramentas de inteligência artificial ajudaram a transformar vulnerabilidades antigas em técnicas funcionais de exploração, reduzindo significativamente o tempo necessário para a pesquisa. A PHP Foundation informou que, após o episódio, realizou mudanças em seus processos internos de segurança e ampliou recursos e ferramentas destinados à identificação e correção de vulnerabilidades semelhantes.

O grupo de espionagem cibernética APT28, associado ao governo russo, foi identificado em ataques contra organizações de dois países integrantes da Organização do Tratado do Atlântico Norte (OTAN). Entre os alvos estão um estaleiro naval, uma fabricante de motores para aeronaves militares e uma agência de segurança pública. A investigação, conduzida pela Symantec Threat Hunter Team, da Broadcom, identificou o uso do backdoor HOOKEDGE e de um carregador de malware até então desconhecido, capaz de descriptografar e executar códigos diretamente na memória do computador. A campanha, monitorada sob o nome Swallowtail, foi atribuída ao APT28, também conhecido como Fancy Bear, BlueDelta e Forest Blizzard. Segundo a Symantec, os alvos possuem informações estratégicas potencialmente relevantes para operações de inteligência estrangeira. Invasores mantiveram acesso à rede de estaleiro naval Durante um ataque ocorrido no final de julho de 2026, os operadores retornaram repetidamente a um computador comprometido de um estaleiro naval ao longo de uma semana. A atividade indicou operações manuais, com execução direta de comandos, roubo de credenciais e estabelecimento de mecanismos de acesso persistente à rede interna. Os pesquisadores identificaram duas técnicas distintas para obtenção de credenciais. Na primeira, os invasores transferiram uma chave privada SSH para o computador comprometido e estabeleceram uma conexão com sua própria infraestrutura, criando um túnel SSH persistente em segundo plano. Esse mecanismo fornecia um caminho de acesso à rede interna da organização. Na segunda, utilizaram um script PowerShell para iniciar um serviço local de escuta no endereço de loopback da máquina e forçar uma autenticação, capturando as informações da negociação NTLM. A operação também envolveu o envio de um novo carregador reflexivo, identificado como ld.exe, por meio de comandos curl executados via SSH. A ferramenta foi desenvolvida para descriptografar e executar um payload diretamente na memória, utilizando uma chave criptográfica fornecida durante a execução. A funcionalidade exata do componente seguinte ainda não foi determinada. Backdoor HOOKEDGE recebe novas funcionalidades O HOOKEDGE foi documentado publicamente pela primeira vez em agosto de 2026, pela Recorded Future Insikt Group, após sua identificação em ataques contra organizações governamentais e diplomáticas da Romênia, Espanha e Turquia. Essas atividades ocorreram entre setembro de 2025 e abril de 2026. O malware compartilha características técnicas com o HEADLACE, um implante modular para Windows utilizado pelo APT28 em campanhas contra diplomatas desde abril de 2023. Originalmente, o HOOKEDGE era distribuído por documentos Microsoft Word com macros maliciosas, enviados por spear-phishing. Após a execução, o backdoor utilizava scripts em lote do Windows para receber comandos e transmitir resultados por meio do serviço webhook[.]site. As máquinas comprometidas recuperavam as instruções utilizando uma instância oculta do navegador Microsoft Edge, evitando a necessidade de um downloader convencional. Na campanha contra o estaleiro naval, entretanto, os operadores utilizaram variantes que substituíram o webhook[.]site por comunicação direta com o endereço 185.82.218[.]119, na porta 443, tanto para recebimento de comandos quanto para exfiltração de informações. Segundo a Symantec, a combinação de roubo de credenciais, túneis persistentes e execução de código em memória representa uma ampliação das capacidades anteriormente documentadas nessa operação. Infraestrutura de espionagem contra a Ucrânia também é identificada Em uma investigação separada, a Team Cymru identificou cinco novos servidores de comando e controle associados ao LegionRelay, ferramenta utilizada em ataques contra organizações ucranianas. Os endereços identificados são: 91.149.221[.]118:8000 91.149.221[.]123:8000 166.88.239[.]54:8000 194.87.108[.]12:8000 194.87.108[.]217:8000 O LegionRelay é um trojan de acesso remoto (RAT) baseado em PowerShell, capaz de enumerar arquivos, extrair informações, capturar telas e roubar dados de navegadores, Telegram e WhatsApp, além de configurar acessos por Remote Desktop Protocol (RDP). A ferramenta é atribuída ao grupo GREYVIBE, associado a ataques persistentes contra a Ucrânia e entidades relacionadas ao país desde pelo menos agosto de 2025. Hackers russos ampliam ataques contra smartphones O CERT-UA, centro de resposta a incidentes cibernéticos da Ucrânia, também identificou um crescimento das operações direcionadas a smartphones de militares e funcionários governamentais. Segundo a agência, a utilização crescente de dispositivos móveis para comunicações oficiais e militares tornou esses equipamentos alvos relevantes para espionagem, comprometimento de contas e ataques financeiramente motivados. Entre as ferramentas observadas está o DarkSword, um kit de exploração de vulnerabilidades do iOS distribuído por ataques do tipo watering hole, nos quais sites legítimos comprometidos são utilizados para atingir seus visitantes. Nesse caso, os invasores exploraram veículos de notícias e páginas governamentais ucranianas para distribuir códigos capazes de extrair informações sensíveis de dispositivos afetados. As descobertas são consistentes com uma investigação publicada pelo Google Threat Intelligence Group (GTIG) em março de 2026, que associou o grupo russo UNC6353 ao uso dos kits Coruna e DarkSword em campanhas contra usuários ucranianos desde meados de 2025. No Android, o CERT-UA identificou dois grupos utilizando aplicativos falsos para distribuir malwares diferentes. O UAC-0244 utiliza o CAMELSPY, capaz de coletar informações do dispositivo, localização geográfica, dados do cartão SIM, contatos, registros de chamadas e imagens armazenadas na galeria. Já o UAC-0263 distribui o BTMOB RAT, que permite controlar remotamente dispositivos comprometidos e extrair informações. APT28 explora vulnerabilidades no Office e em serviços de e-mail O CERT-UA também relatou atividades do APT28 envolvendo a exploração de vulnerabilidades em softwares amplamente utilizados. Uma delas é a CVE-2026-21509, falha de bypass de mecanismos de segurança do Microsoft Office, explorada para distribuir o malware COVENANT. Outra é a CVE-2026-8496, vulnerabilidade zero-click no cliente de webmail SOGo, utilizada para obter credenciais e informações de caixas de e-mail. O grupo também continua utilizando técnicas mais antigas, incluindo exploração de vulnerabilidades Cross-Site Scripting (XSS) no Roundcube e documentos Microsoft Excel com macros maliciosas para distribuir o COVENANT. De acordo com o CERT-UA, essas atividades integram um conjunto de 3.137 incidentes cibernéticos registrados na Ucrânia durante o primeiro semestre de 2026, número aproximadamente 8% superior ao observado no segundo semestre de 2025. Os relatórios descrevem diferentes operações de espionagem e comprometimento de sistemas, com foco em organizações militares, governamentais e setores estratégicos, incluindo infraestrutura de defesa e dispositivos móveis.