Description

Stirling-PDF is a locally hosted web application that facilitates various operations on PDF files. Prior to 2.13.2, an authenticated administrator using the default H2 database and security mode can upload a crafted SQL file to POST /api/v1/database/import-database. DatabaseService.validateSqlContent() splits normalized input on semicolons and accepts a statement when it contains any allowed keyword, allowing dangerous H2 functions such as FILE_READ and CSVWRITE, plus CREATE ALIAS, to bypass the insufficient whitelist and execute side effects when RUNSCRIPT processes the file. This permits arbitrary file access. The demonstrated operating-system command execution chain writes attacker-controlled startup files to a user-site location and then triggers an application Python interpreter configured to load those startup files, resulting in command execution as the JVM service account. This issue is fixed in version 2.13.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.1",
  "pubDate": "2026-10-14T19:17:22.050Z",
  "pubdate": "2026-10-14T19:17:22.050Z",
  "executiveSummary": "Stirling-PDF versions prior to 2.13.2 are susceptible to an Arbitrary Command Execution vulnerability via the database import functionality.\nThe flaw exists in the DatabaseService.validateSqlContent() method, which fails to properly sanitize SQL input handled by the H2 database engine.\nAn authenticated administrator can exploit this by uploading a crafted SQL file to /api/v1/database/import-database.\nBy bypassing the insufficient keyword whitelist, an attacker can invoke dangerous H2 functions, including FILE_READ, CSVWRITE, and CREATE ALIAS.\nSuccessful exploitation allows for arbitrary file system access and OS-level command execution running under the privileges of the JVM service account.\nThe vulnerability poses a critical risk to confidentiality, integrity, and availability, as it enables full compromise of the application environment.\nExploitation requires administrative-level authentication within the application, making the impact severe in environments where administrative credentials are compromised.",
  "technicalDetails": "The vulnerability originates in the DatabaseService.validateSqlContent() function within Stirling-PDF, which is responsible for processing imported SQL files in the H2 database environment. The validation logic relies on a flawed whitelist approach that fails to adequately restrict the execution of privileged H2 database functions.\nWhen a user invokes the POST /api/v1/database/import-database endpoint, the application passes the provided SQL content to the validator. The validator splits the input into individual statements based on semicolons. However, the implemented check only confirms the presence of an allowed keyword rather than enforcing a strict command blocklist or validating the safety of the entire statement structure.\nThis design flaw allows an attacker to inject malicious SQL commands alongside authorized keywords. Specifically, the H2 database engine supports functions that interact directly with the operating system, such as FILE_READ, CSVWRITE, and CREATE ALIAS. These functions are permitted because the validation logic does not properly isolate or sanitize the full command string.\nThe exploitation flow proceeds as follows: 1) The attacker crafts a malicious SQL script containing H2 functions designed to facilitate file system interaction. 2) The script is submitted to the /api/v1/database/import-database endpoint. 3) The validation logic erroneously approves the content due to the presence of whitelisted keywords. 4) The RUNSCRIPT command processes the payload, executing the unintended H2 functions.\nTo achieve remote code execution, the attacker leverages these primitives to write attacker-controlled content into startup files located in a user-site directory. Because the application utilizes a Python interpreter configured to load startup files, the attacker can influence the execution environment of the interpreter. By populating these files with arbitrary code, the attacker ensures that the Python interpreter executes the payload upon initialization.\nConsequently, the attacker gains the ability to execute OS-level commands with the privileges of the underlying JVM service account. This bypasses application-level security controls and grants the attacker full control over the application's runtime environment, leading to potential data exfiltration, service disruption, or further lateral movement within the infrastructure."
}