The 3 most seen vulnerabilities last year

The 3 most seen vulnerabilities last year

Frederik Bøgeskov Johnsen

We have performed quite a few vulnerability scans over the past year. In this blog post, we will share what vulnerabilities we most often see and present you with possible solutions. Hopefully, this can help you ensure that your organisation is not affected by these vulnerabilities.

Lots of data on vulnerabilities

It is no secret that we perform quite a few vulnerability scans for our customers every year. It’s a few months into the new year and we think it is time for us to reflect on last year’s work. We have found the most seen vulnerabilities in our scans. We want to share them with you as the reporting data from our vulnerability scans can provide you with an insight into, what you should watch out for in your organisation.

We scan publicly available IP addresses

When we scan for vulnerabilities, we scan our customer’s publicly available IP addresses. For instance, Microsoft Exchange servers or the server the company’s website runs on. We simply start by connecting to the server and depending on conditions such as operating system, services, and applications, we have different files of relevant vulnerabilities that we are testing for. Thus, we have found several vulnerabilities of which some are repeated more often than others.

Here, we will mention the 3 of the most common vulnerabilities which you and your organisation ought to check for.

1: SSL/TLS: Report Vulnerable Cipher Suites for HTTPS

The vulnerability most seen in our reports in 2020 is the same one we saw in 2019.
In other words, we still find that 3DES (Triple DES) and RC4 (Arcfour) encryption algorithms are supported, which is a vulnerability.

Encryptions can be decoded if you have the right code. These two encryption algorithms use very weak codes and can therefore be decoded with relatively few resources.

RC4 encryption algorithm discouraged since 2013

When it comes to the RC4 algorithm, Microsoft and others have deprecated the use of it since 2013. This means that as far back as 2013 the encryption algorithm RC4 was proven vulnerable as it is simply no longer so advanced that it can create strong and safe encryption.

3DES algorithm affected by weakness

The second encryption algorithm, 3DES, is affected by a vulnerability that allows an external user to extract a blunt cleartext data for each connection that is established. This weakness is based on the exploit kit for 3DES known as “Sweet32.

Based on this vulnerability in 3DES the NIST (National Institute of Standards and Technology) has recommended not to allow the use of 3DES after 2023.


We recommend that you remove support of the 3DES and RC4 algorithms. It will be optimal to use different forms of powerful 256 encryptions and for this, we recommend the tools IIS Crypto or Mozilla SSL Config Generator.

2: Cleartext Transmission of Sensitive Information via HTTP

The second most seen vulnerability in our reports is “Cleartext Transmission of Sensitive Information via HTTP”. This basically means that login information is sent via a connection that is not encrypted, which again means that the application is vulnerable to a potential interception of user information from this login.

Before an external actor can listen in on the connection, both parties must be logged on to the same network. This makes the vulnerability rather difficult to exploit in practice. However, if the circumstances are right and an employee is on a public network like a restaurant or bar, the vulnerability is dangerous and easy to exploit.


It is recommended that you close access to the service through HTTP. This can be done by using an SSL/TLS certificate to encrypt connectivity. In addition, you can move access to port 443 to secure the connection and maintain its safety.

3: SSH Weak Encryption Algorithms Supported

The last vulnerability we will investigate today is the third most-watched vulnerability in our reports from 2020. The vulnerability comes from misconfigured SSH accesses.

We often see that they allow the use of vulnerable encryption algorithms such as RC4, arcfour128 and arcfour256.

As described under the most-viewed vulnerability, the RC encryption algorithm is based on a 128-bit code that no longer provides complex encryptions. We often see this algorithm supported on SSH connections.


We recommend that you change the configuration of the SSH server so that it does not allow encryptions with RC4, arcfour128 and arcfour256 algorithms.

Vulnerabilities do not correct themselves

These 3 vulnerabilities are in many ways simple to resolve. It is worth noticing, however, that the most viewed vulnerability was already discovered in 2013. It shows, that even simple vulnerabilities do not resolve themselves and that you ought to concentrate on resolving these vulnerabilities to avoid them.

Subscribe to our newsletter

Receive updates containing free templates, tools, and news from CyberPilot.

Join our 2000+ subscribers and sign up for our newsletter. You will receive inspiration, tools and stories about good cyber security practice directly in your inbox. Our newsletter is sent out approximately once a month.


Contact us

You are always welcome to contact us
for an initial and informal chat about your cyber security challenges.