CVE-2026-113605 in Stirling-PDF
Summary
by MITRE • 10/20/2026
Stirling-PDF from 2.13.2 through 3.2.0 contains an incomplete denylist in DatabaseService.validateSqlContent() that allows administrators to bypass H2 import restrictions using CREATE OR REPLACE ALIAS. Authenticated administrators can upload a crafted SQL backup to the import-database endpoint, where RUNSCRIPT defines H2 Java function aliases and restores Java-method execution.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Stirling-PDF versions 2.13.2 through 3.2.0 represents a critical security flaw rooted in an incomplete denylist within the DatabaseService.validateSqlContent() method. This architectural weakness allows authenticated administrators to bypass intended H2 database import restrictions by exploiting specific SQL syntax features, namely CREATE OR REPLACE ALIAS. The core of the issue lies in the validation logic which fails to adequately sanitize or restrict certain commands that can be used to define aliases for Java methods within the H2 database engine. By uploading a crafted SQL backup file through the import-database endpoint, an attacker with administrative privileges can inject code that defines these aliases, effectively bridging the gap between the database layer and the underlying Java runtime environment.
From a technical perspective, this flaw leverages the RUNSCRIPT command in conjunction with CREATE OR REPLACE ALIAS to execute arbitrary Java methods. The H2 database engine allows for the creation of SQL function aliases that map directly to static Java methods. When an administrator imports a maliciously crafted backup file containing these definitions, the system processes them without sufficient scrutiny. This results in the execution of potentially dangerous Java code during the import process. Because the vulnerability requires authentication and administrative privileges, it is classified as an issue with insufficient access control or privilege escalation within the application's database management features. The attacker does not need to exploit a remote code execution flaw directly but rather abuses the trusted relationship between the administrator role and the system's ability to execute complex SQL operations that interact deeply with the JVM.
The operational impact of this vulnerability is severe, as it effectively leads to Remote Code Execution (RCE) under specific conditions. Once an attacker successfully imports the crafted backup file, they can trigger the execution of arbitrary Java code by invoking the newly created aliases from within subsequent SQL queries or administrative actions that interact with the database. This capability allows for a wide range of malicious activities, including data exfiltration, modification of system configurations, installation of backdoors, or complete compromise of the server hosting Stirling-PDF. The ability to execute Java methods means that an attacker can leverage standard Java libraries to perform file operations, network requests, and other actions typically reserved for higher-level application logic, thereby undermining the security boundaries established by the web application framework.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection), specifically where user input or uploaded content is used to construct executable code without proper validation. It also relates to CWE-78 Improper Neutralization of Special Elements used in an OS Command, as the SQL commands are processed by a database engine that supports external function integration. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1059 Command and Scripting Interpreter, where attackers use scripting languages like Java via the H2 alias mechanism to execute commands on the target system. It also touches upon T1136 Create Account if the attacker uses the execution capability to create new administrative users for persistent access.
Mitigation strategies should focus on immediate patching of Stirling-PDF to a version that addresses this validation flaw, ensuring that the denylist in DatabaseService.validateSqlContent() is comprehensive and includes restrictions on CREATE OR REPLACE ALIAS statements. In addition to software updates, administrators should enforce strict input validation for all SQL imports, potentially by whitelisting only known safe commands rather than relying solely on blacklists which are prone to omissions like this one. Implementing principle of least privilege is also critical; administrative access to the import-database endpoint should be restricted to essential personnel and monitored closely. Furthermore, deploying Web Application Firewalls (WAFs) with rules specifically targeting H2-specific injection patterns can provide an additional layer of defense against exploitation attempts while patching efforts are underway. Regular security audits of database interaction layers and code reviews focusing on SQL parsing logic will help prevent similar vulnerabilities in the future.