CVE-2026-108113 in ILIAS
Summary
by MITRE • 10/09/2026
ILIAS before 9.24, 10.12, and 11.5 contains an unrestricted file upload vulnerability in QTI question import image handling (ilQtiMatImageSecurity) that allows authenticated authors to write executable files. Attackers with question pool import rights can import a crafted archive writing a .htaccess and PHP file to the web-served image directory, achieving remote code execution as the web server user.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in ILIAS versions prior to 9.24, 10.12, and 11.5 represents a critical security flaw within the Question Test Interface module's handling of imported question archives. Specifically, the function ilQtiMatImageSecurity fails to adequately sanitize or validate file names during the extraction process of QTI (Question and Test Interoperability) packages. This lack of rigorous input validation allows an authenticated user with permissions to import questions from a pool to manipulate the filesystem structure within the application's web-accessible directories. The core technical failure lies in the insufficient filtering of archive contents, which permits the inclusion of files that are not strictly images but rather executable scripts or configuration directives intended for the underlying web server software.
By exploiting this unrestricted file upload mechanism, an attacker can craft a malicious QTI archive containing specially named files such as .htaccess and PHP script files. When the system processes this archive, it extracts these files into the image directory without verifying their content type or extension against a strict allowlist of safe image formats like JPEG, PNG, or GIF. The inclusion of an .htaccess file is particularly dangerous because Apache web servers interpret directives within this configuration file to alter server behavior for that specific directory and its subdirectories. By setting appropriate handlers in the .htaccess file, the attacker can instruct the web server to treat PHP files as executable scripts rather than plain text or static content.
The operational impact of this vulnerability is severe, resulting in Remote Code Execution with the privileges of the web server process. Once the malicious .htaccess and PHP payload are successfully written to the image directory, any subsequent request that triggers the execution of these files allows the attacker to run arbitrary code on the host system. This level of access typically grants control over the underlying operating system, enabling data exfiltration, installation of backdoors, lateral movement within the network, or complete compromise of the ILIAS instance and potentially other services running under the same user context. The attack vector requires authentication but leverages a relatively low-privilege role (question pool import rights), making it accessible to a broader range of potential adversaries who may have compromised legitimate academic accounts.
From a classification perspective, this vulnerability aligns with CWE-434, which describes the unrestricted upload of files with dangerous types, and CWE-94, involving improper control of generation of code or commands. In terms of offensive security frameworks, it maps to MITRE ATT&CK technique T1505.003, known as Web Shell: ASPX, PHP, JSP, or CGI, where attackers deploy web shells for persistent access and command execution. The exploitation also relates to CWE-79, the improper neutralization of input during web page generation, although the primary failure is in file handling rather than direct output encoding.
Mitigation strategies must focus on immediate patching and rigorous configuration hardening. Administrators should upgrade ILIAS to version 9.24 or later for legacy systems, or versions 10.12 and 11.5+ for newer deployments, as these releases contain fixes that enforce stricter validation of uploaded file types and names during the QTI import process. In environments where immediate patching is not feasible, implementing a Web Application Firewall rule to block requests containing suspicious patterns in upload parameters or restricting write permissions on image directories can provide temporary relief. Additionally, configuring the web server to ignore .htaccess files via AllowOverride None directives for specific directories adds an essential layer of defense against this type of configuration-based exploitation. Regular audits of uploaded content and enforcing strict MIME-type verification at both the application and infrastructure levels are critical preventive measures against similar unrestricted upload vulnerabilities.