Common Weakness Enumeration (CWE)

Common Weakness Enumeration (CWE) is a catalog of software and hardware weakness types, run by MITRE and sponsored by CISA. Each entry has a CWE ID, such as CWE-79 for cross-site scripting. A CVE identifies one vulnerability in one product; the CWE ID attached to it names the root-cause mistake, so one flaw can be counted across many products.

A CWE ID describes a mistake, not an attack and not an intent. It travels as metadata: the organization that publishes a CVE record puts it in the record's problemTypes field, and the GitHub Advisory Database copies it into the cwe_ids field of its OSV-format records. As of November 2026, the list is at CWE 5.0, released October 28, 2026, with 956 weaknesses among 1,477 entries. Our position: CWE is the right vocabulary for root-cause trends and static analysis rules, a weak signal for triage, and close to irrelevant for catching malicious packages. On November 6, 2026, the OpenSSF malicious-packages dataset held 239,975 malware reports. Exactly 7 of them referenced a CVE.

CWE is a shared dictionary of the mistakes that make software exploitable. CISA sponsors it, and the Homeland Security Systems Engineering and Development Institute, which MITRE operates, manages it, according to the CWE FAQ. The program started in 2006 and marked its 20th anniversary on September 29, 2026.

Each CWE entry carries an ID, a name, an abstraction level, a description, and relationships to other entries. Most also list detection methods, mitigations, and observed examples drawn from real CVEs. Every weakness entry also carries a vulnerability-mapping usage, which tells you whether you may attach that ID to a real vulnerability at all. We come back to that field below, because much of the CWE data in circulation ignores it.

In practice you rarely visit cwe.mitre.org. You meet CWE IDs inside other records. Here is the CNA container of the CVE record for the Qix maintainer compromise, published by GitHub's CNA on September 15, 2025:

"cna": {
  "title": "debug@4.4.2 contains malware after npm account takeover",
  "problemTypes": [{
    "descriptions": [{
      "cweId": "CWE-506",
      "lang": "en",
      "description": "CWE-506: Embedded Malicious Code",
      "type": "CWE"
    }]
  }]
}

The CWE list changes on a published schedule. CWE 4.20, released April 30, 2026, added view CWE-1448 for weaknesses in AI and machine learning products. CWE 5.0 added 16 weaknesses, deprecated CWE-377, CWE-391, and CWE-613, and shipped Schema 8.0 with breaking changes. The Category element is gone, replaced by Grouping, and the XML namespace moved to http://cwe.mitre.org/cwe-8. MITRE also released CWE 4.21 the same day for consumers still parsing Schema 7.x. If your tooling ingests the CWE XML, it needs work before it can read 5.0.

A CVE identifies one vulnerability in one product; a CWE classifies the kind of mistake behind it. The CWE FAQ puts the relationship in one line: "one CWE entry can often be the root cause of many different CVE Records."

The form-data vulnerability of July 2025 shows both identifiers in one advisory. The npm package picked multipart boundaries with Math.random(), so an attacker who could observe other outputs of the generator could predict a boundary and inject form fields. The GitHub-reviewed advisory record looks like this:

{
  "id": "GHSA-fjxv-7rqg-78g4",
  "aliases": ["CVE-2025-7783"],
  "summary": "form-data uses unsafe random function in form-data for choosing boundary",
  "database_specific": {
    "cwe_ids": ["CWE-330"],
    "severity": "CRITICAL",
    "github_reviewed": true
  }
}

The advisory itself notes that the same bug had recently been found in undici. That is CWE doing its job: two CVEs in two packages, one weakness type.

The record also shows how loose mapping is in practice. CWE-330, Use of Insufficiently Random Values, is a Class that MITRE marks Discouraged for mapping. Its Base-level child, CWE-338, Use of Cryptographically Weak Pseudo-Random Number Generator, is marked Allowed and describes Math.random() exactly. A carefully reviewed advisory still landed on the coarser label, and our own coverage repeated it.

Verdict: use CVE to answer "am I affected?" and CWE to answer "what do we keep getting wrong?" Use neither to answer "what do I fix first?" That question needs reachability analysis and exploitation evidence such as CISA's Known Exploited Vulnerabilities (KEV) catalog. A severity score from CVSS is a starting point, and a CWE ID adds nothing to the ordering.

The CWE hierarchy sorts weaknesses into four abstraction levels, from Pillar down to Variant. MITRE defines a Pillar as the "highest-level weakness that cannot be made any more abstract." A Class is described abstractly, independent of language or technology. A Base has enough detail to infer detection and prevention methods. A Variant is tied to a specific language or technology.

