CVE-2020-15999

What it actually does

A heap buffer overflow in FreeType occurs while decoding PNG-compressed embedded bitmap glyphs (sbit data in TrueType/OpenType fonts). In Google Chrome prior to 86.0.4240.111, a remote page that supplies a crafted font can corrupt heap memory in the renderer (or any other process linking the vulnerable FreeType). The assigned CVSS emphasizes availability (process crash), but heap corruption of this class has been used in the wild as a memory-corruption primitive toward renderer code execution when combined with additional bugs.

Why it matters to the business

Unpatched browsers and any product that still bundles vulnerable FreeType can be compromised when a user simply opens a malicious page, leading to workstation takeover, session theft, and follow-on intrusion. The flaw is on CISA KEV (due 2021-11-17, long overdue), has been actively exploited in the wild for years, and carries a high and rising EPSS (0.44 → 0.64 over 30 days). FreeType is ubiquitous across browsers, desktops, document renderers, and embedded UI stacks, so residual exposure is an enterprise-wide patch-compliance and regulatory risk rather than a Chrome-only issue. Ransomware use is not indicated in KEV.

How an attack unfolds

An attacker places a web page that embeds or downloads a malicious font whose PNG-compressed bitmap glyph triggers the FreeType heap overflow. The victim is induced to open that page in a vulnerable Chrome/Chromium build (or another FreeType consumer) via phishing, malvertising, or a compromised site. Parsing the font corrupts the renderer heap; in observed in-the-wild campaigns this primitive was chained with other Chrome/Chromium memory-safety bugs (use-after-free, V8 type confusion / incorrect implementation) to run attacker code in the renderer and then attempt sandbox escape or data theft. No further interaction beyond loading the page is required after the user navigates to it.

How to fix it

Upgrade Google Chrome/Chromium to 86.0.4240.111 or later. For standalone or embedded FreeType (desktop.org/freetype/freetype GIT), move to a build that includes commit 6a2b3e4007e794bfc6c91030d0ed987f925164a8 or any later upstream/release that contains that fix, then rebuild and redeploy all downstream binaries (browsers, office/PDF viewers, UI toolkits, printers, and embedded devices). Until patched, restrict untrusted browsing, disable unnecessary remote font loading where the product allows it, and isolate high-risk users. Confirm SBOMs and OS packages so leftover libfreetype copies are not missed.

How to confirm the fix worked

Inventory Chrome/Chromium and every FreeType consumer; verify browser version is 86.0.4240.111+ and FreeType source/package maps to commit 6a2b3e4007e794bfc6c91030d0ed987f925164a8 or a later patched release. Check OS package versions (libfreetype6 and equivalents), container/base images, and statically linked copies via SBOM or binary identification. After upgrade, smoke-test font rendering (web, PDF, desktop UI) and confirm crash telemetry for freetype/renderer faults has dropped. Treat any remaining pre-fix commit or Chrome < 86.0.4240.111 as exposed.

Typical attack path

1. Attacker prepares a page that loads a crafted font containing a malformed PNG-compressed bitmap glyph targeting FreeType.
2. Page is delivered through phishing, malvertising, a watering-hole, or an injected iframe.
3. Victim opens the page in Chrome/Chromium before 86.0.4240.111 or another app using unpatched FreeType.
4. FreeType parses the glyph and overflows a heap buffer in the renderer (or host process).
5. Heap corruption is combined with additional browser primitives (historically UAF / V8 issues) to obtain renderer code execution.
6. Attacker attempts post-exploitation such as sandbox escape, credential or session theft, or implant deployment.

How to detect it

This is a client-side memory-corruption bug; successful exploitation often leaves only a renderer crash plus later post-exploitation, so hunt artifacts rather than a single exploit signature. Review browser crash reports and Breakpad/Crashpad minidumps for chrome/chromium renderer faults in libfreetype / freetype, especially stacks involving PNG sbit / Load_SBit_Png-style paths, on builds before 86.0.4240.111. Correlate short-lived visits to untrusted sites with subsequent renderer crashes, unexpected child processes of the browser, sandbox-escape attempts, or new persistence. Endpoint/EDR process trees, DNS/proxy logs for the landing page, and font-cache or downloaded .ttf/.otf/.woff files from the same timeframe are useful. Historical in-the-wild use was often chained with other Chrome UAF and V8 bugs—treat clustered Chromium memory-safety crashes as higher confidence. There is no reliable network IOC unique to the overflow itself.

• chrome/chromium version < 86.0.4240.111
• libfreetype
• freetype
• Load_SBit_Png
• renderer crash AND freetype
• chrome.exe --type=renderer
• Crashpad
• Breakpad minidump
• embedded PNG sbit / sbix / CBDT font tables in downloaded .ttf/.otf/.woff

What your security team should do

• Patch or rebuild all Chrome/Chromium and FreeType consumers immediately; this is an overdue CISA KEV item with confirmed in-the-wild exploitation.
• Hunt SBOM, package, and endpoint inventory for libfreetype/freetype and Chrome < 86.0.4240.111, including embedded and statically linked copies.
• Prioritize internet-facing user workstations and VDI/browser farms; EPSS is high and rising.
• Review historical crash and EDR telemetry for renderer/FreeType faults around first publication (2020-11) and any later unpatched window.
• Block or tightly control loading of untrusted webfonts and untrusted HTML in high-security enclaves until inventory is clean.
• Track related Chrome memory-corruption KEV issues (UAF and V8 type-confusion/incorrect-implementation families) as common chaining partners.