Stirling-PDF CVE-2026-85714

Requires all of the following: (1) an authenticated administrator account; (2) the application running on its DEFAULT H2 database backend; (3) 'security mode' enabled; and (4) the ability to reach POST /api/v1/database/import-database to upload a crafted SQL file processed by RUNSCRIPT. Limiting factors that reduce real-world exposure: instances configured with an external database (e.g. PostgreSQL) instead of H2 are not affected, and the attacker must already hold administrative privileges, so this is a configuration-and-privilege-gated flaw rather than a default-config unauthenticated exploit.

The CVSS 3.1 base score of 9.1 (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) is driven by network reachability, low complexity, no user interaction, a scope change, and full CIA impact - but the single most important mitigating signal is PR:H: exploitation requires an authenticated administrator. This is therefore not an unauthenticated internet-facing RCE but a privilege-escalation/post-authentication issue where an existing admin breaks out of the application to OS command execution as the JVM service account. No EPSS score was supplied, the CVE is not listed in CISA KEV, and no public exploit was provided in the input, so exploitation status is 'no public exploit identified at time of analysis.' Real-world urgency is further constrained by configuration dependency: it only applies to the default H2 database backend with 'security mode,' so deployments using an external database (e.g. PostgreSQL) are not in scope. Net assessment: a genuine high-severity flaw worth patching promptly for H2-backed instances, but materially lower real-world risk than the 9.1 headline implies because it presupposes administrative access and a specific default configuration rather than anonymous exploitation.

An authenticated Stirling-PDF administrator (or an attacker who has already obtained admin credentials) on a default H2-database instance uploads a crafted SQL file to POST /api/v1/database/import-database. Because DatabaseService.validateSqlContent() only checks that each semicolon-split statement contains an allowed keyword, the attacker smuggles dangerous H2 functions (FILE_READ, CSVWRITE, CREATE ALIAS) past the whitelist, which RUNSCRIPT then executes to read/write files and ultimately chain into OS command execution. No public proof-of-concept was provided in the input, though the advisory describes a working command-execution chain.