CVE-2026-77468 in Lychee
Summary
by MITRE • 10/15/2026
Lychee is a free, open-source photo-management tool. Prior to 7.7.0, GET /docs/api exposes the Scramble-generated OpenAPI documentation configured by config/scramble.php to unauthenticated callers after installation, with observed response size and latency suggesting that the schema is regenerated without an application-level cache. A remote attacker can repeatedly request the unthrottled route to consume server CPU and obtain a detailed map of the API surface and parameter schema. This issue is fixed in version 7.7.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Lychee, specifically affecting versions prior to 7.7.0, represents a significant security misconfiguration that exposes internal application architecture details while simultaneously creating a vector for resource exhaustion attacks. As an open-source photo-management tool, Lychee relies on robust API endpoints to facilitate interactions between clients and the server infrastructure. However, during the initial installation phase or if specific configuration parameters are left at their defaults, the system inadvertently exposes its Scramble-generated OpenAPI documentation via the GET /docs/api endpoint without requiring any form of authentication. This exposure allows unauthenticated remote actors to access a comprehensive schema that details every available API route, expected input parameters, data types, and potential response structures. The presence of this detailed map effectively neutralizes the security benefit of obscurity, providing attackers with precise intelligence on how to interact with the application's backend services, identify valid endpoints for further exploitation, and craft payloads tailored to specific parameter expectations.
Beyond the information disclosure aspect, the technical implementation of this endpoint introduces a severe availability risk due to performance inefficiencies. Analysis indicates that the OpenAPI schema is regenerated dynamically upon each request rather than being cached at an application level or persisted in memory. This lack of caching means that every GET request triggers a computationally expensive process where the framework must introspect the codebase, parse annotations, and construct the documentation structure from scratch. Because this route is unthrottled and lacks rate limiting mechanisms, it becomes susceptible to abuse through automated scripting tools. A remote attacker can send a high volume of requests in rapid succession, forcing the server CPU to perform repetitive regeneration tasks for each request. This behavior leads to significant latency increases and substantial consumption of server processing resources, effectively resulting in a Denial of Service condition where legitimate users experience degraded performance or complete service unavailability due to resource starvation caused by malicious traffic patterns.
From a classification perspective, this vulnerability aligns with CWE-209, which describes the generation of an error message that includes sensitive information about the software environment, and more critically, CWE-770, Allocation of Resources Without Limits or Throttling. The exposure of API schemas also relates to CWE-200, Information Exposure, as it reveals internal system details that could aid in subsequent attacks such as SQL injection or cross-site scripting if those endpoints are found to be vulnerable. In terms of the MITRE ATT&CK framework, this behavior facilitates Reconnaissance techniques under T1592, specifically Gathering Victim Host Information and T1589, Gather Victim Identity Information, by allowing attackers to map out the attack surface with high precision. The resource exhaustion aspect corresponds to Availability impacts often seen in Distributed Denial of Service (DDoS) scenarios, though here it is executed via a single-vector application-level abuse rather than network flooding.
To mitigate this vulnerability and restore secure operations, immediate action must be taken by upgrading Lychee to version 7.7.0 or later, where the developers have addressed both the information disclosure and performance issues. For organizations unable to upgrade immediately due to dependency constraints, temporary mitigations should focus on restricting access to the /docs/api endpoint at the web server or reverse proxy level. This can be achieved by configuring firewall rules or Nginx/Apache configurations to block external requests to this path while allowing internal monitoring tools if necessary. Additionally, implementing rate limiting policies for all API endpoints is a critical defense-in-depth measure that would prevent any single IP address from consuming excessive CPU resources through rapid-fire requests. Administrators should also audit their configuration files to ensure that debug modes or documentation generators are disabled in production environments unless explicitly required and secured with strong authentication mechanisms such as OAuth2 or basic HTTP auth, ensuring that sensitive architectural details remain inaccessible to untrusted parties.