SSL/TLS Vulnerability Database

Search known SSL/TLS vulnerabilities and CVEs

Searching vulnerability database...

Found vulnerabilities

About

The SSL/TLS Vulnerability Database provides a comprehensive catalog of known vulnerabilities affecting SSL/TLS implementations, including protocol-level flaws, implementation bugs, and cryptographic weaknesses. Each vulnerability entry includes detailed technical descriptions, affected software versions, CVSS severity scores, remediation guidance, and detection methods.

The database covers critical vulnerabilities from Heartbleed (CVE-2014-0160) and POODLE (CVE-2014-3566) to newer threats like Raccoon (CVE-2020-1968) and HoneyBadger (CVE-2021-3449). Use this resource to understand which vulnerabilities affect your infrastructure, verify that your systems are patched, and stay informed about emerging SSL/TLS security threats as they are discovered.

How to Use

1Browse the vulnerability database by category, severity, or affected software
2Click on any vulnerability entry to view full technical details and remediation steps
3Use the search function to find specific CVEs or vulnerability names
4Check if your server is vulnerable by testing with the linked detection tools

Use Cases

•Vulnerability Assessment: Identify which SSL/TLS vulnerabilities may affect your servers and prioritize patching based on severity and exploitability
•Incident Response: Quickly research newly disclosed vulnerabilities to understand impact and determine if your systems are affected
•Patch Validation: Verify that security patches have been correctly applied by testing for known vulnerabilities
•Security Training: Use the database as a learning resource for understanding SSL/TLS attack vectors and defensive measures
•Audit Documentation: Reference specific CVEs and their remediation status for security audit reports and compliance documentation

What The Catalogue Is

This is a reference of TLS vulnerabilities and the conditions each needs, so you can reason about exposure rather than relying on a version number.

1List each flaw with the precondition it requires — which protocol version, which cipher family, which server behaviour. That framing matters more than the identifier, because the precondition is what tells you whether you are actually exposed.
2Separate historical from applicable. Most entries here are decades old and patched; their value is explaining why old protocols and cipher families remain risky rather than flagging anything live. A site negotiating 1.3 or 1.2 with AEAD suites satisfies almost none of these conditions.
3Point at the check that tests each one, so a catalogue entry leads to a measurement rather than to concern. Knowing a flaw exists is not the same as knowing your server is exposed to it.

Almost every entry here shares the same remedy, which is why disabling the old protocols resolves so many of them at once. A catalogue is most useful when it makes that convergence obvious rather than presenting a long list of separate problems.

Tips & Best Practices

•Subscribe to CVE alerts for SSL/TLS vulnerabilities to stay informed about new discoveries
•Test for critical vulnerabilities immediately when new CVEs are disclosed — especially remote code execution flaws
•Keep all SSL/TLS libraries (OpenSSL, NSS, BoringSSL) updated to the latest patched versions
•Use the vulnerability database to create a prioritized patching schedule based on CVSS scores

Technical Details

●CVE Coverage: Comprehensive database of SSL/TLS CVEs from 2014 to present with CVSS v3.1 scoring

●Categories: Protocol vulnerabilities, implementation bugs, cryptographic weaknesses, side-channel attacks

●Severity Levels: Critical (9.0-10.0), High (7.0-8.9), Medium (4.0-6.9), Low (0.1-3.9)

● Detection Methods: Links to detection tools and test scripts for each vulnerability

Frequently Asked Questions

The database is updated whenever new SSL/TLS vulnerabilities are disclosed, typically within 24-48 hours of public disclosure. Critical vulnerabilities with active exploits are added immediately. The database also receives monthly updates to add newly assigned CVEs and update remediation information for existing entries.

Prioritize by CVSS score and exploitability: Heartbleed (CVE-2014-0160) and other remote code execution flaws first, followed by padding oracle attacks (POODLE, Lucky 13), then downgrade attacks (FREAK, Logjam), and finally information disclosure vulnerabilities. Always patch critical and high-severity issues within 24-72 hours.

Use the detection method linked in each vulnerability entry, or run the SSL Scanner tool which checks for known vulnerabilities automatically. The scanner tests your server against all entries in the vulnerability database and reports any matches. For library-specific vulnerabilities, check your server's OpenSSL or NSS version against the affected versions listed.

Because TLS's serious protocol-level flaws are historical. The interesting ones were found in the CBC constructions and in protocol handling of the 1.0 era, and they were fixed by removing those constructions. So a modern server satisfying none of the preconditions here is genuinely not exposed to them — which is the point of listing preconditions rather than just names.

By checking the conditions rather than the names. Each entry lists what it needs — a CBC suite under an old protocol, compression enabled, static RSA key exchange — and those are all observable. Run the protocol and cipher checks on this site and compare the negotiated result against the preconditions. A server on 1.3 with AEAD suites satisfies essentially none of them.

Because TLS 1.3 removed the constructions they all depended on: CBC suites, static RSA key exchange, compression, and the renegotiation mechanisms some of them abused. Enabling 1.3 and disabling everything older closes whole categories at once rather than requiring individual mitigations. That convergence is the single most valuable thing to understand from this catalogue.

Yes, for a different reason than they were when they mattered. They explain why specific deprecated things are deprecated — why CBC suites are a step down, why forward secrecy exists, why compression is treated as a risk — and that reasoning is what lets you judge new configuration decisions without re-deriving the cryptography each time.

Rarely. It means the catalogue is long, which it is for any protocol with a thirty-year history. What matters is the small number of conditions you actually satisfy. If the protocol check shows 1.2 or 1.3 with modern suites, most of this list does not apply to you at all — and reading it as a list of problems you have is the wrong conclusion from the right information.