CVE-2026-77467 in Lychee
Summary
by MITRE • 10/15/2026
Lychee is a free, open-source photo-management tool. Prior to 7.7.0, Lychee enables ImageMagick PDF support with Ghostscript but does not apply an effective pre-render limit to PDF page dimensions in ImagickHandler::loadPdf(). An authenticated user who can upload a small PDF with an oversized /MediaBox can cause Imagick::readImage() to consume substantial CPU before failing to produce an image. When QUEUE_CONNECTION selects synchronous processing the request can occupy a web worker, while the official asynchronous Docker configuration can clog the shared image-processing queue and delay other work. The advisory did not identify a Ghostscript sandbox escape. This issue is fixed in version 7.7.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Lychee prior to version 7.7.0 represents a significant resource exhaustion flaw rooted in the improper handling of PDF documents during image processing operations. Lychee, an open-source photo-management platform, relies on ImageMagick and Ghostscript to convert various file formats into viewable images for users. Specifically, when a user uploads a PDF document, the application utilizes the ImagickHandler::loadPdf method to process this input. The core technical flaw lies in the absence of effective pre-render limits applied to PDF page dimensions within this handler. While ImageMagick and Ghostscript are powerful tools capable of rendering complex vector graphics, they can also be computationally expensive if not constrained properly. In this specific implementation, the software fails to validate or restrict the size of the /MediaBox attribute found in uploaded PDF files before initiating the rendering process. This oversight allows an attacker to craft a seemingly small PDF file that contains metadata specifying extremely large page dimensions.
When such a maliciously crafted PDF is processed by Imagick::readImage(), the underlying libraries attempt to render pages according to these oversized dimension specifications rather than scaling them down or rejecting the input based on size constraints. This results in substantial CPU consumption as the system attempts to allocate memory and compute pixels for an image that may be effectively infinite or excessively large in resolution. The operational impact of this flaw is particularly severe due to how Lychee handles background tasks through its queue connection settings. In configurations where QUEUE_CONNECTION selects synchronous processing, a single request from an authenticated user can occupy a web worker thread indefinitely while it attempts to render the oversized image. This blocks other incoming requests on that specific worker, leading to service degradation for all users accessing the platform at that time.
The impact is further exacerbated in environments utilizing the official asynchronous Docker configuration with shared queues. In this setup, the resource-intensive rendering task clogs the shared image-processing queue. Because the job does not fail quickly but instead consumes significant CPU cycles over a prolonged period, it delays or blocks other legitimate image processing tasks waiting in the queue. This creates a denial-of-service condition where normal functionality is impaired for all users relying on photo uploads and conversions. It is important to note that this vulnerability is strictly classified as a resource exhaustion issue rather than a sandbox escape. The advisory explicitly states that there was no evidence of Ghostscript allowing an authenticated user to break out of its restricted environment or execute arbitrary code outside the intended scope. Therefore, while the system remains secure against remote code execution via this vector, it remains vulnerable to availability attacks through computational abuse.
From a classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption. The attacker leverages valid authentication credentials and legitimate upload functionality to trigger excessive resource usage, fitting the profile of an inefficient algorithmic complexity or unbounded loop scenario within the application logic. In terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, where attackers use computing resources for their own benefit, in this case causing a denial of service by monopolizing server CPU and queue capacity. The attack requires authentication, which limits its scope to internal threats or compromised accounts rather than unauthenticated external actors, but the ease of exploitation via standard upload features makes it a persistent risk if left unpatched.
To mitigate this vulnerability, organizations running Lychee must upgrade immediately to version 7.7.0 or later, where the developers have implemented effective pre-render limits for PDF page dimensions in the ImagickHandler::loadPdf method. This patch ensures that oversized /MediaBox attributes are either rejected during validation or scaled appropriately before rendering begins, preventing the excessive CPU consumption associated with the flaw. For environments unable to upgrade immediately due to dependency constraints, administrators should consider implementing rate limiting on file upload endpoints and configuring web server timeouts to automatically terminate long-running requests that exceed a reasonable duration threshold. Additionally, deploying reverse proxies such as Nginx or Apache in front of the Lychee instance can help absorb some of the load by dropping connections from clients that do not respond within expected timeframes, thereby protecting the backend application workers and queue systems from being overwhelmed by maliciously crafted requests. Regular auditing of uploaded file metadata against known safe dimensions standards is also recommended as a defensive measure to complement software updates.