Adobe Flash Player is written in an unmanaged code language, vulnerable to the following commonly cited vulnerabilities:
- Heap-based buffer overflow
- Use-after-free vulnerability
- Integer overflow
- Stack-based buffer overflow
- Double-free vulnerability
- Unspecified "type confusion"
- Crafted format-string argument
Typically, unmanaged code is also subject to a deep or enriched data flow and control flow. The deeper security researchers look into the code paths, the more memory-trespass vulnerabilities will be uncovered. Flash Player has a very deep control flow, making lots of decisions and invoking a lot of situational factors, adding to its complexity.
The state-of-the art in memory trespass vulnerabilities is continually updated by security researchers. In recent years, ROP chains have made exploit development an easier and broader process. Tools and techniques increase exponentially as more dedicated security researchers are recruited by increasingly-larger and more-powerful organizations. Take this Libformatstr blog post from just the other day where the researcher released a new framework to simplify the process of exploit development. It's an example of the explosive, novel research going on in the exploit development camp.
For these reasons, and the cross-pollination of Flash exploits into Exploit Kits found in Traffic-Distribution Systems especially via Domain Shadowing, I update Flash Player through Chrome and deliberately turn it off (i.e., chrome://plugins, disable), turning it on only for known-good destinations such as IT systems under my or my org's control. Java applets have had a similar history as Flash Player, which has caused Chrome to permanently discontinue support for these applets -- I expect that Flash applets will soon follow.