A Thelia store administrator can reach server code through several back-office workflows in 2.6.0 and 2.6.1, according to a CERT/CC vulnerability note released October 12. Merchants running those releases face a server-takeover risk if an attacker gains the relevant administrative access. CERT/CC says a patch for its 2.6 findings is not yet available. A separately listed flaw in Thelia 3.0.0 has a Twig engine module fix specific to that release.
Restricting access to a storefront’s separate admin site can reduce exposure to several reported paths, but a stolen back-office account can still operate within its assigned permissions. The CVE record for the Thelia 3 flaw identifies thelia/twig-engine-module 1.0.9 as the patched module version for CVE-2026-107248. On 3.0.0 stores, verify the installed Twig module is at least 1.0.9.
Back-office features reach the server
Thelia uses Smarty templates for messages in 2.6.0. In the record for CVE-2026-103528, CERT/CC describes an authenticated administrator editing an email template through the messages configuration interface. When the template is previewed or rendered, unrestricted PHP functions can run with the web process’s privileges. A feature meant to format mail can therefore read or write server files and execute commands.
File management opens other routes. CERT/CC says the document upload endpoint in 2.6.0 rejects executable file types, while the document update endpoint lacks the same validation. An administrator with access to that workflow can upload an executable file, according to the CVE-2026-103521 record. The store banner upload relies on a client-supplied MIME type (CVE-2026-103522). Module installation also runs embedded PHP during installation (CVE-2026-103529). These are distinct routes with the same severe destination: code running as the web server.
The reported 2.6.1 issues involve a different part of the admin surface. For CVE-2026-103535, a user with UPDATE permission on admin.configuration.language can make the translation editor write outside templates/; the writing logic also permits PHP injection into the resulting file. The two flaws together allow code execution from a web-accessible file. CVE-2026-103537 permits an authorized user to supply an absolute template path that Smarty loads and compiles. The code-execution outcome there depends on the server’s filesystem layout and deployment configuration.
Browser and login risks remain
The same CERT/CC note describes stored script injection through category and product administration (CVE-2026-103524) and reflected script injection in address templates (CVE-2026-103527). Those paths can put an administrator’s browser session at risk. A redirect in the address-creation workflow (CVE-2026-103523) can send a shopper who submits the address form to an attacker-chosen site. Different responses from the admin login and password-reset endpoints reveal valid usernames (CVE-2026-103526); repeated attempts face no rate limit at those endpoints, according to CERT/CC.
Twig fix applies to 3.0.0
A user with the “Messages” permission can supply unsandboxed Twig templates in the back-office Email/Messages feature, according to the CVE record for CVE-2026-107248. Compiling the modified content can execute PHP functions, read sensitive files and potentially write files. The record names thelia/twig-engine-module 1.0.9 as the fix for this path. Keep this module-specific repair separate from the 2.6 work while making the version inventory.
Restrict access while fixes develop
For 2.6.0 and 2.6.1 stores, CERT/CC recommends restricting access to Thelia administration, disabling or tightly limiting file upload and template editing, and removing PHP execution permission from user-writable directories wherever possible. CERT/CC says it could not coordinate with Thelia and lists the vendor status as unknown. Treat the admin site’s network reachability and user permissions as live risk controls while tracking a verified vendor remedy.
Start by listing the store’s installed Thelia version and, for 3.0.0, its installed thelia/twig-engine-module version. Put the administrative interface behind a trusted management access path, and limit the accounts that can install modules, update documents, edit translations or edit message templates. Review admin account permissions against those workflows. At the reverse proxy, apply rate limits to the administrative login and forgotten-password endpoints; CERT/CC also recommends MIME filtering and URL allowlisting to reduce exposure. Those proxy settings are additional barriers, especially when application-side file checks differ between endpoints.
For a store where untrusted users may have reached the back office, inspect administrative sign-ins, document and banner changes, module installs, translation edits and message-template changes against the period of exposure. Look for unexpected PHP files in web-accessible or user-writable directories, then investigate any match as a possible compromise. If relevant logs were unavailable, keep the store in incident review rather than clearing it on a clean file search. Finally, verify from an untrusted network that the admin interface is inaccessible, check the actual account permissions and PHP execution policy, and confirm 1.0.9 or later is installed where the 3.0.0 Twig module is used. Keep the 2.6 restrictions in place until a supported fix is verified on the running store.