BLOG HOME > PCI > Top 15 ASV Scan Vulnerabilities and How to Fix Them

Top 15 ASV Scan Vulnerabilities and How to Fix Them

Author: Colten Henrie 

Scan Technician Supervisor Security+, ASV

What is an ASV Scan? 

ASV stands for “Approved Scanning Vendor.” The Payment Card Industry Data Security Standard (PCI DSS) requirement 11.2.2 calls for regular vulnerability scanning from an ASV. These are vendors with scanning solutions that have been tested, approved, and added to a list of approved solutions that can help fulfill this PCI compliance requirement. Learn about what qualities to look for in an ASV.

How do vulnerability scanners work?

Vulnerability scanners are technically computer programs that search systems for weaknesses. Hackers can take advantage of these weaknesses to breach a network and steal data or install malware. 

White Paper: HIPAA Vulnerability Scanning 101

Download Here

Vulnerability scans are automatic. They’re nonintrusive, similar to a security professional checking whether or not your front door is unlocked and letting you know if it is (while not entering your house). Vulnerability scans search your network and provide a logged summary of alerts you can review and act on. 

If you are using SecurityMetrics’ ASV vulnerability scans and have an intrusion detection system or intrusion prevention system protecting your network, you may need to add our scanner's IP range to a whitelist or exclusion list for the scan to complete accurately.

Here are the top 15 ASV scan vulnerabilities and how to fix them: 


TLS Version 1.0 Protocol Detection (PCI DSS), SSL Version 2 and 3 Protocol Detection


SSL 64-bit Block Size Cipher Suites Supported (SWEET32), SSL Medium Strength Cipher Suites Supported, SSL RC4 Cipher Suites Supported (Bar Mitzvah), SSL/TLS Services Support RC4 (PCI DSS), SSL Weak or Medium Strength Cipher Suites Supported, SSL Medium Strength Cipher Suites Supported (SWEET32), Weak DH Key Exchange Supported (PCI DSS), SSH Weak Algorithms Supported, SSL Weak Cipher Suites Supported


SSL Certificate with Wrong Hostname, SSL Self-Signed Certificate, SSL Certificate Expiry


Web Application Potentially Vulnerable to Clickjacking


SSLv3 Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE)


Microsoft Windows SMB Login Possible


Web Server Transmits Cleartext Credentials, Web Server Uses Basic Authentication Without HTTPS, SMTP Service Cleartext Login Permitted


Internet Key Exchange (IKE) Aggressive Mode with Pre-Shared Key


SMB Signing not required


OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability


Terminal Services Doesn't Use Network Level Authentication (NLA) Only


FTP Supports Cleartext Authentication


Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness


Terminal Services Encryption Level is Medium or Low


Script Src Integrity Check

1. TLS Version 1.0 Protocol Detection (PCI DSS) and SSL Version 2 and 3 Protocol Detection 

Grouped together because they have a common solution. SSL, or “Secure Sockets Layer,” was an earlier protocol and precursor to TLS or “Transport Layer Security.” Both are designed for use in data transmission over the open public internet. 

Resolution: According to the PCI DSS and security best practice, all versions of SSL (SSLv2 and SSLv3), as well as early versions of TLS (TLS 1.0), should be disabled from use on all open connections into the CDE.

2. Cipher/Algorithm Vulnerabilities 

This extensive list of cipher/algorithm vulnerabilities all come down to very similar fixes or resolutions. 

Resolution: In each one of these vulnerabilities, the ciphers that cause these to flag have to be disabled. Those ciphers/algorithms are located in the “Data Received” section of the scan vulnerability details. Once disabled, rescans should clear these from flagging in the future.

3. SSL Certificate with Wrong Hostname, SSL Self-Signed Certificate, and SSL Certificate Expiry 

These are all SSL Certificate related vulnerabilities. As the third most common vulnerability we see, most merchants will come across this at some point. 

