Why a decade-old Silverlight bug is in a 2022 exploited-vulnerability list

Scattered through the Known Exploited Vulnerabilities catalog is a layer of fossils: Microsoft Silverlight remote code execution (CVE-2016-0034, CVE-2013-0074), Oracle Java JRE (CVE-2013-0431), Oracle Outside In document parsing (CVE-2012-1710), Red Hat JBoss application server (CVE-2010-1428, CVE-2010-0738), and IBM enterprise software (CVE-2013-3993). These are exploit-kit-era and early-APT-era bugs, a decade or more old, backfilled into the catalog because they’re still being exploited somewhere. The question they raise isn’t “how do I patch a 2013 Java bug,” it’s “why am I still running 2013 Java,” and for most of this class the remediation is removal, not an update.

Why they’re still here

These vulnerabilities persist for the same reason any legacy bug does: the software outlived its usefulness but not its installation. A few specific dynamics keep this layer alive:

• Dead browser plugins that never got uninstalled. Silverlight reached end of support in October 2021; the Java browser plugin was deprecated and removed from browsers years ago. The exploit-kit industry feasted on these plugins in the 2010s. The runtimes often remain installed on machines long after the last site that needed them disappeared, sitting there as pure attack surface with no benefit.
• Application servers that became load-bearing and unkillable. Old JBoss instances run a line-of-business app nobody wants to touch. The app works, the server is ancient, and “upgrade the app server” is a project that never gets scheduled, so a 2010 RCE stays exploitable on an internet-or-internally-reachable host.
• Embedded components inside other products. Oracle Outside In is a document-parsing library bundled into many enterprise products (mail, archiving, DLP). A bug in it isn’t something you patch directly; it rides inside whatever embedded it, which means you may not even know you’re exposed, the same dependency-visibility problem behind Log4Shell.

The common thread: this is legacy attack surface, and unlike a current bug, the highest-value fix is usually to make the software stop existing in your environment.

What to do

The actions for this class are about inventory and reduction more than patching.

• Uninstall dead runtimes and plugins. If you don’t have a documented, current need for Silverlight, the Java browser plugin, Flash, or similar, remove them from your endpoints. They are attack surface with no upside. This single sweep closes a whole stratum of these CVEs.
• Inventory legacy application servers and runtimes, and put them on a retirement path. Find your old JBoss, Tomcat, WebLogic, and similar installs. Where they run something that still matters, plan the upgrade or migration; where they don’t, decommission them. Treat “unsupported server still running” as a tracked risk with an owner and a date, not a permanent fixture.
• Hunt for embedded legacy components. For libraries like Outside In, you need software-composition visibility into the products you run, and you need to lean on vendors to update bundled components. Ask what’s inside the enterprise software that parses untrusted documents.
• Isolate what you genuinely can’t remove yet. Where a legacy runtime or server must stay for a real reason, segment it hard, restrict who and what can reach it, and virtual-patch at the network layer. Containment buys time until retirement.
• Patch where a fix exists and the software stays. If you’re keeping a supported-but-old component, apply the available updates. But recognize that for much of this list, no further patches are coming, so removal or upgrade is the only real remediation.

The reframe is to read the legacy layer of the catalog as a prompt for attack-surface reduction rather than a patch queue. A 2013 Java exploit or a 2010 JBoss bug appearing on an exploited-vulnerabilities list in the 2020s is telling you these things are still out there and still being used against the organizations that never cleaned house. The most effective security work here isn’t deploying a patch; it’s the unglamorous inventory-and-remove project that takes the dead runtime off the machine and the abandoned app server off the network. You can’t be exploited through software you no longer run. We track the legacy entries as a class because the answer is nearly always the same: find it, and if you don’t need it, get rid of it.

Sources

• CISA Known Exploited Vulnerabilities Catalog
• Microsoft: Silverlight end of support
• CISA: Securing legacy and end-of-life systems guidance
• NVD CVE-2016-0034 (Microsoft Silverlight RCE) — 2016