Pacotes falsos de correção ortográfica para Python estavam sendo usados como cavalo de Troia para distribuir um trojan de acesso remoto (RAT) via PyPI. A campanha explorava a confiança dos desenvolvedores no repositório oficial Python Package Index e abusava da aparência de ferramentas legítimas de correção de texto para esconder um código altamente malicioso.
Os pesquisadores localizaram dois pacotes comprometidos: spellcheckerpy e spellcheckpy. À primeira vista, aparentavam ser bibliotecas comuns para verificação ortográfica em projetos Python. Na prática, porém, funcionavam como vetor de infecção para instalar, de forma silenciosa, um RAT em sistemas das vítimas. Antes de serem removidos do PyPI, esses pacotes chegaram a somar mais de mil downloads, o que aumenta a probabilidade de que tenham contaminado ambientes de desenvolvimento e produção.
A engenharia maliciosa usada pelos atacantes foi cuidadosamente elaborada para não levantar suspeitas em uma análise rápida. Em vez de deixar o código perigoso em arquivos típicos, como um `__init__.py` suspeito, os criminosos decidiram escondê-lo em um arquivo que simula ser apenas um recurso de dicionário: `resources/eu.json.gz`, supostamente contendo frequências de palavras em idioma basco. O arquivo comprimido parecia legítimo, mas trazia, embutido, um payload codificado em Base64.
Dentro desse recurso, encontrava-se o núcleo da ameaça: o código responsável por decodificar o payload e, posteriormente, baixar e executar um trojan de acesso remoto completo, escrito em Python. Ou seja, o dicionário em língua basca era apenas uma fachada para transportar, de forma disfarçada, o componente que daria controle total da máquina ao invasor.
Outro ponto que demonstra o nível de sofisticação da campanha foi o uso de versões “dormentes” dos pacotes. Nas primeiras distribuições de spellcheckerpy e spellcheckpy, o código malicioso era apenas extraído, mas não chegava a ser executado. Essa abordagem permitia que os pacotes aparentassem comportamento normal durante testes iniciais, reduzindo a chance de serem detectados por auditorias automatizadas ou por usuários mais atentos.
O gatilho verdadeiro foi acionado apenas na versão spellcheckpy 1.2.0, publicada em janeiro de 2026. A partir dessa atualização específica, o pacote passou a executar automaticamente o código malicioso no momento da importação da biblioteca. Com isso, bastava que o desenvolvedor incluísse um simples `import spellcheckpy` no código para que o RAT começasse a ser instalado, sem qualquer interação adicional.
O mecanismo de ativação também foi pensado para se esconder de olhares curiosos. Em vez de executar a carga maliciosa de forma explícita, o pacote utilizava uma função chamada `test_file()`. Quando essa função era chamada com parâmetros específicos, o módulo realizava a decodificação do payload em Base64 presente no arquivo `eu.json.gz` e iniciava o processo de infecção. Assim, a ameaça ficava incrustada em uma funcionalidade que poderia ser interpretada como parte do funcionamento normal da biblioteca.
Após essa primeira etapa, o malware avançava para a fase de conexão externa. O código baixava um RAT hospedado em um domínio remoto controlado pelos operadores da campanha. Esse trojan de acesso remoto permitia ao atacante:
– coletar informações detalhadas sobre o sistema comprometido;
– receber comandos em tempo real a partir de um servidor de comando e controle (C2);
– executar instruções diversas na máquina da vítima, incluindo download de novos arquivos, roubo de dados, instalação de outras ferramentas maliciosas e movimentação lateral na rede.
Segundo os pesquisadores, a infraestrutura de C2 utilizada já havia sido associada anteriormente a operações ligadas a grupos potencialmente patrocinados por Estados-nação. Isso sugere que a campanha não se tratava apenas de cibercrime oportunista, mas possivelmente de uma ação mais organizada, com objetivos de espionagem, sabotagem ou coleta estratégica de informações em ambientes sensíveis.
Esse episódio não é inédito no ecossistema Python. Em 2025, um outro pacote falso de correção ortográfica já havia sido identificado no PyPI, exibindo comportamento semelhante: se passava por ferramenta benigna, mas, internamente, carregava código malicioso. A repetição do padrão reforça a suspeita de que o mesmo grupo ou, pelo menos, a mesma metodologia esteja por trás de múltiplas ondas de ataques, refinando técnicas a cada nova campanha.
O caso também se insere em um cenário mais amplo de ataques à cadeia de suprimentos de software. Repositórios de pacotes como PyPI, npm e outros se tornaram alvos frequentes, por serem pontos centrais na distribuição de componentes usados em milhares de projetos. Ao comprometer uma única biblioteca popular — ou uma que pareça legítima o suficiente — o atacante ganha um canal direto para diferentes organizações, desde desenvolvedores independentes até grandes empresas.
Uma das tendências mais preocupantes destacadas pelos especialistas é o slopsquatting. Nessa técnica, criminosos monitoram nomes de pacotes mencionados incorretamente ou simplesmente inventados por ferramentas de inteligência artificial. Quando veem que um nome de biblioteca inexistente começa a ser sugerido em respostas de IA, registram esse nome no repositório oficial e publicam um pacote contendo código malicioso. Assim, desenvolvedores que confiam cegamente em respostas de IA podem acabar instalando bibliotecas perigosas, acreditando que são componentes legítimos do ecossistema.
Esse tipo de ameaça mostra como a combinação de IA, automatização no desenvolvimento e confiança exagerada em dependências externas cria um terreno fértil para ataques. Ferramentas de IA podem sugerir pacotes que “parecem” certos, com nomes coerentes, mas que nunca existiram até serem criados justamente pelos atacantes. Quando o desenvolvedor não verifica a procedência do pacote, torna-se um alvo fácil para campanhas de slopsquatting.
Diante desse cenário, é fundamental que desenvolvedores e equipes de segurança adotem medidas práticas para reduzir o risco:
– verificar sempre o nome exato do pacote e buscar por homônimos suspeitos ou variações sutis;
– conferir o histórico de versões e o número de downloads, mas sem depender apenas disso como sinal de confiabilidade;
– analisar, quando possível, o código-fonte do pacote, especialmente arquivos de recursos incomuns ou comprimidos;
– desconfiar de bibliotecas recém-lançadas que prometem resolver problemas comuns de maneira “mágica” ou pouco documentada;
– manter ferramentas de análise estática e varredura de dependências integradas ao pipeline de CI/CD, com políticas claras para bloqueio de pacotes suspeitos.
Outro ponto essencial é a implementação de uma política de governança de dependências. Em muitas empresas, qualquer desenvolvedor pode adicionar um novo pacote ao projeto sem revisão prévia. Esse modelo é extremamente arriscado. Uma boa prática é instituir uma lista de componentes aprovados, exigir revisão por pares para novas dependências e, quando possível, usar espelhos internos de repositórios, onde apenas bibliotecas previamente validadas são disponibilizadas.
Também é importante lembrar que a detecção de campanhas como a do spellcheckpy muitas vezes ocorre tardiamente. Ou seja, mesmo após a remoção de um pacote malicioso do repositório oficial, os sistemas que já o instalaram continuam vulneráveis. Por isso, equipes de segurança devem monitorar constantemente inventários de software, registrar quais versões de cada dependência estão em uso e reagir rapidamente a alertas de incidentes envolvendo pacotes específicos.
Para desenvolvedores individuais, a principal lição é não tratar o PyPI — ou qualquer outro repositório — como uma fonte absolutamente confiável. Ele é um grande repositório aberto, sujeito a abusos. Combinar boas práticas de segurança, auditorias periódicas e uma postura mais crítica ao instalar bibliotecas é hoje uma necessidade, não um luxo.
A crescente sofisticação de ataques à cadeia de suprimentos indica que episódios como o dos pacotes falsos de correção ortográfica tendem a se repetir e evoluir. Ao mesmo tempo em que as ferramentas de IA aceleram o desenvolvimento, também ampliam a superfície de ataque e introduzem novos vetores, como o slopsquatting. Nesse contexto, conscientização, processos robustos e uma cultura de segurança integrada ao ciclo de desenvolvimento são as melhores defesas para evitar que simples bibliotecas de “correção ortográfica” se transformem em portas de entrada para invasores.