By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
18px_cookie
e-remove
Blog

What Is Malicious Code? Types, Examples & How to Protect Yourself

What Is Malicious Code? Types, Examples & How to Protect Yourself

Published on
July 13, 2026
Updated on
July 29, 2026

What is malicious code?

Malicious code is any program or script built to damage a system, steal data, or disrupt operations. It spans two categories: code built to attack, such as backdoors and logic bombs, and flaws in legitimate code that let an attacker run their own commands.

Today malicious code is not just external malware. It hides in code repositories, first-party code, open source dependencies, and container images.AI coding agents add a new way for it to slip into a codebase. That spread across the stack is why engineering and security teams need detection at every layer, not antivirus on the endpoint alone.

Types of malicious code

The attack surface runs from traditional malware through modern supply chain threats. These are the main types, with a one-line description and a real example of each.

  • Viruses and worms. Self-replicating code that spreads through files (viruses) or across networks (worms). Modern versions show up as self-propagating packages in npm and PyPI.
  • Trojans and backdoors. Code disguised as legitimate functionality that opens hidden access for an attacker. SolarWinds and the Codecov bash uploader are examples.
  • Ransomware. Encryption-based attacks that lock data or systems for extortion, now reaching CI/CD pipelines and development infrastructure.
  • Spyware and keyloggers. Code that exfiltrates credentials, API keys, and sensitive data from developer environments.
  • Script-based attacks (XSS, SQLi, RCE). Injection flaws in application code that let an attacker run arbitrary commands. Malicious scripts of this kind remain among the most common entry points.
  • Supply chain and dependency injection. Malicious packages, typosquatting, and dependency confusion that target package managers and the developers who pull from them.

How malicious code enters the software supply chain

Most attention goes to the code a team writes. The faster-growing path runs through everything that code depends on. For the full category, see our guide to software supply chain security.

Compromised packages and dependencies

An application with 50 direct dependencies can carry hundreds of transitive ones, packages developers never chose and rarely review. Attackers exploit that trust in several ways.

Typosquatting plants packages with names a character off from popular libraries. Dependency confusion publishes a public package using the name of a private internal one, so the build resolves the malicious version.

Maintainer takeover inserts a backdoor into a project teams already rely on. Because the payload sits deep in the dependency tree, it reaches every project above it. For a full taxonomy of known attacks and techniques used to inject malicious code into open-source software projects, visit our Risk Explorer.

AI-generated and AI-assisted malicious code

AI coding assistants introduce a fresh vector. They suggest insecure patterns, pull in outdated or vulnerable dependencies, and write logic flaws that pass review. The sharper supply chain risk is package hallucination: large language models invent package names that sound plausible but do not exist. Attackers register those names and fill them with malicious code, a pattern known as slopsquatting.

A newer twist turns the agent from the courier into the target. Malicious packages hide instructions in the files an AI coding agent reads: README text, code comments, documentation, and package metadata. When the agent pulls that content into its context, the planted instructions can steer it into installing another package, adding a dependency, or running a command the developer never requested. The agent becomes the delivery mechanism, and because agentic tools resolve and install dependencies on their own, the malware lands before a human reviews it.

For where this heads next, see AI-generated malware and the software supply chain. AI-written code and the dependencies it suggests need the same scanning as human-written code, with no exceptions.

How to detect malicious code

No single scanner covers malicious code. Detection works across layers, with each layer catching what the others miss.

  • SAST finds vulnerabilities in your first-party code, including the injection flaws behind script-based attacks.
  • SCA flags risky and malicious open source dependencies, direct and transitive.
  • Container scanning catches threats in base images and the components that manifests never declare.
  • Secrets detection surfaces exposed credentials and API keys before they ship.
  • Runtime monitoring watches for behavioral anomalies that static scans cannot see.

The hard part is noise. Raw scanning floods teams with thousands of findings, most of which carry no real risk. Reachability analysis determines whether your application calls the vulnerable or malicious code at all, which cuts the actionable list by up to 95%.

Timing matters as much as coverage. Catching a malicious package before it enters the build is a different problem from finding it after deployment. Endor Labs malicious package detection (AURI) evaluates more than 150 signals to flag compromised packages before they reach the build, layers function-level reachability to cut noise by 95%, offers patches that fix issues without risky version upgrades, and gives full-stack visibility from code to containers.

FAQ

What is the difference between malicious code and malware? Malware is a subset of malicious code. Malicious code is the broader category. It covers both intentional threats (malware, backdoors, logic bombs) and exploitable vulnerabilities in otherwise legitimate code that an attacker can turn against you.

How does malicious code enter a software supply chain? Through compromised packages, typosquatting, dependency confusion, vulnerabilities buried in transitive dependencies, and, increasingly, AI-suggested dependencies. Because so much risk sits in code developers never chose, a compromised upstream component can propagate to every downstream project that pulls it in.

How can malicious code do damage? It exfiltrates data, moves laterally across systems, locks resources for ransom, and rides the supply chain into downstream users. The business impact follows: breach costs that run into the millions, compliance violations under frameworks like the EU Cyber Resilience Act and FedRAMP, incident response that drains engineering velocity, and brand damage from a public compromise.

How can you prevent viruses and malicious code? Combine prevention with detection. Validate and sanitize inputs and use parameterized queries to block injection. Control dependencies with version pinning, SBOMs, and malicious package detection. Automate scanning in CI/CD and break builds on critical findings. Enforce least privilege with RBAC and secrets management. Then monitor in production for anomalies. No single control is enough on its own.

How often should engineering teams scan for malicious code? Scan on every build in CI/CD, run pre-commit checks for secrets, and rescan on every dependency update. A new release or a single dependency bump can introduce risk that a quarterly scan would miss.

Can AI-generated code introduce malicious code vulnerabilities? Yes. AI can introduce insecure patterns, outdated or vulnerable dependencies, and logic flaws, plus hallucinated package names that attackers register and weaponize. Route AI-generated code and its suggested dependencies through the same security pipeline as human-written code.

Malicious code protection requires coverage across code, dependencies, and containers, combining secure coding and dependency control with layered detection and fast remediation. See how Endor Labs detects malicious packages before they reach production, or book a demo.

Description goes here