CVE-2026-12600: Uncontrolled memory usage in Innodata Labs’ Poppler JPX decoderUncontrolled memory usage in Innodata Labs’ Poppler JPX decoder
Denial-of-service (DoS) vulnerability in the internal JPEG2000 (JPX) decoding implementation of the Poppler fork developed by Innodata Labs. When an application processes an untrusted PDF file containing specially crafted JPXDecode images, a remote attacker can cause uncontrolled memory consumption. The flaw occurs in the JPXStream::readCodestream() function, where values controlled from the SIZ segment (such as img.nComps) are used for the memory allocation of tiles and components without adequate validation. This allows an attacker to force excessive memory allocation and cause a resource exhaustion, ultimately causing the pdftoppm process to terminate due to out-of-memory (OOM) conditions.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Remove/disable the internal JPX decoder code in the Innodata Labs Poppler fork, since Poppler (upstream) removed the JPX decoder code and no fix is reported yet for the Innodata Labs fork.
Poppler (fork developed by Innodata Labs) - internal JPEG2000 (JPX) decoder JPX decoder code (JPXStream::readCodestream) availability = removed/disabled - Compensating control
Ensure pdftoppm processes only trusted/untrusted PDFs according to your exposure model (e.g., avoid converting attacker-supplied PDFs, or gate conversion behind strict access controls) to mitigate the remote DoS via crafted JPXDecode images.
Event History
Frequently Asked Questions
What must an attacker provide to trigger the issue?
An attacker needs an application to process an untrusted PDF containing specially crafted JPEG2000 images encoded with JPXDecode. The crafted image’s SIZ segment supplies values that drive excessive allocation for image tiles and components.
What is the practical impact on affected systems?
Processing the malicious PDF can consume uncontrolled amounts of memory. This can exhaust available memory and cause the pdftoppm process to terminate under out-of-memory conditions.
Which workflows are most exposed?
Workflows that use the Innodata Labs Poppler fork to render or otherwise process untrusted PDFs are exposed, particularly where pdftoppm handles PDF content supplied by remote or untrusted users.