CVE-2026-111497 Brotli out-of-bounds write

[jmaegn]

The update to resolve CVE-2026-111497 (#10340) is in the main branch already. Is there a release planned for sooner than the next quarterly (2027-01) so this can be incorporated into downstream projects?

[aclark4life]

No, but it could certainly be discussed. @hugovk thoughts ?

[hugovk]

First I'd like to understand the actual exposure to Pillow.

At least we've not had any PoC reports or repros, afaik only responses to CVE scanner tools.

[jmaegn]

From Claude (similar results from a downstream app):

The path is through Pillow’s font loading, not its image decoders.

The path
Application code calls ImageFont.truetype() with a font file or file-like object that an attacker controls.
Pillow passes it to FreeType, which was built with Brotli support. Pillow’s build files comment that Brotli is built “for FreeType WOFF2 font support,” and its test loads a .woff2 font through ImageFont.truetype. Your ldd output shows libfreetype in both images’ pillow.libs linking the bundled libbrotlidec.
github
FreeType decompresses the WOFF2 font’s Brotli stream using the bundled decoder.
A crafted stream triggers the decoder bug. The CVE record describes a buffer overflow in the Brotli decoder that can corrupt adjacent decoder state, disclose memory contents, cause a denial of service, or potentially allow code execution from a crafted Brotli-compressed stream.
osv

Two conditions are required: the application must pass attacker-controlled font data to ImageFont, and that data must be WOFF2.

Not part of the documented path
I found no documentation that Pillow’s image decoders (JPEG, PNG, WebP, and so on) invoke Brotli. Pillow’s security page says its primary attack surface is parsing untrusted image data, but that concerns its image parsers, not this CVE. I haven’t verified whether any image format plugin reaches the decoder.
readthedocs
HarfBuzz in the 13.0.0 wheel also links the bundled decoder. I couldn’t find what it does with it, so I can’t say whether it adds a second route.

[aclark4life]

Two conditions are required: the application must pass attacker-controlled font data to ImageFont, and that data must be WOFF2.

Where have these conditions been met in public? Which applications or sites have been attacked using this path? I suspect anyone with an answer to that question has already patched their Pillow and would not benefit from a new release. If someone said "all versions of very popular app are vulnerable to this attack" then obviously we'd be doing a patch release, but I haven't seen anything like that, ever in 16 years of Pillow (that I can recall!)

[wiredfool]

That (open untrusted font) was one of our oss-fuzz paths that uncovered some font handling bugs.

[jmaegn]

If the position is that this vulnerability doesn't warrant an official patch release ahead of the the scheduled quarterly, and that downstream users ought to do a custom build on their own, that's fine.