CVE-2023-52082 in Lychee
Summary
by MITRE • 12/28/2023
Lychee is a free photo-management tool. Prior to 5.0.2, Lychee is vulnerable to an SQL injection on any binding when using mysql/mariadb. This injection is only active for users with the `.env` settings set to DB_LOG_SQL=true and DB_LOG_SQL_EXPLAIN=true. The defaults settings of Lychee are safe. The patch is provided on version 5.0.2. To work around this issue, disable SQL EXPLAIN logging.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 01/20/2024
CVE-2023-52082 represents a critical SQL injection vulnerability affecting Lychee photo management software versions prior to 5.0.2. This vulnerability specifically targets applications using MySQL or MariaDB database systems and exploits a flaw in how SQL queries are handled when certain logging configurations are enabled. The vulnerability operates under the Common Weakness Enumeration classification of CWE-89 SQL Injection, which is one of the most prevalent and dangerous web application security flaws. The flaw manifests when the application's configuration file .env contains both DB_LOG_SQL=true and DB_LOG_SQL_EXPLAIN=true settings, creating an attack surface that allows malicious actors to inject arbitrary SQL commands into the database layer.
The technical exploitation of this vulnerability requires specific preconditions that make it less likely to be exploited in default installations but still represents a significant risk for improperly configured systems. The vulnerability is not active by default since Lychee's standard configuration disables SQL logging features, but when these settings are explicitly enabled for debugging or monitoring purposes, the application becomes susceptible to SQL injection attacks. Attackers can leverage this weakness to execute unauthorized database operations including data retrieval, modification, or deletion, potentially leading to complete database compromise. The vulnerability's impact is particularly concerning because it operates at the database binding level, meaning that successful exploitation could allow attackers to bypass application-level security controls and directly interact with the underlying database system.
The operational impact of this vulnerability extends beyond simple data theft to include potential system compromise and data integrity violations. When SQL injection occurs in a photo management system, attackers could access sensitive user information including personal photographs, metadata, user credentials, and potentially system configuration details. The vulnerability's conditionality means that only systems with explicit logging enabled for debugging purposes are at risk, but this creates a dangerous scenario where administrators might enable these settings for legitimate troubleshooting while inadvertently creating security exposure. Organizations using Lychee in production environments should consider this vulnerability as part of their broader database security posture assessment, particularly when evaluating the security implications of enabling diagnostic logging features.
The recommended mitigation strategy involves upgrading to Lychee version 5.0.2 or later, which includes the necessary patch to address the SQL injection vulnerability. For systems that cannot be immediately upgraded, administrators should disable SQL EXPLAIN logging by setting DB_LOG_SQL_EXPLAIN=false in the .env configuration file. This remediation approach aligns with the ATT&CK framework's defensive techniques for database security, specifically targeting the prevention of command injection attacks through proper input validation and configuration management. Additionally, organizations should implement comprehensive monitoring of database access patterns and consider implementing database activity monitoring solutions to detect potential exploitation attempts. The vulnerability serves as a reminder of the importance of secure configuration management and the principle of least privilege, where diagnostic features should never be enabled in production environments without proper security controls in place.