Common Weakness Enumeration

A Community-Developed List of Software & Hardware Weakness Types

2021 CWE Most Important Hardware Weaknesses
CWE Top 25 Most Dangerous Weaknesses
Home > News > News & Events - 2018 Archive  

News & Events - 2018 Archive

Right-click and copy a URL to share an article. Send feedback about this page to

How “Meltdown” and “Spectre” Can Be Defined by CWE and CAPEC

January 31, 2018 | Share this article

There has been a lot of press (rightly so) regarding the “Meltdown”- and “Spectre”-style attacks. The CWE and CAPEC teams have been reviewing the available information and trying to determine if new weaknesses or attack patterns should be added. Below are our current thoughts. We welcome additional discussion.

Common Weakness Enumeration (CWE™)

Both Meltdown and Spectre are technically attacks. They take advantage of a processor executing instructions out of order, in a way that causes some instructions to be executed even though the logic of the original code would not execute these instructions. This condition leads to a case where data in memory is cached before a permission check is performed. The end result is the ability to perform side-channel style attacks against the cache to learn the exact value of data.

The root cause of both of these attacks is the out of order execution. The processor uses this feature to increase the speed at which a program can be executed. This is very similar to compiler optimizations where a compiler makes changes to the source code to improve performance. In both instances, the computer is no longer executing exactly what the developer told it to execute, but rather is executing a variation that the processor/compiler thinks is “better.”

Unfortunately, these optimizations can sometimes lead to an exploitable weakness. There already exists a base-level CWE for the compiler version of this:

CWE-733: Compiler Optimization Removal or Modification of Security-critical Code

A new base-level CWE should be added to cover the case where the processor changes the order of security-critical code.

In addition, a new class-level CWE should also be considered around the topic of “Insecure Optimizations.” This class-level CWE would be a member of the Behavioral Problems category in the Development Concepts view, and a child of Interaction Error in the Researcher view. Both the existing compiler optimization (CWE-733) weakness and the new processor execution order weakness would be children of this new class.

CWE CATEGORY: Behavioral Problems

CWE-435: Improper Interaction Between Multiple Entities

Finally, there should be a CanFollow relationship between the existing class CWE-696: Incorrect Behavior Order and this new class “Insecure Optimizations”. We see this relationship in Meltdown/Spectre with the optimizations resulting in a change in the order of execution.

One last note, many discussions of Meltdown and Spectre focus on the side channel attack that arises from timing discrepancies. In this case, the timing discrepancy is not a weakness as it is legitimate behavior (since caching improves efficiency) and is not introduced by choices made by the application developer. Therefore, this is not a focus from the CWE classification perspective; the ability to see this (legitimate) timing discrepancy arises from the insecure optimization.

Common Attack Pattern Enumeration and Classification (CAPEC™)

Shifting to the attack pattern side of things, both the compiler and processor weaknesses are not currently well represented in CAPEC.

The compiler weakness (CWE-733) is not directly attacked, but rather results in a different weakness (e.g., buffer overflow) being present in the software, and that weakness is the one that is used in an attack. CWE thinks of this as a chain. The processor weakness can be thought of in the same way. Even though an adversary can manipulate when/how a processor decides to execute out of order, it is the resulting exposure of data that contributes to the vulnerability. See CWE-668: Exposure of Resource to Wrong Sphere.

For both the Meltdown and Spectre attacks, CAPEC already has a relevant standard-level attack pattern that can be leveraged:

CAPEC-141: Cache Poisoning

This attack pattern has a detailed-level child that covers the DNS version of cache poisoning. Meltdown and Spectre expose a different type of cache poisoning where the adversary doesn't insert malicious data into the cache, but rather cause the cache to contain data that shouldn’t be allowed. CAPEC-141 needs to be cleaned up a bit, but the overall idea behind it is valid. A new detailed-level pattern should be added to cover the Flush+Reload attack pattern (and potentially others) that are leveraged by the Meltdown and Spectre attacks.

What do you think?

Please let us know your thoughts on the above by sending an email message to the CWE Researcher community discussion list, or directly to

We look forward to hearing from you!

More information is available — Please select a different filter.
Page Last Updated: June 20, 2019