A 23 de setembro, versões maliciosas dos pacotes MemOS da MemTensor foram publicadas tanto no npm como no PyPI, transformando um componente concebido para dar memória de longo prazo a agentes de IA num vetor de ataque à cadeia de fornecimento de software. A Socket e a StepSecurity identificaram três versões afetadas do plugin oficial para OpenClaw — @memtensor/memos-cloud-openclaw-plugin 0.1.21, 0.1.23 e 0.1.25 — e a versão MemoryOS 2.0.34 no PyPI. O OSV passou também a registar o pacote Python como malicioso.
O incidente é mais importante do que a violação de uma única biblioteca. Os sistemas de memória ficam muito perto de dados sensíveis numa arquitetura de agentes: prompts, contexto recuperado, credenciais de desenvolvimento, configuração de ferramentas e estado persistente. Uma versão maliciosa nesta camada pode herdar um nível de confiança normalmente reservado ao próprio runtime do agente.
O que foi comprometido
Os pacotes afetados incluíam um implante multiplataforma escrito em Go, identificado como sckit. A Socket relata que os binários procuravam segredos nos diretórios pessoais dos programadores e enviavam dados para infraestrutura sob skyleen[.]fr. A análise da StepSecurity descreve como alvos credenciais de controlo de código, cloud, registos de pacotes e ferramentas de desenvolvimento.
O caminho de execução é especialmente relevante. Não se tratava apenas de um script de instalação que pudesse ser bloqueado desativando hooks. Os investigadores observaram que o plugin OpenClaw podia iniciar o payload quando o gateway arrancava e durante operações normais de recuperação de memória. No pacote Python, a importação do módulo memos podia desencadear o código. O OSV indica ainda que o código malicioso incluía mecanismos destinados a copiar-se para outros repositórios ou pacotes acessíveis através de credenciais roubadas.
Isto muda a hipótese defensiva: uma dependência pode passar os controlos de instalação e só se tornar perigosa quando o código normal da aplicação a carrega.
Porque é que a memória de agentes aumenta o raio de impacto
Um plugin de memória não é uma dependência de interface comum. A sua função é observar o estado das conversas, recuperar contexto anterior e, muitas vezes, executar automaticamente antes ou depois de cada interação do agente. Em produção, pode correr no mesmo processo que contém chaves de API, tokens de repositório, credenciais cloud e configuração de ferramentas.
O incidente da MemTensor evidencia um problema de fronteira de confiança. Uma equipa pode avaliar cuidadosamente a segurança do modelo e do framework de agentes, mas tratar a memória como uma funcionalidade auxiliar. Operacionalmente, essa memória pode fazer parte da base computacional de confiança.
O risco é também persistente. Um componente de memória foi concebido para sobreviver entre sessões e participar repetidamente na execução. Se estiver comprometido, tem várias oportunidades para observar prompts e o ambiente do processo. A StepSecurity documentou especificamente a passagem de texto do prompt para o launcher malicioso durante a recuperação de memória.
Para a Aipolix, a conclusão prática é que a memória de agentes deve ser classificada como uma integração privilegiada de runtime, e não como um simples adaptador de armazenamento.
A verdadeira fronteira de segurança está no processo de release
Os investigadores não descrevem um simples caso de typosquatting. As versões maliciosas apareceram sob as identidades legítimas dos pacotes da MemTensor. A Socket refere que as publicações npm estavam associadas a uma conta anteriormente usada para versões legítimas, enquanto as versões suspeitas não correspondiam aos metadados normais do processo de release do projeto.
Esta diferença é importante porque uma allowlist baseada apenas no nome do pacote não teria impedido o incidente. Quando a identidade de um pacote confiável é comprometida, a proveniência do artefacto torna-se mais importante do que o reconhecimento do nome.
As equipas precisam de saber que commit originou um pacote, que workflow estava autorizado a publicá-lo, se existe proveniência verificável e se as credenciais de publicação podem ser reutilizadas fora do caminho esperado. Uma política que só pergunta «este é o pacote aprovado?» é mais fraca do que uma política que pergunta «este é o artefacto aprovado produzido pelo processo de release aprovado?».
O estado atual dos registos também mostra por que motivo verificar apenas o tag latest não basta. O npm apresenta atualmente 0.1.24 como latest, embora as versões maliciosas identificadas sejam outros point releases. O PyPI continua a disponibilizar os metadados da versão 2.0.34. O inventário deve, por isso, usar a versão exata instalada.
O que as equipas afetadas devem verificar agora
As organizações que instalaram ou executaram uma das versões identificadas devem tratar o host como potencialmente exposto, em vez de se limitarem a fazer downgrade. As análises publicadas recomendam investigar as credenciais a que o processo tinha acesso, rever atividade nos repositórios e registos e verificar se credenciais de publicação comprometidas podem ter sido utilizadas a jusante.
As versões identificadas são:
- npm: `@memtensor/memos-cloud-openclaw-plugin` 0.1.21, 0.1.23 e 0.1.25
- PyPI: `MemoryOS` 2.0.34
Os investigadores apontam 0.1.20 e 2.0.33 como os últimos baselines conhecidos antes das versões maliciosas, enquanto o npm atualmente aponta o tag latest para 0.1.24. No entanto, instalar uma versão limpa não revoga segredos que já tenham sido copiados de uma máquina onde uma versão comprometida foi executada.
A resposta adequada é mais ampla: isolar sistemas afetados, rodar credenciais a partir de um ambiente limpo, rever atividade de CI e dos registos e validar novamente artefactos downstream.
O que este incidente muda na engenharia de agentes
A principal lição é arquitetural. Os sistemas de agentes estão a juntar uma cadeia crescente de plugins de memória, servidores MCP, adaptadores de ferramentas, routers de modelos e workflows autónomos. Muitos destes componentes executam com a mesma autoridade ambiente do agente.
A análise de dependências continua a ser necessária, mas a infraestrutura agentic acrescenta outra pergunta: o que pode esta dependência ver sempre que o agente é executado?
O ataque à MemTensor torna essa pergunta concreta. Uma integração de memória persistente pode criar uma ponte entre dados de conversação, segredos de desenvolvimento e autoridade de publicação de software. Uma arquitetura mais segura reduz credenciais disponíveis no ambiente, isola extensões, fixa e verifica artefactos e torna a proveniência parte da política de deployment.