Views slice the same entries for different readers. CWE-699 organizes weaknesses by software development concepts, CWE-1194 covers hardware design, and CWE-1000 is the full research hierarchy. CWE-1003, Weaknesses for Simplified Mapping of Published Vulnerabilities, is a deliberately short list for databases; the FAQ says the NVD "has historically added CWE mappings to CVE Records using the CWE-1003 view." Groupings, called Categories before CWE 5.0, collect entries that share an attribute. Views and groupings are navigation aids. You never map a vulnerability to one.

The branch that holds malicious code is the clearest way to see how the levels nest:

Figure 1 shows the CWE-506 lineage in CWE 5.0. Pillar CWE-710, Improper Adherence to Coding Standards, is the root, and MITRE marks it Discouraged. Its child CWE-684, Incorrect Provision of Specified Functionality, is a Class marked Allowed-with-Review. CWE-684's child CWE-912, Hidden Functionality, is a Class marked Allowed-with-Review. CWE-912 has two children: CWE-506, Embedded Malicious Code, a Class marked Allowed-with-Review, and CWE-1242, Inclusion of Undocumented Features or Chicken Bits, a Base. CWE-506 has four Base children: CWE-507 Trojan Horse, CWE-510 Trapdoor, CWE-511 Logic/Time Bomb, and CWE-512 Spyware.

The placement is revealing. In CWE's model, a credential stealer injected into a package is a descendant of "Improper Adherence to Coding Standards." The taxonomy treats malware as a property of the product's code, because CWE was built to describe defects that the product's own developers introduce.

CNAs map a vulnerability to a CWE through root cause mapping, which MITRE defines as "the identification of the underlying cause(s) of a vulnerability." The mapping guidance is explicit that "CWEs at the Base and Variant level should be used whenever possible." Every entry declares one of four usage levels:

• Allowed: the ID may be used to map real-world vulnerabilities.
• Allowed-with-Review: usable in limited cases after checking whether a child fits better. Many Classes, including CWE-506 and CWE-912, sit here.
• Discouraged: the ID "should not be used to map to real-world vulnerabilities." Pillars such as CWE-284 and CWE-710 sit here, along with overused Classes such as CWE-20 Improper Input Validation.
• Prohibited: the ID "must not be used." Views such as CWE-1003 are Prohibited.

The CNA that publishes the CVE record does the first mapping. For years, the National Vulnerability Database (NVD) added or corrected mappings during enrichment. In April 2026, NIST stopped enriching most CVEs and now prioritizes KEV entries, federal software, and software designated critical. That leaves CNAs and CISA's Vulnrichment container as the practical sources of CWE data for most new records.

We measured what that produces. We scanned every CVE record published between January 1 and November 6, 2026 under a CVE-2025 or CVE-2026 ID, from CVEProject/cvelistV5 at commit 08ff21a:

CWE-284, Improper Access Control, is the third most common CWE on 2026 records, behind CWE-79 and CWE-862. MITRE's own entry for CWE-284 says the ID "is not useful for trend analysis" and lists seven descendants to use instead. Coverage is high and precision is not. The CNA Scorecard rated CWE completeness at 89.8% across more than 23,000 CVEs from February 7 to August 7, 2025, but it measures whether the field is filled, not whether the ID is right.

You can reproduce our count with a sparse clone and a short Python script:

git clone --depth 1 --filter=blob:none --sparse https://github.com/CVEProject/cvelistV5
cd cvelistV5 && git sparse-checkout set cves/2025 cves/2026

import json, os, collections

def cwes(container):
    return {d["cweId"] for pt in container.get("problemTypes") or []
            for d in pt.get("descriptions") or [] if d.get("cweId")}

total, any_cwe, counts = 0, 0, collections.Counter()
for folder in ("cves/2025", "cves/2026"):
    for root, _, files in os.walk(folder):
        for f in files:
            if not f.endswith(".json"):
                continue
            rec = json.load(open(os.path.join(root, f)))
            meta = rec["cveMetadata"]
            if meta["state"] != "PUBLISHED" or not meta["datePublished"].startswith("2026"):
                continue
            total += 1
            found = cwes(rec["containers"]["cna"])
            for adp in rec["containers"].get("adp") or []:
                found |= cwes(adp)
            any_cwe += bool(found)
            counts.update(found)

print(total, any_cwe, counts.most_common(5))

The CWE Top 25 ranks weaknesses by how often they appear in recent CVE records and how severe those records score. The 2025 list, published in December 2025, drew on 39,080 CVE records for vulnerabilities published between June 1, 2024 and June 1, 2025. Each weakness's score is its normalized frequency multiplied by its normalized average CVSS v3.x score, times 100.

