News, updates, trends and the latest
info you need to know about IT

Overview
Thelia versions 2.6.0 and 2.6.1 contain multiple vulnerabilities relating to file management, Smarty templating, module installation, and administrative workflows. Successful exploitation of these issues could enable remote code execution (RCE), server-side template injection (SSTI), stored and reflected cross-site scripting (XSS), unauthorized URL redirection, and other risks that expose both server-side and client-side attack surfaces.
Description
Thelia is an open-source e-commerce platform designed to provide merchants with customizable online storefronts, product management workflows, and administrative functionalities. It utilizes the Smarty template engine and provides administrators with broad control over templates, content, and modules.
CVE-2026-103521 In Thelia v2.6.0, the document upload endpoint properly blocks the upload of executable file types, but the document update endpoint does not perform the same validation. An attacker with administrative Thelia permissions can exploit this vulnerability to upload arbitrary executable files, such as malicious PHP scripts, to achieve remote code execution on the underlying server.
CVE-2026-103522 In Thelia v2.6.0, the store banner upload feature performs insufficient filetype validation that relies exclusively on client-supplied MIME types. An attacker with administrative access can upload a PHP file disguised as an image to bypass validation and achieve remote code execution on the underlying server.
CVE-2026-103523 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.
CVE-2026-103524 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.
CVE-2026-103526 In Thelia v2.6.0, both the administrative login and forgotten password endpoints return different responses for invalid usernames and incorrect passwords, allowing unauthenticated attackers to enumerate valid administrator accounts. Because the endpoint also lacks rate limiting or other protections against repeated authentication attempts, username enumeration can be performed efficiently at scale.
CVE-2026-103527 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 XSS when an authenticated user visits the malicious link containing attacker‑controlled JavaScript.
CVE-2026-103528 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 server.
CVE-2026-103529 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.
CVE-2026-103535 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, used to build the translation file’s write path, does not sanitize directory traversal sequences such as ../, allowing an authenticated user with UPDATE-level permission on admin.configuration.language to write files outside templates/, including to web-accessible directories. Separately, the translation-writing logic does not escape in user-supplied values, allowing input to break out of the PHP string literal and inject executable code into the translation file. Chained together, these flaws allow a malicious PHP file to be written to a web-accessible path and executed with the web server’s privileges.
CVE-2026-103537 Thelia v2.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 such as ../ 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 that file can be executed with the web server’s privileges.
Impact
Several of these vulnerabilities allow authenticated administrative users to achieve arbitrary code execution on the host server. These include insufficient file validation and unsafe upload/update workflows (CVE-2026-103521 and CVE-2026-103522), unrestricted execution of PHP code during module installation (CVE-2026-103529), unsafe template evaluation for email content (CVE-2026-103528), server side template injection via absolute paths (CVE-2026-103537), and flaws in the translation writing process that permit path traversal and PHP injection (CVE-2026-103535). Exploitation of any of these issues can result in complete compromise of the underlying application environment with the privileges of the web server.
Separately, user-supplied content rendered within administrative templates enables stored and reflected XSS. CVE-2026-103524 allows persistent JavaScript execution within the admin interface, while CVE-2026-103527 enables reflected JavaScript injection via unescaped template parameters. These vulnerabilities allow attackers to hijack administrative sessions and perform privileged actions in the browser context of other authenticated users.
The discrepancies in authentication error-handling identified in CVE-2026-103526 allow unauthenticated attackers to easily enumerate valid administrative usernames, increasing the risk and effectiveness of subsequent brute-forcing or authentication-related attacks.
Finally, the open redirect described in CVE-2026-103523 allows attackers to redirect users to external attacker-controlled websites, increasing the effectiveness of phishing or other downstream attacks.
Together, these vulnerabilities facilitate full server takeover for authenticated administrative attackers, and expose avenues for browser-based compromise or credential attacks to both authenticated and unauthenticated attackers.
Solution
Unfortunately, we were unable to coordinate these vulnerabilities with Thelia, and a patch is not yet available. To reduce risk until these issues are remediated, users and organizations should restrict access to Thelia administrative interfaces, disable or tightly limit file-upload and template-editing features, and remove PHP execution permissions from user-writable directories wherever possible. Applying strict reverse-proxy controls such as rate limiting, MIME filtering, and URL allowlisting can further reduce exposure.
Acknowledgements
Thanks to the reporters K08UK0VU, s-b321, DuanNH, Deflask13, LongNBH, and NNPhong (pnn219) from ETC JSC security team for researching and reporting these vulnerabilities. This document was written by Molly Jaconski.

