imgproxy v4.0.11 custom BMP loader heap buffer overflow causes remote process crash

The decoder accepts arbitrary BMP bit depths for uncompressed BI_RGB input, routes every value greater than or equal to 24 through its 24/32-bit row generator, allocates a row buffer sized for at most four bytes per pixel, and then reads a row sized from the attacker-controlled bit depth. The inconsistent allocation and read invariants allow source-image bytes to be written beyond the native heap allocation.

I confirmed the memory-safety defect by compiling the exact v4.0.11 loader with AddressSanitizer. At width 512, a valid 32-bpp BMP uses a 2,052-byte row buffer, reads 2,048 bytes, and completes normally. A matched 40-bpp input retains the same 2,052-byte allocation but performs a 2,560-byte write. ASan reports a 508-byte heap-buffer-overflow at the first byte after the allocation.

I separately reproduced terminal availability impact using the immutable official v4.0.11 container image and its documented HTTP processing route. One request for a crafted 65535-bpp BMP caused a fatal SIGSEGV in runtime.memmove, with the stack continuing through AsyncBuffer.ReadAt and vips.imgproxyReaderRead. The entire imgproxy process exited with status 2; both /health and processing of a safe image became unavailable. Restarting the same container restored normal processing. No live or third-party system was tested.

The overwrite bytes and length are attacker controlled. Two bounded, non-weaponized canonical-marker experiments against the unmodified official image did not dem…