Deep-Live-Cam leva malware à instalação, e ExecCritic mede o peso do teste ruim

Você instala as dependências, recebe um erro e nem chega a abrir o programa. No ataque ao Deep-Live-Cam analisado pela SafeDep, isso já podia bastar para executar código malicioso. Uma alteração no arquivo de dependências distribuía um sequestrador de área de transferência para Windows e macOS. O projeto reverteu a mudança, mas quem passou pela instalação afetada precisa investigar a máquina. O instalador pode ter falhado só na parte que você queria que funcionasse.

Deep-Live-Cam executava código do invasor antes de abrir a aplicação

A SafeDep publicou em 9 de setembro a análise de uma alteração maliciosa enviada ao Deep-Live-Cam no dia anterior. No meio de uma reescrita em lote do requirements.txt, uma dependência chamada requests passou a apontar para um repositório controlado pelo atacante.

O nome era familiar. A origem tinha mudado. A instalação foi desviada para outro repositório; o caso não estabelece comprometimento do pacote Requests legítimo nem do PyPI. Conferir só a coluna dos nomes deixava passar justamente a mudança que importava.

Pela análise dos eventos feita pela SafeDep, a alteração ficou na branch principal por aproximadamente nove horas e 39 minutos, até o envio da reversão em 9 de setembro, no horário UTC. Esse é o tempo em que a mudança esteve no projeto. Quantas máquinas foram infectadas e quanto dinheiro foi perdido continuam sem resposta nas fontes.

A execução começava durante o build da dependência a partir do código-fonte. O backend, baseado em setuptools, executava o setup.py. A SafeDep encontrou código oculto de carregamento antes até da checagem de versão do Python. Quando a mensagem de incompatibilidade aparecia, o código malicioso já podia ter rodado.

E o isolamento de build do pip? Ele cria um ambiente Python temporário para organizar as dependências de construção, separado das dependências da aplicação. Isola os pacotes usados no build. Para conter código hostil executado ali, é preciso uma barreira de segurança do sistema operacional. Ganhar um diretório próprio não transforma um ambiente Python numa máquina virtual.

Nos artefatos recuperados, o carregador escolhe Windows ou macOS. O payload troca endereços de carteiras de criptomoedas na área de transferência e instala persistência para voltar a executar na inicialização. Você copia um endereço para pagar e pode colar outro. É entre copiar e colar que o ataque tenta mudar o destino do dinheiro.

Se você instalou a revisão afetada, há duas coisas para resolver. A reversão consertou a lista de dependências do repositório. Os arquivos e as entradas de inicialização já instalados continuam na máquina. Só clonar o repositório, por outro lado, não equivale a executar esse build. E o payload analisado não sustenta estender a mesma conclusão ao Linux.

Comece pela revisão usada na instalação: o commit malicioso começa com 7895c547, e a reversão, com 55d306d5. Depois, confira os indicadores documentados pela SafeDep. No Windows, estão entre eles o arquivo sys.pyw no diretório WindowsHelper, dentro dos dados locais do usuário, e a entrada de inicialização SysHelper. No macOS, a análise aponta sys.py em Library/Application Support/HowToFind e o LaunchAgent com.user.syshelper.plist, ambos sob a pasta do usuário.

Use esses nomes como pistas e valide o contexto antes de apagar um arquivo correspondente. E não repita a instalação suspeita para conferir se ela realmente dá erro. O erro é justamente uma das coisas que podem acontecer tarde demais.

O mantenedor relatou logins estranhos apesar do uso de autenticação em dois fatores e disse ter trocado senhas e chaves. O método exato de acesso à conta continua desconhecido: o relato não permite determinar se houve token, chave SSH ou sessão comprometida, nem afirmar que o mecanismo de dois fatores foi burlado.

Fontes: SafeDep — análise do ataque ao Deep-Live-Cam, GitHub — registro e diff da reversão, resposta do mantenedor e pip — funcionamento do build e de seu isolamento.

ExecCritic fixa o teste enquanto o agente corrige o código

Ontem vimos testes de agentes que concordavam com implementações erradas. Um preprint apresentado em 8 de setembro acrescenta uma comparação controlada: com o mesmo agente de reparo, trocar a origem dos testes mudou o resultado para pior ou para melhor. O trabalho se chama ExecCritic, de Leitian Tao e coautores.

No benchmark dos autores, o reparador original resolveu 61,2% das tarefas do SWE-bench Verified sem receber testes gerados como feedback. Com testes produzidos pelo Qwen base, a taxa caiu para 57,3%. Com testes do GPT-5.6-sol, subiu para 65,3%. São médias de três execuções de reparo, com conjuntos de testes gerados mantidos fixos. O que entra nessa conta são as tarefas resolvidas na avaliação final. As bolinhas verdes que o agente acendeu pelo caminho precisam passar por esse crivo.

Nesse experimento, testes fracos fizeram o mesmo reparador resolver menos tarefas. Acrescentar testes automaticamente também acrescenta uma fonte de orientação, que pode estar errada. Dá para colocar mais trabalho no fluxo e sair com menos problemas resolvidos. Uma produtividade bem ao contrário.

