CVE-2026-109397 in Thelia
Summary
by MITRE • 10/12/2026
Thelia before 3.1.2 and 3.2.x before 3.2.1 contains an unrestricted file upload vulnerability that allows authenticated back-office users to upload PHP files by appending a trailing space to filenames. FileProcessorService validates the raw filename but FileManager::sanitizeFileName() strips the space, storing an executable .php file under public/cache/documents/ for code execution as the web server user.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in Thelia versions prior to 3.1.2 and 3.2.x before 3.2.1 represents a critical security flaw rooted in inconsistent filename sanitization logic within the application's file handling subsystems. This issue specifically manifests as an unrestricted file upload vulnerability, which is classified under CWE-434: Unrestricted Upload of File with Dangerous Type. The core technical failure lies in the discrepancy between two distinct components responsible for processing uploaded files: the FileProcessorService and the FileManager::sanitizeFileName() method. When a user initiates a file upload through the back-office interface, the system first validates the raw filename provided by the client against allowed extensions or patterns using the FileProcessorService logic. This initial validation step is designed to ensure that only permitted file types are accepted into the processing pipeline. However, subsequent to this validation, the FileManager component applies its own sanitization routine via the sanitizeFileName() function before persisting the file to disk.
The critical flaw occurs because the sanitizeFileName() method strips trailing whitespace from filenames during storage preparation. An authenticated attacker can exploit this by uploading a PHP script with a filename that includes a trailing space character appended after the .php extension, such as malicious.php[space]. The FileProcessorService perceives this file as having an allowed or neutral extension depending on its specific validation regex, potentially allowing it to pass initial checks if they are not strictly anchored to end-of-string boundaries. Once passed through the service layer, the FileManager processes the filename and removes the trailing space, resulting in a stored file named malicious.php. This discrepancy between the validation stage and the storage stage creates an effective bypass of security controls intended to prevent executable code from being saved on the server filesystem.
The operational impact of this vulnerability is severe due to its direct consequence: arbitrary remote code execution as the web server user. The uploaded PHP files are stored in the public/cache/documents/ directory, which is typically accessible via HTTP requests by default configurations or specific application routing rules. Because the file ends up with a .php extension after sanitization, when an attacker triggers the execution of this file through a browser request to its URL path, the web server interprets it as PHP code and executes it within the context of the web service account. This grants the attacker full control over the underlying operating system processes associated with that user privilege level, potentially leading to complete compromise of the application environment, data exfiltration, lateral movement across internal networks, or persistence mechanisms being established on the host machine.
This vulnerability aligns closely with MITRE ATT&CK technique T1505.003: Web Shell, which describes attackers uploading malicious scripts to web directories for persistent access and command execution. The exploitation path relies heavily on authentication, meaning that only users who have already gained valid credentials within the Thelia back-office can leverage this flaw. However, given that many administrative accounts may possess weak passwords or be targeted via credential stuffing attacks, the risk surface remains significant. Furthermore, because the vulnerability involves file upload mechanisms common in content management systems and e-commerce platforms like Thelia, it highlights a broader class of risks where input validation is not consistently applied across all stages of data processing pipelines.
Mitigation strategies must focus on enforcing strict filename sanitization at every stage of the upload lifecycle rather than relying on disparate checks that may conflict with one another. The most effective remediation involves upgrading to Thelia version 3.1.2 or later, where this inconsistency has been addressed by ensuring that validation rules account for trailing whitespace and that sanitized filenames are validated against allowlists before storage. Additionally, administrators should implement defense-in-depth measures such as configuring the web server to disable script execution in upload directories like public/cache/documents/. This can be achieved through specific configuration directives in Apache or Nginx that prevent PHP interpretation within these paths regardless of file extensions. Regular security audits and static code analysis tools configured to detect inconsistent sanitization patterns across service layers should also be employed to identify similar architectural flaws before they are exploited in production environments.