Resolution: The suggested resolutions are similar with slight variances, but they all boil down to one core concept: Open, Public ports that use encryption are required to have a Valid SSL Certificate signed by a Certificate Authority (CA). This means that the common name needs to match the target, the issuer needs to be a CA, and the certificate cannot be expired. 

4. Web Application Potentially Vulnerable to Clickjacking 

This vulnerability often appears on websites as well as simple login pages found on the network side. With clickjacking, a hacker or malicious individual loads a webpage or a button/link from a webpage into an I-Frame. A visitor may then unknowingly click on a malicious link and be sent to a completely different site–typically a duplicate page made to look like the valid webpage. I-Frames need to be restricted by implementing a security header.

Resolution: Regardless of where Clickjacking is vulnerable, the same fix applies. Pages that are vulnerable to Clickjacking are required to implement either X-Frame-Options or Content-Security-Policy security headers that prevent I-Frames from loading affected web pages.

5. SSLv3 Padding Oracle on Downgraded Legacy Encryption Vulnerability (POODLE) 

POODLE only shows up when SSLv3 is enabled. The remote host is affected by a man-in-the-middle (MitM) information disclosure vulnerability. MitM attackers can decrypt a selected byte of a cipher text in as few as 256 tries if they are able to force a victim application to repeatedly send the same data over newly created SSL 3.0 connections.

Resolution: Once SSLv3 is disabled, this vulnerability will no longer show up.

6. Microsoft Windows SMB Login Possible 

This vulnerability has alerted 23,000 times in the last six months and is number six on the list. In this case, the remote host is running a Microsoft Windows operating system or Samba, a CIFS/SMB server for Unix. 

It’s possible that by having this set up, someone could log into the system with the following account information: 

  • NULL session
  • Guest account
  • Supplied credentials 

Resolution: Often this vulnerability requires the scan customer to contact their Vendor or OEM for an applicable vendor supplied patch. 

PCI Approved Vulnerability (ASV) Scans

Learn More

7. Web Server Transmits Cleartext Credentials, Web Server Uses Basic Authentication Without HTTPS, and SMTP Service Cleartext Login Permitted 

These three vulnerabilities are all very similar. But despite these similarities, there are some key differences. SMTP Service Cleartext Login Permitted is on a completely different protocol than the other two, which function over HTTP. 

Resolution: The recommended fix for these vulnerabilities is to disable any insecure service that supports remote logins and migrate everything over to a secure version of that service. So, rather than having login pages over the HTTP protocol, you would move them to HTTPS. The same with SMTP to SMTPS. 

8. Internet Key Exchange (IKE) Aggressive Mode with Pre-Shared Key

Number eight on our list of top ASV scan vulnerabilities has to do with an IPsec VPN technology that functions over the IKE protocol on port 500. 

Resolution: There are a few resolutions that can be applied by the scan customer to resolve this vulnerability. 

  • Disable Aggressive Mode if supported. 
  • Do not use Pre-Shared key for authentication if it's possible. 
  • If using Pre-Shared key cannot be avoided, use very strong keys.
  • If possible, do not allow VPN connections from any IP addresses.

9. SMB Signing Not Required 

If SMB servers are used, SMB Signing Not Required could appear as a valid vulnerability. The idea behind this vulnerability is that, if found, signing is not required on the remote SMB server. This means that an unauthenticated, remote attacker can exploit this to conduct MitM attacks against the SMB server. 

Possible Resolutions:

  • Enforce message signing in the host's configuration. 
    • On Windows, this is found in the policy setting 'Microsoft network server: Digitally sign communications (always).’ 
    • On Samba, the setting is called 'server signing.’

10. OpenSSL 'ChangeCipherSpec' MiTM Potential Vulnerability only signals due to the support of certain versions of OpenSSL.

This vulnerability only shows up due to the support of certain versions of OpenSSL. 

Resolution: For all OpenSSL 0.9.8 SSL/TLS users, upgrade to 0.9.8za; for the OpenSSL 1.0.0 SSL/TLS users, upgrade to 1.0.0m; and for OpenSSL 1.0.1 SSL/TLS users, upgrade to 1.0.1h. 

