SixLabors ImageSharp CVE-2026-106116

Exploitation requires that the target application use ImageSharp (versions 2.0.0 through before 4.1.2) to decode attacker-supplied image input, and that the input be a 64-bit BigTIFF file whose Exif IFD declares an entry count while fewer than 20 bytes remain in the stream, causing ExifReader.ReadValue64 to return without advancing the stream or breaking the outer loop. The key limiting factor is that the deployment must accept and decode untrusted images; impact is further bounded to a single decoder thread's CPU consumption for an attacker-controlled time (the advisory explicitly does not claim worker-pool/thread-pool exhaustion), so a single malformed file degrades rather than fully denies service.

All signals point to a genuine but moderate-severity availability issue rather than a top-tier emergency. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3 Medium) describes a remotely reachable, low-complexity, unauthenticated condition with no confidentiality or integrity impact and only LOW availability impact - consistent with CWE-835 (loop with unreachable exit condition). No EPSS score, no CISA KEV listing, and no public exploit code were supplied, so there is no evidence of active or imminent widespread exploitation. Crucially, the vendor description self-limits the impact: 'This report does not claim worker-pool exhaustion,' meaning a single decoder thread is tied up for an attacker-controlled duration rather than the whole service being denied - which is why A:L (not A:H) is appropriate and why this is not a crash-the-server bug. Net assessment: patch it if your application decodes untrusted/user-supplied images, but treat it as routine maintenance (medium) rather than an incident. No signals conflict; the main caveat is that the provided PR diff shows ICC-profile channel-count hardening and new stream-bounds helpers rather than the exact ExifReader.ReadValue64 fix named in the description, so verify the precise code change against the commit before claiming full remediation detail.

An attacker submits a small, malformed BigTIFF image to an application (for example an image-upload or thumbnailing endpoint) that uses ImageSharp to decode it. The declared 64-bit BigTIFF IFD entry count is trusted, and because ExifReader.ReadValue64 returns without advancing the stream or breaking the loop when fewer than 20 bytes remain, the outer loop never terminates and one decoder thread spins, consuming CPU for an attacker-controlled duration. No public exploit identified at time of analysis.