O ExecCritic separa dois papéis. Um agente escreve o teste sem acesso à trajetória da correção candidata. Outro altera o código para resolver o problema. Ambos partem do Qwen-3.5-35B-A3B, mas recebem treinamentos separados. Quem corrige pode mexer no fonte; os critérios de aceitação ficam fixos durante as revisões. A prova permanece na mesa enquanto o aluno troca a resposta.

O agente de testes entrega um pacote com o patch do teste no formato do repositório, o comando exato para executá-lo e um contrato de comportamento em JSON. Um controlador determinístico confere se o teste executa validamente e falha de maneira limpa na versão com o bug. Uma execução inválida não pode contar como aprovação.

Se o teste falha nessa verificação inicial, o sistema mantém a primeira correção, feita sem feedback, e a envia à avaliação oficial. A tarefa continua na conta. Descartar os casos em que a geração falhou seria um jeito bastante conveniente de melhorar o resultado sem melhorar o reparo.

Num exemplo do paper, um reparo de Django usa o valor lógico de uma lista como condição e acaba pulando o caso em que ela está vazia. Só que lista vazia e ausência de valor são situações diferentes naquele comportamento. A correção muda a guarda para verificar se o valor é diferente de None. O teste fixo rejeita o primeiro patch e aceita a revisão que preserva essa diferença.

É um detalhe pequeno de código, mas o teste precisa chegar exatamente ali: entregar a lista vazia e cobrar o comportamento esperado. Acrescentar verificações sobre listas preenchidas deixaria o problema passando do mesmo jeito.

Com os dois papéis treinados, os autores relatam 72,6% de resolução. O reparador treinado sozinho, sem feedback de testes, chega a 68,3%, uma comparação mais justa para entender a contribuição do conjunto. O resultado completo combina treinamento específico, geração de testes e computação adicional nas revisões. O paper diz explicitamente que o ganho foi medido com custos computacionais diferentes. Reproduzir essa configuração exige mais do que colocar dois agentes de prateleira para conversar.

Mesmo com contextos e permissões separados, os dois agentes ainda podem entender errado o mesmo requisito. Fazer o teste falhar no código com bug é uma condição necessária do fluxo; a expectativa do teste também precisa estar correta. No sistema, passar no teste local encerra a revisão. Quem decide a resolução reportada é um avaliador oficial separado, com a suíte completa, e seu resultado fica fora do feedback daquela correção. As taxas vêm dos autores, em um preprint, sem replicação independente apresentada aqui.

No seu fluxo, eu começaria por uma pergunta que dá para conferir no diff: qual comportamento errado esse teste reprova? Depois, impediria o reparador de enfraquecer o teste para terminar a tarefa. A gente já tem trabalho suficiente corrigindo a implementação sem deixar que ela negocie o gabarito.

Fonte: ExecCritic — método, exemplos e resultados.

PostgreSQL divide memória por operação, e a concorrência multiplica a conta

Você aumenta a memória de manutenção do PostgreSQL, permite mais workers e espera o índice ficar pronto mais rápido. Antes de subir o número de novo, confira quem divide esse orçamento e quem recebe um orçamento próprio. Christophe Pettus publicou em 8 de setembro uma explicação com medições sobre essa diferença. As configurações já existiam; a investigação nova mostra onde a conta costuma escapar.

A configuração maintenance_work_mem define a memória disponível para operações de manutenção e vem com padrão de 64 MB. Na construção paralela de um índice, os participantes compartilham o limite da operação inteira. Com work_mem, em consultas paralelas, o orçamento pode se multiplicar por worker.

Na análise e no experimento de Pettus com PostgreSQL 18.6, o cálculo normal do planejador reserva pelo menos 32 MB por participante, incluindo o processo líder. Com 64 MB, cabem o líder e um worker; com 96 MB, o líder e dois workers. Aumentar só o máximo permitido de workers pode deixar você pedindo mais gente do que a conta admite.

Também entram os outros limites e a disponibilidade de workers na hora da execução. E há uma exceção: definir parallel_workers explicitamente na tabela pode contornar essa conta normal de memória. Os valores acima descrevem o caminho comum do planejador, sujeito a essas condições.

Agora troque uma operação paralela por várias operações independentes. O pg_restore -j usa sessões separadas. No exemplo do autor, oito jobs com permissão para usar 2 GB cada somam 16 GB de memória de manutenção potencialmente solicitada. A alocação efetiva durante o restore pode ser menor. Ainda assim, você entregou oito orçamentos de 2 GB, em vez de dividir um orçamento de 2 GB por oito. A RAM da VPS não ficou sabendo que era para interpretar a conta com otimismo.

O autovacuum também entra nessa soma: cada worker pode usar sua própria cota de memória. A configuração autovacuum_work_mem vem com valor -1, que faz essa cota herdar maintenance_work_mem. Se você aumenta o valor global pensando num índice maior, pode aumentar junto a permissão de memória de cada worker de autovacuum.