Overview
An Out-of-bounds Write vulnerability in the InsydeH2O IHISI software used by HP PC BIOS can allow a local attacker with OS kernel privileges to perform arbitrary physical memory writes, including writes to System Management RAM (SMRAM). Because the vulnerable code executes in System Management Mode (SMM), successful exploitation can allow an attacker to modify SMM-protected memory and potentially achieve arbitrary code execution in SMM. Depending on the platform’s memory and firmware configuration, the arbitrary physical memory write primitive may also have implications for UEFI firmware update or flash-related operations.
Description
HP PC BIOS is firmware that initializes and manages hardware components during the boot process and provides runtime services to the operating system and provide the ability to update firmware. The affected system uses InsydeH2O Kernel version 5.5 or earlier. The BIOS includes custom HP SMM handlers that execute in System Management Mode (SMM), a highly privileged CPU execution mode that is isolated from the operating system.
CVE-2026-12855: An Out-of-bounds Write vulnerability in the H19WMIHandlerSmm module (GUID f1946499-571b-44c3-9b9c-cc55210b0c02) allows a local attacker with OS kernel privileges to read or write arbitrary physical memory, including SMRAM, through a Software SMI handler.
An attacker with kernel-level privileges can trigger the vulnerable SMM handler by issuing a Software System Management Interrupt (SMI) through I/O port 0xB2 and supplying specially crafted CPU register values. The vulnerable handler does not adequately validate the supplied parameters before performing memory operations, allowing the attacker to influence the physical address and data involved in the operation.
Because the affected handler executes in SMM, the resulting arbitrary physical memory write can target memory regions that are normally inaccessible to software executing outside SMM, including SMRAM. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution in SMM. The ability to affect firmware or ROM contents is platform-dependent and is not assumed as a direct consequence of this vulnerability.
Impact
An attacker with privileged OS kernel access (ring 0) can exploit the vulnerability by raising Software SMI interrupts through I/O port 0xB2 with crafted CPU register values. Modifying SMM code or data may allow an attacker to alter subsequent SMM execution and potentially achieve arbitrary code execution and persistence via modifying SMRAM.
Solution
Users should check HP’s security bulletins to determine whether their system is affected. Insyde advisory is available at https://www.insyde.com/security-pledge/sa-2026009/
Acknowledgements
Thank you to Zhenyu Liu for reporting these vulnerabilities. This document was written by Vijay Sarvepalli.

Overview
Authlib (versions up to and including 1.7.2) contain a signature‑verification bypass in the JSON Web Signature (JWS) general JSON serialization handling. The JsonWebSignature.deserialize_json() function accepts a JWS object with an empty “signatures” array and treats the payload as successfully verified, allowing attackers to supply arbitrary forged content without possessing any key material.
Description
Authlib is a Python library that provides tools for implementing OAuth, OpenID Connect, JWT/JWS/JWE (JSON Web Token / JSON Web Signature / JSON Web Encryption), and other modern authentication and authorization standards. It’s widely used in web applications and microservices to handle token creation, cryptographic validation, and secure communication.
As discussed in CVE-2026-96760, a security flaw in Authlib’s handling of JSON Web Signatures (JWS) makes it possible for an attacker to skip signature verification completely. Normally, a JWS should include at least one valid signature to prove the data hasn’t been tampered with. However, Authlib’s deserialize_json() function mistakenly accepts JWS objects even when the “signatures” section is an empty list. Because the function starts by assuming the signatures are valid and never performs any checks when the list is empty, it ends up treating unsigned data as if it were properly signed. This means an attacker could provide a JWS with no signatures, and Authlib would still treat it as trusted. Both ways of loading a JWS in Authlib are affected:
jws.deserialize_json(“payload”:”…”, “signatures”:[], key=None)
jws.deserialize(‘”payload”:”…”,”signatures”:[]’, key=None)
Impact
An attacker can forge arbitrary authenticated payloads without any signing key or credentials. Systems that rely on Authlib’s JWS verification for authentication, authorization, inter-service message integrity, or signed configuration data may accept attacker‑supplied content as legitimate. Potential attack scenarios inlcude the following:
* Authentication bypass: forged identity or privilege‑escalation claims (e.g., sub=admin).
* Signed message injection between microservices using JWS.
* Forged authorization claims such as scopes, roles, or permissions.
* Integrity bypass in systems relying on signed JWS data.
Solution
The vendor could not be reached to coordinate this vulnerability and an official patch has not been made available at the time of this writing. Users are advised to monitor the project’s GitHub repository for updates and install the latest version of this library once a fix has been released.
Acknowledgements
Thank you to Tong Hoang Gia (uziii2208) and Nguyen Minh Tuan (nguyenminhtuan28) for reporting this vulnerability. This document was written by Bob Kemerer.