CVE-2026-107188 in Archibus
Summary
by MITRE • 10/19/2026
A user can upload export reports with any file contents and specify any contents. JSP code can be uploaded, JSPX can be specified as the file extension, and anyone can browse to the uploaded file, leading to command execution. The authentication bypass vulnerability can be chained with this vulnerability to run code on the server without authentication.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The described vulnerability represents a critical security flaw centered around insecure direct object references and improper input validation within an application's report export functionality. At its core, the issue stems from the system allowing users to upload files that are subsequently stored in accessible directories with minimal or no restriction on file types or content verification. This lack of sanitization permits attackers to bypass standard filtering mechanisms by specifying extensions such as JSPX, which are interpreted by Java-based web servers like Apache Tomcat as executable script pages rather than static data files. When a user uploads a crafted payload containing malicious JSP code and names the file with an allowed extension, the server stores this content in a location that is directly accessible via HTTP requests.
This architectural weakness facilitates arbitrary remote code execution because the uploaded file becomes part of the application's executable context. Once the attacker identifies or guesses the path to the stored report, they can issue an HTTP GET request to trigger the JSP engine to parse and execute the embedded commands. This transforms a simple data upload feature into a full system compromise vector. The ability to specify arbitrary contents means that attackers are not limited to predefined payloads; they can inject complex logic, including reverse shells or command-line invocations, effectively gaining control over the underlying operating system processes running the web application.
The severity of this vulnerability is significantly amplified by its potential interaction with authentication bypass flaws within the same ecosystem. While file upload vulnerabilities often require some level of user access to exploit in well-configured environments, the presence of an associated authentication bypass allows unauthenticated actors to initiate the upload process entirely from outside the trusted boundary. By chaining these two distinct weaknesses, an attacker can achieve complete remote code execution without valid credentials. This combination negates the primary defense mechanism of identity verification, turning a potentially restricted administrative feature into an open entry point for external adversaries.
From a classification perspective, this vulnerability aligns with CWE-434, which covers the unrestricted upload of files with dangerous types, and CWE-94, describing code injection flaws where user input is executed as code without proper validation. In terms of offensive security frameworks such as MITRE ATT&CK, this scenario maps directly to T1505.003, known as Server Side Web Application Components, where attackers install web shells or backdoors via uploaded files. It also relates to T1059, Command and Scripting Interpreter, specifically when the JSP code invokes system commands through standard Java libraries like Runtime.exec().
Mitigation strategies must address both the input validation layer and the server configuration settings. First, developers should implement strict allow-lists for file extensions rather than relying on block lists or extension checks alone. The application should validate not just the filename but also the actual content of the uploaded files using magic numbers or MIME type verification to ensure they match expected data formats like PDF or CSV. Furthermore, uploaded files must be stored in a directory that is outside the web root and lacks execution permissions for scripts. If storage within the web root is unavoidable, server configuration should explicitly disable script interpretation for specific directories containing user uploads. Additionally, enforcing robust authentication checks before allowing any upload operations will prevent unauthenticated exploitation of this flaw.