CWE-506 is a product that contains code that appears to be malicious in nature. It is not tied to a language, and it is a supply chain problem as much as a coding one.
MITRE notes that malicious flaws have picked up colorful names: Trojan horse, trapdoor, time bomb and logic bomb. The common thread is intent. A developer, or someone with access to the code, puts it there to subvert the security of the product or its host.
How it happens
Malicious code can be added in several places.
- By an insider who writes it directly.
- By an outside contributor whose change is merged.
- By someone who compromises a maintainer account, a build system or a release channel.
- Inside a dependency that your product pulls in.
MITRE describes the typical shape: a program that performs a useful service while exploiting the rights of the user in a way the user does not intend. The useful part keeps people from looking closely.
The record includes a real case. CVE-2022-30877 is described as a command history tool shipped with a code execution backdoor inserted by a malicious party. Users installed a tool that did its job and also carried a way in.
The code can be small. MITRE warns that a serious attack can hide in only one or two lines, located almost anywhere in an application, and may have been intentionally obfuscated.
// Illustrative pattern: a small, obfuscated addition to a helper
function formatDate(d) {
try { new Function(atob("ZmV0Y2goJ2h0dHA6Ly8uLi4nKQ=="))(); } catch (e) {}
return d.toISOString().slice(0, 10);
}
The function still formats dates. It also decodes and runs a string it was never supposed to have. A reviewer who skims for logic errors might not stop on it.
What an attacker gains
MITRE lists the ability to execute unauthorized code or commands, affecting confidentiality, integrity and availability. In practice, the code runs with the rights of the host process or the user. That can mean reading secrets, changing data, opening remote access or taking systems down.
Since it runs wherever the product runs, one insertion can reach every customer or every environment that installs the build.
How to find it
The MITRE record lists several detection methods, each described as cost effective for partial coverage rather than complete.
- Manual source code review, which is not the same as an inspection pass for style or logic. Reviewers need to look for code that does something the feature does not need.
- Origin analysis, an automated static technique that checks where code came from.
- Binary or bytecode disassembly, followed by manual analysis for anomalies. This matters when you only have the compiled artifact.
- Generated code inspection, since generated output can hide additions.
- Dynamic analysis with manual interpretation, including automated monitored execution: run the code in a controlled setting and watch what it does.
Practical routines that support these:
- Review changes from new contributors with extra care, and require a second reviewer for build scripts and install hooks.
- Compare a release artifact with what builds from the tagged source.
- Watch for unexpected network calls, new processes and file writes when you run a build or a new dependency in a sandbox.
- Know what you ship. A dependency inventory shows what entered your product and when.
You can start the inventory with the free in-browser scan. It reads a manifest with up to 100 dependencies, needs no login, and the file stays on your machine. It checks known issues, so treat it as one input beside the manual methods above, not a replacement for them.
How to fix it
MITRE's mitigation has two parts: remove the malicious code, and start an effort to make sure no more of it exists. It warns that this may take a detailed review of all code, because the attack can be a couple of lines placed almost anywhere and deliberately obscured.
A workable response plan:
- Contain. Stop shipping the affected build and revoke any credentials the code could have touched.
- Remove the code and identify how it entered: which commit, account or dependency.
- Review everything else that came from the same source, including other repositories and releases.
- Rotate secrets that were reachable from affected systems.
- Tell the people who ran the affected build.
Prevention is about narrowing the paths in. Require review for all changes. Protect maintainer accounts with strong authentication. Pin dependency versions and review updates before they land. Verify the integrity of what you install.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
How much code does it take to hide an attack?
MITRE says one or two lines can be enough, and they can sit almost anywhere and be obfuscated.
Does a clean dependency scan prove a package has no malicious code?
No. A scan matches known issues. New or targeted malicious code needs manual review, origin checks and runtime monitoring as well.