Although this vulnerability shows up frequently, it is often prone to False Positives which are often disputed by proving they are on newer versions of OpenSSL than those listed above as vulnerable.

11. Terminal Services Doesn't Use Network Level Authentication (NLA) 

This alert appears if an RDP or Remote Desktop Protocol service is enabled on the scan customer’s network. NLA uses strong server authentication which protects against MitM attacks during transmission. It also protects the remote computer from malicious users and software by completing user authentication before a full RDP connection is established. 

Resolution: Enable Network Level Authentication (NLA) on the remote RDP server. This can be found on the ‘Remote’ tab of the ‘System’ settings on Windows. 

12. FTP Supports Cleartext Authentication

Usually found on port 21 (but can be configured to be on other non-standard ports) the FTP Supports Cleartext Authentication vulnerability flags if the FTP service supports a login without a means to encrypt. 

Resolution: Either switch to the FTPS protocol, which uses TLS/SSL to encrypt, or use the SFTP protocol handled over the SSH encryption suite. 

13. Microsoft Windows Remote Desktop Protocol Server Man-in-the-Middle Weakness 

This alert will show up on a scan customer’s results if they are supporting certain versions of RDP. In this case, the RDP client makes no effort to validate the identity of the server when setting up encryption. An attacker with the ability to intercept traffic from the RDP server can establish encryption with the client and server without being detected. A MiTM attack of this nature would allow the attacker to obtain any sensitive information transmitted, including authentication credentials. This flaw exists because the vulnerable version of this RDP server stores a hard-coded RSA private key in the mstlsapi.dll library. Any local user with access to this file (on any Windows system) can retrieve the key and use it for this attack. 

Resolution: A scan customer should force the use of SSL/TLS as a transport layer for this service if supported, and/or select the 'Allow connections only from computers running Remote Desktop with Network Level Authentication' setting if it is available.

14. The Terminal Services Encryption Level is Medium or Low 

This vulnerability also has to do with the RDP service the scan customer is running. The idea here is that the remote Terminal Services service is not configured to use strong cryptography. If by using this service and having weak cryptography implemented may allow an attacker to eavesdrop on the communications more easily and obtain screenshots and/or keystrokes. 

Resolution: The recommended fix for this vulnerability is to change the RDP encryption level to either option below:

  • 3 – High
  • 4 – FIPS Compliant

15. Script Src Integrity Check 

This relatively new vulnerability has made it onto the top vulnerabilities that we flag for. In this situation, the remote host may be vulnerable to payment entry data exfiltration due to javascript included from potentially untrusted and unverified third parties’ script src. 

Resolution: The recommended fix for this issue is to set script integrity checking on the target script or to remove target script. 

  • “Integrity” refers to uncompromised data, i.e., what we receive is exactly what was requested. 
  • Usually this is done by ensuring that the data received is protected by a hash and digest.

Oftentimes, the scan customer can run their javascript link found in the data received through an SRI hash generator to get that hash and digest. 

  • The scan customer then needs to embed that hash inside the source code of the 3rd-party script. 

The top ASV Scan Vulnerabilities are always changing

While these 15 vulnerabilities are the most frequently seen vulnerabilities right now, the list can change. Due to the nature of cybersecurity and the fact that new vulnerabilities arise all the time, we always recommend that in order to harden their systems customers should first determine if any open port or service can either be closed, filtered, or disabled to prevent access into the Cardholder Data Environment (CDE). 

If CDE access can be restricted to only those who need access, these vulnerabilities should not alert on scan results for our scan customers. Second, customers should see if segmentation can be set up to segment insecure portions of the network away from secure portions of the network or the CDE. By ensuring segmentation through strong means, actual attack vectors and threats found in the vulnerability assessment scan could be considered outside of the scope of PCI Compliance. 

If you have a question about your ASV scan or ASV scan results, please contact our support team. 

Join Thousands of Security Professionals and Subscribe


We are excited to work with you.


Thank you!

Your request has been submitted.