Replace remaining sprintf() with snprintf()

[myagmartseren]

Replace All Remaining sprintf() with snprintf()

Summary

Multiple C source files still use sprintf() without bounds checking — the same class of vulnerability fixed in CVE-2024-28219. This PR replaces all remaining instances with snprintf().

Affected Files (6 call sites)

File	Line	Context
src/libImaging/QuantPngQuant.c	129	sprintf(version, "%d.%d.%d", ...)
src/libImaging/JpegEncode.c	405	sprintf(version, "%d.%d", ...)
src/_webp.c	56	sprintf(message, "could not assemble chunks: %s", ...)
src/_webp.c	58	sprintf(message, "could not set %.4s chunk: %s", ...)
src/_webp.c	652	sprintf(message, ": Image size exceeds WebP limit...")
src/_webp.c	746	sprintf(version, "%d.%d.%d", ...)

Fix

All sprintf(buf, ...) → snprintf(buf, sizeof(buf), ...)

Classification

• CWE-120 (Buffer Copy without Checking Size of Input)
• CWE-676 (Use of Potentially Dangerous Function)
• CVSS 3.1: 4.8 (Medium)
• Related: CVE-2024-28219 (same pattern, partially fixed)

[EricSoroos]

Thanks for running a scanner -- note that we have a security policy here: https://github.com/python-pillow/Pillow/blob/main/.github/SECURITY.md that does not include posting security sensitive issues in public.

Also note that in this case, some of the items that are running through sprintf are statically determined at compile time and have no way of being attacker controlled.

[radarhere]

This does seem like a rather difficult exploit.

If an attacker managed to change the value WEBP_MAX_DIMENSION or JPEG_LIB_VERSION, it really sounds like they're able to modify the source code of one of our dependencies. liq_version() and WebPGetDecoderVersion() are virtually constants, and kErrorMessages is internal.