CVE-2026-109396

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.

Thelia 3.0.0's back-office Email/Messages feature contains a server-side template injection (SSTI) flaw allowing any authenticated user with 'Messages' permission to supply unsandboxed Twig templates, executed as raw code. Can lead to full compromise of application and host.

Thelia 2.6.1 contains an absolute path traversal vulnerability in its Smarty template handling that enables SSTI and remote code execution. The checkTemplate() validation restricts relative directory traversal sequences but does not reject absolute paths, allowing an authorized user to supply an arbitrary filesystem path as a template. Smarty then loads and compiles the referenced file without an effective security policy, so depending on filesystem layout and deployment configuration, template code in the file can be executed with the web server's privileges.

Thelia v2.6.1 contains path traversal and PHP code injection vulnerabilities in its translation editor that can be chained to achieve remote code execution. The item_name parameter does not sanitize directory traversal sequences, allowing an authenticated user with UPDATE-level permissions to write files outside the expected templates directory, including web-accessible paths. Additionally, the translation-writing logic does not escape backslashes, allowing inputs to break out of PHP string literals and inject executable code. Chained together, these flaws allow a malicious PHP file to be written to a web-accessible path and executed with web-server privileges.

Thelia v2.6.0 permits authenticated administrators to upload and install modules via the ZIP upload function without validating or sandboxing embedded PHP code. An attacker can include malicious PHP code in a module's install() method which will then be executed upon installation, enabling remote code execution with the privileges of the web server.

Thelia 2.6.0 uses Smarty for email templates without properly restricting access to dangerous PHP functions. An authenticated administrator can inject malicious Smarty expressions into email templates via the messages configuration interface, and when the template is previewed or rendered, functions such as system(), exec(), file_put_contents(), and file_get_contents() can be executed with the privileges of the web process. This allows arbitrary OS command execution, file read/write operations, and RCE on the underlying server.

Thelia v2.6.0's Smarty templates (address.html and address-update.html) fail to properly escape double quotes in the 'next' parameter, enabling reflected Cross-Site Scripting (XSS) when an authenticated user visits the malicious link containing attacker-controlled JavaScript.

In Thelia v2.6.0, both the admin login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate admin accounts. Lack of rate limiting facilitates scalable attacks.

Thelia v2.6.0 is vulnerable to multiple stored XSS vulnerabilities within the administrative interface. User-supplied input is stored without sufficient output encoding or sanitization and is later rendered in the administrator interface and/or the web store's product pages, allowing arbitrary JavaScript execution when the affected pages are viewed. The vulnerability affects multiple administrative functions including category creation and product creation.

Thelia v2.6.0 contains an open redirect vulnerability in its address creation workflow. After a user accesses a crafted URL and successfully submits the 'Add New Address' form, the application redirects them to the URL specified in the 'next' parameter. Because the application does not validate whether the destination belongs to the same origin or an approved allowlist, an attacker can supply an arbitrary external URL and redirect users to an attacker-controlled website.