But I'm not sure I understand the rest of your comment. The threat model for a Java plugin vulnerability is, if your target has the Java plugin enabled, they can't safely browse the web; any page they visit could end up redirecting them to a page with a malicious applet. That's pretty bad.
Please note that the only way to exploit these vulnerabilities is you've already got your code executing on the machine you intend to break
I can't reconcile this with the article. ...34 that are bugs that can be exploited remotely by an attacker without requiring authentication
By "your code" do you mean "Java-based application"? Honest question.In other words these flaws are the equivalent of "I can upload code, how do I get to shell access to the java account".
> Whether they need to be run on the same machine as the program that has the vulnerability (local) or can be run on one machine to attack a program running on another machine (remote).
So if a user starts running the code for you on their machine, it's local. If I send a malformed JPG to a Java webservice that process images, and it doesn't process the JPG correctly leading to code execution or a DoS then that's remote.
[1] http://en.wikipedia.org/wiki/Exploit_(computer_security)
Silent, cross-browser, cross-platform; browser plugin installed by default with anyone who has Java. And that's a huge number of people, since a ton of corporate and residential users have Java installed on all sorts of devices. Java is responsible for a massive ramp up in infections of computer literate and illiterate users alike between 2010 and now.