Java Top 10 Security Vulnerabilities Disclosed [2019 - List]

Our friends at OverOps post a yearly blog listing the popularity of Java libraries, based on GitHub mentions. Accordingly, in this post, we’ll take a look at the vulnerabilities that have been found in the top ten Java libraries picked by OverOps, and focus on three of them in more depth. Firstly, following are the top ten OverOps picks, ordered by popularity:

1. Jackson

2. Hadoop

3. org.junit

4. org.junit.runner

5. org.springframework

6. Jetty

7. com.amazonaws.services

8. org.apache.http.client

9. org.apache.shiro

10. org.apache.commons.lang3

According to ourSnyk vulnerability database, 162 vulnerabilities have been disclosed across these top ten libraries in total, during their lifetimes. We’ll look at the Jackson, Spring Framework and Jetty libraries in more detail to see how their vulns specifically are distributed across releases; we’ll also look at the severity and the types of vulnerabilities in each of the libraries. These three examples are particularly interesting as they have the most significant security disclosures and are well known, key libraries used in production by many applications.

If your Java projects are being monitored by Snyk, you will have already been notified of any vulnerabilities in your Snyk scans. If not, you should test, for free, to see if your application is affected by any of the vulnerabilities mentioned in this post by testing your application code repository with Snyk.

Jackson Vulnerabilities

The top libraries list in 2018 changed a little from the previous year, with Jackson making its way to the top of the list this time around. Jackson is a very common data-processing package often used to parse JSON in Java applications.

Over the lifetime of the library, it has seen a total of 21 vulnerabilities, the majority of which are Deserialization of Untrusted Data.

Deserialization is the process through which files such as JSON or XML are received and then converted into a package that can be accepted by the hosting application.  The deserialization of untrusted data (CWE-502) vulnerability is when the application deserializes data that has not arrived from a trusted source, without sufficiently verifying that the data is valid, allowing the attacker to control the state or the flow of the execution.

Java deserialization issues have been known for years. However, interest in the issue greatly increased in 2015 when classes that could be abused to achieve remote code execution were found in a popular library (Apache Commons Collection). These classes were used in zero-days affecting IBM WebSphere, Oracle WebLogic, and many other products.

Deserialization is an easy target—any application can be breached as long as it has a vulnerable class in its path, and it performs deserialization on untrusted data. The attacker simply sends the payload to the deserializer, and the command is executed.

Pretty much every related vulnerability is marked as high severity because the majority of scenarios only involve the deserialization of untrusted data, which are among the most severe vulnerabilities listed on the CVSS scale to date.

Are you affected?

The current version of Jackson, 2.9.9, actually doesn’t contain a single known vulnerability. This is a great sign of a well-maintained, popular library as vulnerabilities that have been raised clearly get the attention they need and are fixed quickly. To see if your Java applications are affected, test them now for free using Snyk and you’ll also get remediation advice about the closest non-vulnerable version that you should upgrade to.

Spring Framework Vulnerabilities

The Spring framework is undoubtedly the most popular web framework used in modern day Java applications, by millions of developers. It isn’t just a library, but an entire ecosystem that contains various components. Considering how wide usage of the ecosystem is, the vulnerability figures don’t look so large after all!In total over the decades that the Spring framework has been around, only 96 vulnerabilities have been found. The distribution of vulnerabilities as they were identified spread across the various framework versions as demonstrated in the following graph:

As you’d imagine, it takes time to find vulnerabilities and as a result, many remained in the library over multiple versions before fixes were implemented and were counted once for every version in which they were discovered; hence the numbers above don’t all add up to 96. This is also why the number of vulnerabilities dip towards the current version, as vulnerabilities most likely do exist, but haven’t been found just yet.

Most of the vulnerabilities are rated largely as high and medium, which is fairly common for a library or framework offering a large set of capabilities for applications including endpoint, transport, and security support.

Let’s now take a look at these vulnerabilities by type. Below we list all vulnerability types that have been seen five or more times in the history of the Spring framework. We can see a fairly wide range of vuln types, again because the Spring framework is so broad. It’s also worth mentioning that the Arbitrary Code Execution vulnerability, which sometimes originates from exploitation of the Spring Expression Language (SPEL), such asthis Arbitrary Code Execution vulnerability, also referred to as ‘Spring Break’.

Are you affected?

As a best practice, you should always upgrade to the most recent versions available for your application. However, this doesn’t always happen regularly for various reasons. Often, libraries or frameworks upgrade whenever they need to (frequently), sometimes to remedy a security vulnerability, and it can be hard to keep up the pace. To see if your Spring applications are affected,test them now for free using Snyk and you’ll also get remediation advice about the closest non-vulnerable version that you should upgrade to.

Jetty Vulnerabilities

The Eclipse Jetty project is sometimes used as a library but likely more often used as a lightweight application server (often by the Spring boot framework, related to the Spring framework just mentioned). Jetty has also been developed over multiple decades and has a large community of users and contributors. Over the years, the Jetty project has amassed 38 vulnerabilities, and over half of them are either Cryptographic Issues (13) or Information Exposure (6) vulnerabilities. Again, by the very nature of what security components intend to provide to their consumers, bugs can often lead to security issues as well. Below is the full list of vulnerabilities that have been seen more than once in the Jetty project.

Are you affected?

The best way to see if you are affected by these vulnerabilities or indeed, by any vulnerabilities found within the transitive dependencies which are used by your dependencies, test them now for free using Snyk and you’ll also get remediation advice about the closest non-vulnerable version that you should upgrade to.

At Snyk, we try hard to make it easy for developers to test their projects by offering integrations into your favorite IDEs, code repositories, such as GitHub, GitLab and BitBucket, CI servers and much more. You can test for free and we hope you make use of the automatic remediation features to move up towards a safer version. Stay secure!