The ranking measures reporting volume, not attacker preference. CWE-79 scores more than twice as high as anything else, and much of that volume comes from the WordPress plugin ecosystem. In our count of CVE-2025 records published in 2025, Patchstack and Wordfence, two WordPress-focused CNAs, filed 3,615 of the 6,251 records whose CNA mapped CWE-79. CWE-78, OS command injection, ranks ninth but has 20 CVEs in KEV, the most of any entry on the list. MITRE tracks exploitation separately, in a "2025 CWE Top 10 KEV Weaknesses" list published January 29, 2026.

The list also inherits the data's mapping errors. CWE-20 ranks 18th and CWE-284 ranks 19th, though MITRE discourages mapping vulnerabilities to either. The 2024 edition had the same problem in a different form: MITRE attributed some ranking shifts in the 2024 CWE Top 25 to CVE records that never received NVD mappings. The Top 25 is a good map of what developers keep shipping. It is a poor guide to what will hurt you this quarter.

CWE-506, Embedded Malicious Code, is the CWE entry for malicious packages. The CWE-506 entry describes a product that "contains code that appears to be malicious in nature." It is a Class marked Allowed-with-Review, so MITRE expects mappers to check its four Base children first.

GitHub stamps CWE-506 on its malware advisories, and the OpenSSF malicious-packages repository imports them in OSV format. A typical record, for a malicious npm package named wc, carries the CWE and no CVE:

{
  "id": "MAL-2025-6136",
  "aliases": ["GHSA-575w-mx7m-5697"],
  "summary": "Malicious code in wc (npm)",
  "affected": [{
    "package": { "ecosystem": "npm", "name": "wc" },
    "database_specific": {
      "cwes": [{ "cweId": "CWE-506", "name": "Embedded Malicious Code" }]
    }
  }]
}

We counted the whole dataset at commit 89eed16, current on November 6, 2026. It holds 239,975 non-withdrawn reports of malicious packages, 222,852 of them on npm. 33,126 reports carry a CWE, and every one of those includes CWE-506. Only 7 reports reference a CVE, and all 7 belong to the Nx compromise of August 2025, tracked as CVE-2025-10894. On the CVE side, only 29 of the 89,756 CVE records published in 2026 carry CWE-506.

Figure 2 shows why CWE-506 rarely reaches a vulnerability scanner. On the vulnerability path, a CNA publishes a CVE record with a CWE in problemTypes, CISA's Vulnrichment and the NVD may add data, the GitHub Advisory Database and OSV copy the CWE into cwe_ids, and scanners match package versions against those advisories. On the malware path, researchers and registries report a package, GitHub publishes a malware advisory or OpenSSF publishes a MAL- record with CWE-506, and no CVE is assigned. The counts above sit under each path: 29 of the 89,756 CVE records published in 2026 carry CWE-506, while 7 of 239,975 malware reports carry a CVE.

When a malicious release does get a CVE, the labels vary with whoever filed it. The table compares five records for the same kind of event: the ua-parser-js hijack of October 2021, the keep backdoor on PyPI, the malicious debug release from the Qix compromise, the axios hijack of March 31, 2026, and a downstream CLI that pulled the bad axios release:

The keep record is the oddest. MITRE cites CVE-2022-30877 as the observed example on its own CWE-506 page, yet the CVE record itself has no CWE. The axios rows are the most consequential. The axios releases that pulled in a remote access trojan dropper have no CVE, while a downstream CLI that depended on them does. A scanner keyed only on CVEs flags the CLI and misses the compromised axios versions themselves.

That is why we do not wait for an identifier. Socket's Known malware alert fires on package versions that our AI scanner flags and our threat research team confirms as malware, whether or not a CVE exists.

CWE describes defects in a product's own code, and that framing breaks down for supply chain attacks. From the consumer's side, installing a hijacked release is not a coding mistake. The weakness is a trust decision: which publisher, which version, and when the code was allowed to run. CWE's closest entries are CWE-1357, Reliance on Insufficiently Trustworthy Component, a Class, and its child CWE-1395, Dependency on Vulnerable Third-Party Component. The @usebruno/cli advisory stacked three IDs, and none of them names the actual failure: trusting a release published from a hijacked maintainer account.

The CWE program can move when someone does the work. In 2026 it added a view for AI and machine learning weaknesses, and CWE 5.0 added views mapped to the OpenSSF Secure Coding Guide for Python and the OWASP Go secure coding practices. A supply chain view, with entries that describe consumer-side trust failures rather than producer-side bugs, would let advisories label these incidents consistently. Until then, CWE-506 will remain a label applied after the fact, to a few dozen CVEs a year, for an attack class that already fills 239,975 reports in one open dataset. Catching those packages means reading the code before it runs.