Google Chrome caches TLS sessions before certificate validation occurs.

published 2017-04-13 9y ago modified 2026-06-17 4mo ago also EUVD-2013-6464

cvss: 6.5; version 3.1, NVD
cisa kev: Not listed; not in CISA's catalog
epss: 0.3%; EPSS 0.3% chance of exploitation in 30 days, percentile 28%
public exploits: 0; none known

Patch / fix

fixed in 1 links 1

google chrome 33

bugs.chromium.org/p/chromium/issues/detail?id=305220 advisory

Is CVE-2013-6662 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Exploit prediction

0.35% chance of exploitation in the next 30 days, higher than 28% of all scored CVEs (FIRST EPSS, 2026-11-09).

CVSS scores

assigned by	version	score	vector
NVD	3.1	6.5	CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
NVD	2.0	4.3	AV:N/AC:M/Au:N/C:N/I:P/A:N

Classification

Weakness

CWE-295 Improper Certificate Validation

Technology feeds

Google Chrome rss critical rss

References

bugs.chromium.org /p/chromium/issues/detail?id=305220
issue-tracking, patch, third-party-advisory

Sources

CVE List CVE-2013-6662
NVD CVE-2013-6662

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.

CPEs and fixed versions use Anchore's correction of NVD's data: Per debian, this was fixed in late 2013 but nt worth wasting resources pinpointing exact version, so we're choosing 33 as the fix for now.