CWE-506: Embedded Malicious Code

ClassIncomplete

The product contains code that appears to be malicious in nature.

View on MITRE
Back to CWE Lookup

Extended Description

Malicious flaws have acquired colorful names, including Trojan horse, trapdoor, timebomb, and logic-bomb. A developer might insert malicious code with the intent to subvert the security of a product or its host system at some time in the future. It generally refers to a program that performs a useful service but exploits rights of the program's user in a way the user does not intend.

Technical Details

Structure
Simple

Applicable To

Languages
Not Language-Specific
Platforms

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Scan release artifacts for malicious behavioral indicators

Scan source archives, packages, extensions, binaries, container layers, and installer payloads with maintained YARA rules and platform-native malware analysis. Combine signatures with behavioral review of install scripts, network destinations, credential access, obfuscation, and unexpected native modules. Compare each release against its reviewed source and provenance; signatures alone cannot rule out novel malicious logic.

Writing YARA rulesYARA Project

Address Embedded Malicious Code during Implementation

MITRE associates mitigation with Implementation, and Operation; documented detection approaches include Manual Static Analysis - Binary or Bytecode, Dynamic Analysis with Manual Results Interpretation, Manual Static Analysis - Source Code, and Automated Static Analysis; recorded impacts include Execute Unauthorized Code or Commands. Use these source-defined anchors to turn CWE-506 into implementation, review, and verification checks for the affected component.

CWE-506: Embedded Malicious CodeMITRE CWE

Apply lessons from CVE-2025-54313 in eslint-config-prettier

NVD maps CVE-2025-54313 to CWE-506; a compromised package release executed embedded malware through an installation script on Windows. Use the case to sandbox package installation, restrict publishing credentials, verify provenance before consumption, and alert when a dependency unexpectedly adds install-time native execution or credential-access behavior.

CVE-2025-54313 DetailNIST National Vulnerability Database

Apply NIST SSDF controls to prevent unauthorized release changes

Use SSDF practices to protect source, build, signing, and distribution systems; review all changes; preserve release integrity; and respond to discovered vulnerabilities. Require separation of duties for sensitive publishing actions, ephemeral and hardened builds, protected credentials, traceable provenance, and a rehearsed process to revoke and replace a malicious release.

NIST SP 800-218 Secure Software Development FrameworkNational Institute of Standards and Technology

Verify artifact provenance before installation or deployment

At the package-consumption boundary, verify the artifact digest, provenance signature, builder identity, build type, source revision, and external parameters against an allowlisted expectation. Reject missing or mismatched attestations and test compromised-registry, substituted-artifact, untrusted-builder, and altered-provenance cases. Recursively assess dependencies when the ecosystem supports it.

SLSA Build: Verifying artifactsSLSA

Frequently Asked Questions

What is CWE-506: Embedded Malicious Code?+

CWE-506: Embedded Malicious Code is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product contains code that appears to be malicious in nature. Malicious flaws have acquired colorful names, including Trojan horse, trapdoor, timebomb, and logic-bomb. A developer might insert malicious code with the intent to subvert the security of a product or its host system at some time in the future. It generally refers to a program that performs a useful service but exploits rights of the program's user in a way the user does not intend.

What are the security consequences of Embedded Malicious Code?+

If exploited, CWE-506 (Embedded Malicious Code) it can compromise Confidentiality, Integrity and Availability, leading to outcomes such as Execute Unauthorized Code or Commands.

How do you prevent or mitigate Embedded Malicious Code?+

Recommended mitigations for CWE-506 include: Remove the malicious code and start an effort to ensure that no more malicious code exists. This may require a detailed review of all code, as it is possible to hide a serious attack in only one or two lines of code. These lines may be located almost anywhere in an application and may have been intentionally obfuscated by the attacker.

How is Embedded Malicious Code detected?+

CWE-506 can be detected using Manual Static Analysis - Binary or Bytecode, Dynamic Analysis with Manual Results Interpretation, Manual Static Analysis - Source Code and Automated Static Analysis. Combining automated tooling with manual review typically yields the best coverage.

Which programming languages are affected by Embedded Malicious Code?+

CWE-506 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Embedded Malicious Code?+

MITRE documents real CVEs mapped to CWE-506, including CVE-2022-30877. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-506 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

Learn More

Advertisement