Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
.NET
.NET NuGet
CISA KEV · ACTIVELY EXPLOITED
HIGH severity

CVE-2020-16009 — CefSharp.Common

HIGH

CVE-2020-16009 is a high-severity (CVSS 8.8) Out-of-bounds Write vulnerability in CefSharp.Common. It is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03) — treat it as actively exploited and patch now. A fix is available for CefSharp.Common — see the affected versions and patch details below.

Inappropriate implementation in V8

Also known asGHSA-m7mf-48hp-5qmr
Published
Updated
Affected
4 pkgs
Patched
4 / 4
Exploits
5 known
Exploitation data as of Oct 24, 2026 · OSV.dev, NVD, CISA KEV, FIRST.org (EPSS)

Exploitation Status

Actively exploited in the wild

  • Confirmed by CISA's Known Exploited Vulnerabilities catalog on 2021-11-03. Federal agencies were required to remediate by 2022-05-03.
  • A successful exploit gives an attacker total control of the affected component, not partial access.

Exploitation and automatability from CISA (KEV catalog and SSVC triage) for CVE-2020-16009.

EPSS Exploitation Probability

via FIRST.org ↗
48.3%probability of exploitation in next 30 days
High Risk0.00%
Lower risk than most CVEs99th percentile — riskier than 99% of all scored CVEsHighest risk
37.5%56.7%76.0%95.2%84.4%48.3%Apr 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2020-16009 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 395,249 CVEs with a current EPSS score, this one falls in the 10–50% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

4 pkgs affected
.NETCefSharp.Common.NETCefSharp.Wpf.NETCefSharp.WinForms.NETCefSharp.Wpf.HwndHost

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects NuGet packages — download data is not available via public APIs for these ecosystems.

Description

CVE-2020-16009: Inappropriate implementation in V8

Google is aware of reports that exploits for CVE-2020-16009 exist in the wild.

Allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

There is currently little to no public information on the issue other than it has been flagged as High severity.

Affected Packages

4 total 4 fixed
EcosystemPackageVulnerable rangeFix
.NETNuGetCefSharp.Commonall versions86.0.241dotnet add package CefSharp.Common --version 86.0.241
.NETNuGetCefSharp.Wpfall versions86.0.241dotnet add package CefSharp.Wpf --version 86.0.241
.NETNuGetCefSharp.WinFormsall versions86.0.241dotnet add package CefSharp.WinForms --version 86.0.241
.NETNuGetCefSharp.Wpf.HwndHostall versions86.0.241dotnet add package CefSharp.Wpf.HwndHost --version 86.0.241

Affected Products

8 products · 11 configurations
Application
cefsharpcefsharp
< 86.0.241
range
OS
debian linuxdebian
1 version
10.0
OS
fedorafedoraproject
2 versions
3233
Application
chromegoogle
< 86.0.4240.183
range
Application
edgemicrosoft
< 86.0.622.63
range
Application
edge chromiummicrosoft
< 86.0.4240.183
range
Exploits & PoCs
5

Research use only. For defensive security, authorized penetration testing, and academic research only. Never execute exploit code against systems without explicit written authorization.

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for CefSharp.Common, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update CefSharp.Common to 86.0.241 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2020-16009 is resolved across your whole dependency graph.

  3. Workarounds

    Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant
ProductFixed inAdvisory
Red Hat Enterprise Linux 6 Supplementarychromium-browser-0:86.0.4240.183-1.el6_10RHSA-2020:4974

Frequently Asked Questions

CVE-2020-16009: Inappropriate implementation in V8 - https://chromereleases.googleblog.com/2020/11/stable-channel-update-for-desktop.html - https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-16009 Google is aware of reports that exploits for CVE-2020-16009 exist in the wild. Allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. There is currently little to no public information on the issue other than it has been flagged as `High` severity.
O3 Security · Impact-Aware SCA

Is CVE-2020-16009 in your dependencies?

Find it across NuGet, including transitive dependencies.

CVE-2020-16009: CefSharp.Common (High 8.8, KEV)