Definir uma cota explícita para o autovacuum separa essas decisões. Para uma manutenção conhecida, ajustar o valor na sessão também ajuda a delimitar onde o orçamento maior será usado. Nos dois casos, você ainda precisa contar as operações simultâneas e a memória disponível. Há outras alocações nos processos do PostgreSQL, por isso esse orçamento não é um teto rígido para todo o consumo.

E mais memória deixa o índice mais rápido? Na máquina do autor, uma construção serial de índice B-tree sobre quatro milhões de linhas de texto levou 5,5 segundos com 64 MB e 7,7 segundos com 1 GB. Nesse teste, você daria mais memória para esperar mais. Estruturas como índices HNSW podem se comportar de outro jeito quando deixam de caber na memória. E essa medição de B-tree vale para a carga testada, sem estabelecer uma regra para todas as construções.

Eu mediria a minha operação antes de copiar o menor número. Comece pela carga, pela concorrência e pela RAM que existe de verdade. Se a dúvida é paralelismo, observe os workers ativos em pg_stat_activity, pelo tipo de backend parallel worker. O limite configurado diz quantos você permitiu; a consulta mostra quem de fato entrou no trabalho. Depois, confira se essa participação trouxe vantagem.

Fontes: Christophe Pettus — maintenance_work_mem na prática e PostgreSQL 18 — consumo de recursos.

Destaques rápidos para hoje.

• O Chrome corrigiu uma falha no V8 com exploit em circulação. No anúncio de 8 de setembro, o Google confirma exploração da CVE-2026-87491, uma escrita fora dos limites no motor JavaScript, apesar da severidade Medium. Aplique a atualização disponível e confira a versão em execução: 153.0.8010.36 no Linux; no Windows e macOS, 153.0.8010.36 ou 153.0.8010.37. A distribuição é gradual. O Google não detalha a cadeia de exploração nem seu alcance; a falha isolada não permite afirmar fuga da sandbox ou controle completo da máquina. Fonte: Chrome Releases — atualização estável para desktop.

• A Microsoft marcou duas elevações locais de privilégio como exploradas. Os registros de 8 de setembro cobrem a CVE-2026-81963, no Windows Update Stack, e a CVE-2026-85880, no ALPC, mecanismo de comunicação local. Ambas permitem chegar a SYSTEM a partir de acesso local; no ALPC, o atacante precisa executar código num AppContainer de baixo privilégio. A primeira afeta ramos de Windows 11 e Server 2025; a segunda, ramos específicos de Windows 10 e Server 2012 a 2022. Priorize a atualização correspondente ao seu sistema e o reinício exigido. A Microsoft não quantifica a prevalência dos ataques. Fonte: MSRC — registros de segurança de setembro.

• A permissão para publicar precisa ser conferida na hora de executar. Num estudo de 8 de setembro, Yang Li e coautores repetiram 32 intenções de ação produzidas por um modelo: uma verificação determinística bloqueou as seis inseguras e executou as 12 publicações válidas e autorizadas, sem outra chamada ao modelo. A barreira confere ator, artefato, escopo e aprovação atual antes da mudança; conteúdo coincidente ou uma tentativa concluída não concede permissão. É um experimento pequeno, com host e armazenamento de autoridade confiáveis. A segurança completa do sistema fica além do que esse teste demonstra. Fonte: Beyond Agent Harnesses — autorização na execução.

• CUDA Rust ganhou um caminho por blocos de dados com Rust estável. Depois do cuda-oxide que cobrimos em maio, a NVIDIA apresentou em 8 de setembro o caminho Tile com cutile-rs: você descreve operações sobre blocos, e o compilador mapeia o trabalho para threads da GPU. Os requisitos são Linux e GPU com capacidade de computação 8.0 ou superior, além de CUDA 13.3 e Rust estável 1.89 ou posterior. O cuda-oxide mantém controle explícito por thread e exige uma nightly fixada. A NVIDIA recomenda começar por Tile quando você puder abrir mão desse controle; ambos ainda são ferramentas iniciais, com APIs em mudança e sem prontidão para produção. Fonte: NVIDIA — os dois caminhos do CUDA Rust.

• O wrapture acompanha o request Flask depois do retorno da função. Após a configuração externa de ontem, Graham Dumpleton demonstrou em 9 de setembro a combinação de middleware de request com instrumentação específica do Flask. No protocolo WSGI, o status passa por start_response, e o servidor consome o corpo depois que a função da aplicação retorna. O exemplo associa um KeyError tratado internamente ao HTTP 500 e acompanha a conclusão do corpo da resposta. Para observar sucesso e duração da requisição, essas etapas precisam entrar no trace. A função voltou normalmente; o usuário recebeu um erro do mesmo jeito. Fonte: Graham Dumpleton — tracing de Flask com wrapture.

Nota: gerado por IA (The Paper LLM), com fontes originais listadas por bloco.