Código malicioso é qualquer código escrito para fazer um sistema executar o que seu dono nunca autorizou: destruir ou roubar dados, entregar o controle a um atacante, ou alterar em silêncio o que um programa legítimo faz. O NIST o descreve como um programa “covertly inserted into another program”, inserido de forma encoberta dentro de outro programa, e essa palavra — encoberta — é a parte que a maioria das definições pula. O código malicioso raramente se anuncia. Ele chega dentro de algo que parece normal.
Das 100 entradas mais recentes da Fluid Attacks Database em 11 de novembro de 2026, 25 eram pacotes maliciosos, publicados sob identificadores como MAL-2026-19118 e não como CVE. Três deles levavam o nome da mesma biblioteca npm sob scopes diferentes; outros três eram variantes quase idênticas de um mesmo nome de pacote. Nenhum era uma falha que alguém cometeu por acidente. Todos eram código escrito de propósito e publicado onde os desenvolvedores iriam instalá-lo.
Esta página cobre o que é código malicioso e como ele difere de uma vulnerabilidade, os tipos que você vai encontrar, como ele chega a um sistema — por dependências, atualizações e pipelines de compilação —, como o detectamos na Fluid Attacks, e como é a prevenção quando o veículo de entrega é software que sua equipe decidiu confiar.
O que é código malicioso?
Código malicioso é software, ou um fragmento de software, construído com a intenção de prejudicar o sistema que o executa. A intenção é o que o define. Um estouro de buffer que permite a um atacante executar comandos é um defeito introduzido por engano; um backdoor que abre a porta para esse mesmo atacante é código que alguém escreveu para estar ali.
Essa distinção importa mais do que o vocabulário ao redor dela. «Código malicioso» e «malware» são usados indistintamente, e o NIST os trata como a mesma coisa. A divisão útil não está entre as duas palavras, mas entre o código que foi inserido e o código que foi mal gerenciado.
Isso tem uma consequência prática: se você só procura código malicioso no endpoint, está olhando o último passo de um caminho que começou em outro lugar.
Código malicioso não é a mesma coisa que uma vulnerabilidade
Uma vulnerabilidade é uma fraqueza em código escrito de boa-fé. O código malicioso é o oposto: o código está fazendo exatamente o que seu autor queria.
Os dois interagem o tempo todo — um atacante explora uma vulnerabilidade para executar código malicioso —, e por isso se confundem. Mas exigem respostas diferentes. Uma vulnerabilidade se corrige com patch. O código malicioso não se corrige com patch; ele se remove, e depois se descobre o que ele fez enquanto esteve ali.
O requisito de segurança 155, “Application free of malicious code” da Fluid Attacks apresenta o problema como uma equipe de desenvolvimento o vive. O código malicioso “can be imported as part of third party libraries, which may be intentionally malicious”, ou seja, pode ser importado como parte de bibliotecas de terceiros intencionalmente maliciosas, ou “come as a backdoor left by one of the developers”, chegar como uma porta dos fundos deixada por um dos desenvolvedores. O requisito mapeia para CWE-507 (Trojan horse), CWE-510 (Trapdoor) e CWE-511 (Logic/Time bomb), para o controle 8.26 da ISO 27001 e para SI-3 do FedRAMP.
Tipos de código malicioso
O que importa na prática não é o que o código faz depois de executado, mas como ele se propaga e como chegou ali. Essas duas propriedades decidem sua resposta.
Tipo | O que faz | Autorreplica? | Entrada típica |
|---|---|---|---|
Vírus | Se anexa a um arquivo ou programa e roda quando esse arquivo roda | Sim, precisa de um hospedeiro | Arquivo ou documento infectado |
Worm | Se copia por uma rede ou ecossistema sem ação do usuário | Sim, sozinho | Serviço de rede, repositório de pacotes |
Cavalo de Troia | Se apresenta como software legítimo para ser instalado | Não | Download, loja de aplicativos, atualização comprometida |
Criptografa arquivos ou sistemas e exige pagamento, como no Colonial Pipeline | Varia | Phishing, serviço exposto, dropper | |
Spyware | Monitora a atividade, registra teclas digitadas, captura tela, câmera ou microfone | Não | Instalador empacotado, troia, extensão maliciosa |
Rootkit | Esconde a presença do atacante subvertendo o sistema operacional ou o firmware | Não | Instalação após o comprometimento |
Backdoor | Dá acesso encoberto que contorna a autenticação | Não | Inserido no código-fonte, na compilação ou em uma atualização |
Bomba lógica | Fica inativa até que uma condição ou data a dispare | Não | Inserida por alguém com acesso de commit |
Adware | Exibe publicidade indesejada | Não | Instalador empacotado |
Duas correções que valem a pena, porque as duas são comuns e as duas estão erradas.
Um cavalo de Troia não é um vírus. Um vírus se replica anexando-se a outros arquivos; um cavalo de Troia não se replica de jeito nenhum. Ele é instalado porque alguém escolheu instalá-lo, acreditando que era outra coisa. Esse é todo o mecanismo dele, e é por isso que os cavalos de Troia sobrevivem onde os vírus não.
Nem todo adware é código malicioso. O software financiado por publicidade que informa o que faz e pode ser desinstalado é um modelo de negócio, não um ataque. Ele vira código malicioso quando se esconde, resiste à remoção ou carrega uma segunda carga útil. A linha é a transparência, não o incômodo.
Backdoors e bombas lógicas merecem mais atenção do que listas como esta lhes dão: são os tipos de código malicioso que chegam até você dentro de software que você pagou ou de código que sua própria equipe integrou. Eles não se propagam. Não precisam.
O código malicioso na Fluid Attacks
Tratamos o código malicioso primeiro como um problema de cadeia de suprimentos de software e depois como um problema de endpoint, porque é aí que está a exposição dos nossos clientes. Isto é o que procuramos, o que podemos provar e onde nossos números param.
O que procuramos no código de terceiros
Nosso catálogo de fraquezas dá ao código malicioso em dependências uma classe própria: 448, “Use of software with malware”, uma dependência do projeto que “contains code or components suspected of being compromised by malware or malicious behavior”, isto é, que contém código ou componentes suspeitos de estarem comprometidos por malware ou comportamento malicioso. Seu impacto listado é acesso não autorizado e controle total da infraestrutura da aplicação, perda de disponibilidade e propagação para outras aplicações, servidores ou redes: a dependência vira o vetor, não o alvo.
A Fluid Attacks reporta as dependências comprometidas por código malicioso como a fraqueza 448.
Duas coisas dessa ficha merecem leitura atenta. Sua maturidade de exploração é A, de Attacked: isto não é teórico. E seu tempo esperado de remediação é de 60 minutos: a correção costuma ser rápida depois que você sabe; o difícil é saber.
Entre os requisitos aos quais ela se conecta estão o 155, acima, e o 262, “Verify third-party components”, que também governa a confusão de dependências.
Como isso funciona na prática
O que instrumentamos | O que procura | Onde fica a evidência |
|---|---|---|
Dependências que carregam código malicioso ou vulnerabilidades conhecidas, diretas e transitivas | Seção Packages, com o arquivo e a linha que a importa | |
Advisories de malware | Pacotes publicados com comportamento malicioso e sem CVE | Identificadores MAL próprios no banco de dados público |
Análise de alcançabilidade | Se o seu código realmente chama uma função vulnerável | Etiqueta “Reachable” no pacote afetado |
Código malicioso no seu próprio repositório: backdoors, bombas lógicas, lógica inserida | Vulnerabilidade reportada com o código em contexto | |
Exportação de SBOM | O inventário completo de componentes, com transitividade e etapa de compilação ou execução | Download em CycloneDX ou SPDX |
![Seção Packages com as dependências de terceiros e suas vulnerabilidades]](https://framerusercontent.com/images/STtGnNUIbf8WekiQKNwvZ6XvVQ.webp)
A seção Packages lista cada dependência de terceiros nos repositórios de um grupo, com as vulnerabilidades e localizações de cada uma.
Na plataforma, a seção Packages mostra de cada dependência sua “location in your projects and if it contains malware”: sua localização nos seus projetos e se ela contém malware. Ela também registra se um componente é usado na etapa de compilação ou de execução, o que muda até onde um pacote malicioso consegue chegar.
O que a detecção automatizada encontra e o que não encontra
No benchmark da Fluid Attacks de ferramentas de AppSec de terceiros contra uma aplicação web semeada com 1.201 vulnerabilidades em 105 categorias CWE, um pentester reportou 1.076 delas: 89,6 % de recall com 100 % de precisão. O melhor scanner automatizado do mesmo exercício, o nosso, chegou a 22,7 % de recall, encontrando 273 das 1.201, e cobriu 8,8 % da exposição total ao risco.
Onde esses números param
Esse benchmark mede vulnerabilidades, não código malicioso. Seria fácil transportar os 89,6 % para uma afirmação sobre detecção de código malicioso, e estaria errado: encontrar uma falha de injeção em uma aplicação semeada e detectar um script de postinstall que exfiltra variáveis de ambiente são problemas diferentes com tetos diferentes. Nós o publicamos porque é reproduzível, não porque ele se transporta.
Mais dois limites que preferimos dizer a que você descubra.
A alcançabilidade e a detecção de malware respondem perguntas diferentes. Nossa documentação as lista separadamente por um motivo. A alcançabilidade diz se o seu código chama a função vulnerável de uma dependência. Ela não diz nada sobre se essa dependência contém código malicioso, porque um pacote hostil não espera ser chamado: um script de instalação roda na hora da instalação.
Um lock file protege a próxima compilação, não a que você já fez. Ele fixa a versão que você instalou para que uma publicação maliciosa dentro da faixa declarada não entre depois. Se a versão que você fixou já estava comprometida, o lock file a mantém no lugar com toda a fidelidade.
O controle que decide quase todo o resto
Se você implementar uma única coisa desta página, implemente lock files com hashes. Nossa documentação sobre eles expõe o caso de falha sem rodeios: “Attackers have taken control of maintainer accounts and released malicious versions of popular packages”, os atacantes tomaram o controle de contas de mantenedores e publicaram versões maliciosas de pacotes populares. Sem um lock file, “the next build can install a malicious version that is in the declared range”: a próxima compilação pode instalar uma versão maliciosa que esteja dentro da faixa declarada.
Com os hashes registrados, o gerenciador de pacotes “stops the installation when a package is different from the package that you locked”, interrompe a instalação quando um pacote é diferente daquele que você fixou: verificação de integridade em cada compilação. Nossa documentação lista o arquivo e o comando de CI/CD de 15 gerenciadores de pacotes, de npm ci a cargo build --locked, além do que fazer com pip, Maven e sbt, que não produzem nenhum.
Para se aprofundar: nossa visão geral da segurança da cadeia de suprimentos de software cobre o conjunto mais amplo de práticas, e a página sobre análise de composição de software explica como os inventários de componentes são construídos e avaliados.
Como o código malicioso entra em um sistema
O código malicioso precisa de um mecanismo de entrega, e a lista cresceu muito além dos anexos de e-mail. Estas são as vias que importam hoje.
Phishing e engenharia social. Continua sendo a abertura mais comum, mas a engenharia social agora mira quem publica código, não só os usuários finais. O comprometimento do npm de setembro de 2025 começou com um e-mail de phishing para um mantenedor.
Downloads e mídias removíveis. Software pirateado, instaladores falsos, extensões de navegador maliciosas, pen drives. A via clássica, e ainda funciona.
Exploração de uma vulnerabilidade. O atacante não insere código malicioso no seu software; usa uma falha nele para executar o dele.
Atualizações comprometidas. Uma atualização assinada com certificados legítimos, entregue pelo canal do próprio fornecedor, carregando código que o fornecedor não escreveu.
Dependências maliciosas. Um pacote de typosquatting publicado com um nome parecido com um real, um pacote abandonado que outra pessoa registrou de novo, ou um pacote legítimo cuja conta de mantenedor foi tomada. A confusão de dependências também entra aqui: quando um projeto declara suas dependências de forma ambígua, um atacante pode fazer o gerenciador de pacotes resolver para o dele em vez do seu.
CI/CD e ferramentas de desenvolvimento. Executores de compilação, ações reutilizáveis, extensões de IDE e, agora, os arquivos de instruções que os agentes de programação com IA leem. A técnica T1195.001 do MITRE ATT&CK, Compromise Software Dependencies and Development Tools, cobre tudo isso, e observa que os arquivos de habilidades de agentes podem passar pela triagem dos repositórios e pelo escaneamento por assinaturas, porque são linguagem natural e não código executável.
Vale sinalizar uma técnica de evasão porque ela derrota a própria revisão de código: em outubro de 2025, atacantes esconderam código malicioso em extensões do VS Code usando caracteres Unicode invisíveis que aparecem como espaço em branco em uma visualização de diff, mas são executados normalmente.
O código malicioso na cadeia de suprimentos de software
O código malicioso de maior impacto dos últimos cinco anos não chegou como um download suspeito. Chegou como uma atualização legítima ou um pacote confiável. É isso que é um ataque à cadeia de suprimentos de software: o atacante compromete algo que está acima de você, e a sua própria confiança faz a entrega. Quatro casos, todos documentados pela nossa equipe, mostram o padrão.
Caso | Ano | Como o código entrou | O que fez |
|---|---|---|---|
2020 | Backdoor inserido na compilação, enviado como atualização assinada | Canal encoberto para servidores controlados pelo atacante, em milhares de organizações | |
2025 | Tags de versão redirecionadas para um commit malicioso em uma GitHub Action | Despejou segredos de CI/CD da memória do executor nos logs do workflow | |
2025 | Phishing de um mantenedor e publicação de versões maliciosas | Interceptador no navegador que reescrevia transações de criptomoedas | |
2025 | Carga maliciosa em um script de postinstall sequestrado | Roubou credenciais e se republicou sozinho em mais pacotes |
A SolarWinds quebrou a premissa que sustenta quase todas as defesas de endpoint: o componente comprometido estava assinado digitalmente e entregue pelo canal oficial de atualizações do fornecedor. A verificação de assinatura confirmou que o pacote era autêntico. Ele era. O código malicioso estava dentro dele.
O caso da GitHub Action aplica a mesma lógica à compilação. Mais de 23.000 repositórios dependiam dela; nosso advisory de CVE-2025-30066 o classifica sob a fraqueza 448 com CWE-506, Embedded Malicious Code, e registra uma pontuação EPSS de 0,88385, o percentil 99,47 de probabilidade de exploração.
O Shai-Hulud mudou a economia do ataque de novo. Ao roubar credenciais e usá-las para se publicar em outros pacotes, ele tirou o atacante do circuito. Um ataque à cadeia de suprimentos de software que se propaga sozinho transforma o ecossistema na rede de distribuição.
Como detectar e prevenir o código malicioso
A detecção de código malicioso se divide conforme onde o código está. O código do seu próprio repositório precisa de revisão. O código que você importou precisa de inteligência sobre sua origem.
Escaneie as dependências contra inteligência de malware, não só contra fontes de CVE
Essa é a lacuna que pega as equipes de surpresa. Um pacote publicado com fins maliciosos nunca recebe um CVE, porque nada foi divulgado: alguém publicou código hostil. Nosso banco de dados os emite sob identificadores MAL próprios, e uma ferramenta que só compara o seu manifesto com a NVD reporta esses projetos como limpos.Inventarie o que você entrega
A seção Packages rastreia dependências diretas e transitivas por repositório e exporta um SBOM em CycloneDX ou SPDX. Você não consegue avaliar um componente que não sabe que tem, e a maior parte do inventário é transitiva.Fixe versões e verifique a integridade
Lock files com hashes, mais o comando de CI/CD que falha a compilação quando o lock file está desatualizado.Revise seu próprio código em busca de lógica inserida
Backdoors, bombas-relógio e carregadores de rootkit não são encontrados comparando nomes de pacotes. São encontrados quando alguém lê o código, que é para isso que existem o Secure Code Review e o Pentesting as a Service (PTaaS) assistido por código.Coloque um portão no pipeline de CI/CD
No State of Attacks 2026 da Fluid Attacks, que cobre 1.119.396 vulnerabilidades reportadas ao longo de 2025, as organizações que usaram nosso CI Gate remediaram 72,2 % das suas vulnerabilidades reportadas, contra 58 % das que não usaram. O mesmo relatório encontrou que 70 % dos sistemas avaliados tinham pelo menos uma vulnerabilidade de severidade alta ou crítica, contra 53,3 % no ano anterior. Um pipeline de CI/CD que falha a compilação diante de uma violação de política é o lugar para barrar uma dependência não revisada.Trate a detecção como o começo da resposta
A fraqueza 448 recomenda revisar a origem e a integridade das dependências afetadas, substituí-las e depois testar para verificar se o ambiente de produção já não está comprometido. Remover o código malicioso não desfaz o que ele fez com as credenciais que leu.
Conclusões
O código malicioso ganha esse nome pela intenção, não pela técnica, e as técnicas que importam se moveram. A imagem da era do endpoint — um anexo infectado, um pen drive, uma assinatura de antivírus — ainda descreve ataques reais, mas não os que alcançaram milhares de organizações de uma vez. Esses chegaram por uma atualização assinada, uma ação reutilizável de CI/CD e um pacote com dois bilhões de downloads semanais.
Defender-se disso significa saber do que o seu software é feito, verificar se esses componentes são o que dizem ser, e ler o código que a sua própria equipe escreve. Nenhum conjunto de controles torna um sistema imune. A meta alcançável é que o código malicioso na sua cadeia de suprimentos seja algo que você detecta em horas, não algo que você fica sabendo por outra pessoa.
Perguntas frequentes
Código malicioso é a mesma coisa que malware?
Sim, os termos são usados indistintamente. A SP 800-83 do NIST define malware como “also known as malicious code”: qualquer programa inserido de forma encoberta dentro de outro com a intenção de destruir dados, executar programas destrutivos ou intrusivos, ou comprometer a confidencialidade, integridade ou disponibilidade dos dados, das aplicações ou do sistema operacional da vítima. A distinção mais útil é entre o código malicioso, escrito de propósito, e uma vulnerabilidade, um defeito introduzido por engano.
Um software assinado digitalmente pode conter código malicioso?
Sim, e os ataques à cadeia de suprimentos mais danosos funcionaram exatamente assim. No comprometimento da SolarWinds Orion em 2020, os atacantes inseriram um backdoor durante a compilação, de modo que a atualização resultante foi assinada com os certificados legítimos do fornecedor e distribuída pelo seu canal oficial. A verificação de assinatura provou que o pacote era autêntico. Ele era. O código malicioso estava dentro dele.
Como o código malicioso entra nos pacotes de código aberto?
Quase sempre pelo mantenedor, não pelo código. Os atacantes fazem phishing ou tomam a conta de um mantenedor e publicam uma versão maliciosa de um pacote em que as pessoas já confiam, registram nomes parecidos com os populares para que um erro de digitação instale o deles, ou registram de novo pacotes abandonados. O MITRE ATT&CK documenta os três sob a técnica T1195.001, junto com o comprometimento de componentes de CI/CD como as GitHub Actions.
As ferramentas automatizadas detectam código malicioso nas dependências?
Em parte, e a lacuna é específica. Uma ferramenta que compara suas dependências com fontes de CVE perde por completo os pacotes publicados com fins maliciosos, porque esses nunca recebem um CVE. A detecção exige uma fonte de publicações maliciosas confirmadas. Das 100 entradas mais recentes da Fluid Attacks Database em 11 de novembro de 2026, 25 eram pacotes maliciosos com identificadores MAL em vez de identificadores CVE.
A Fluid Attacks detecta código malicioso nas dependências?
Sim. Nossos escaneamentos estáticos inventariam as dependências de terceiros do seu software, e a seção Packages mostra de cada uma sua localização nos seus projetos e se ela contém malware: uma fraqueza que catalogamos como a 448, “Use of software with malware”. O código malicioso inserido no seu próprio repositório é outro problema, coberto pelo Secure Code Review manual e não pela comparação de componentes.
Saiba o que o seu software está realmente executando
Nossos scanners e pentesters verificam as duas metades do problema: as dependências que você importou e o código que sua equipe escreveu. Teste gratuito · Fale conosco.
Comece agora com a solução RBVM da Fluid Attacks
