Summary
Stirling-PDF contains an SQL validation weakness in its database import endpoint that can allow an authenticated administrator to upload crafted SQL containing dangerous H2 functions or aliases. When the imported script is processed, the attacker may gain arbitrary file access and potentially execute operating-system commands as the application service account.
Stirling-PDF contains an SQL validation weakness in its database import endpoint that can allow an authenticated administrator to upload crafted SQL containing dangerous H2 functions or aliases. When the imported script is processed, the attacker may gain arbitrary file access and potentially execute operating-system commands as the application service account.
Affected context
The issue occurs in Stirling-PDF deployments using the default H2 database and security mode, where an authenticated administrator can access the database import API. Risk arises when uploaded SQL is validated using an insufficient keyword allowlist before H2 processes it with RUNSCRIPT, permitting statements with file or code-execution side effects.
The issue occurs in Stirling-PDF deployments using the default H2 database and security mode, where an authenticated administrator can access the database import API. Risk arises when uploaded SQL is validated using an insufficient keyword allowlist before H2 processes it with RUNSCRIPT, permitting statements with file or code-execution side effects.
Exploit preconditions
- Attack surface: The authenticated database import HTTP endpoint
- Required access: An authenticated account with administrator privileges and permission to import database content
- Trigger point: Processing an uploaded SQL file through the database import workflow
- Deployment condition: Use of the affected H2 database and security configuration
- Why exploitation is possible: Validation accepts statements containing an allowed keyword without reliably rejecting dangerous H2 functions, aliases, or other side-effecting SQL constructs
- Attack surface: The authenticated database import HTTP endpoint
- Required access: An authenticated account with administrator privileges and permission to import database content
- Trigger point: Processing an uploaded SQL file through the database import workflow
- Deployment condition: Use of the affected H2 database and security configuration
- Why exploitation is possible: Validation accepts statements containing an allowed keyword without reliably rejecting dangerous H2 functions, aliases, or other side-effecting SQL constructs
Why this happens
The underlying flaw is insufficient validation of semi-structured SQL input. The validation logic normalizes and splits content on semicolons, then accepts statements when they contain any permitted keyword, rather than parsing SQL safely and enforcing an explicit, context-aware grammar.
This insecure allowlist pattern allows dangerous H2 capabilities, including file-access functions and alias creation, to pass validation before RUNSCRIPT evaluates the imported content. The resulting behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled database content can influence the creation or execution of code-like behavior.
The underlying flaw is insufficient validation of semi-structured SQL input. The validation logic normalizes and splits content on semicolons, then accepts statements when they contain any permitted keyword, rather than parsing SQL safely and enforcing an explicit, context-aware grammar.
This insecure allowlist pattern allows dangerous H2 capabilities, including file-access functions and alias creation, to pass validation before RUNSCRIPT evaluates the imported content. The resulting behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-controlled database content can influence the creation or execution of code-like behavior.
Potential impact
- Arbitrary local file reads or writes may be possible
- Application configuration or startup files could be modified
- Commands may execute with the privileges of the JVM service account
- Sensitive data and credentials may be exposed
- The application host could be compromised
- Persistence or lateral movement could follow, depending on service permissions
- Arbitrary local file reads or writes may be possible
- Application configuration or startup files could be modified
- Commands may execute with the privileges of the JVM service account
- Sensitive data and credentials may be exposed
- The application host could be compromised
- Persistence or lateral movement could follow, depending on service permissions
General mitigation guidance
Mitigation focuses on removing executable behavior from database import workflows and reducing trust in uploaded SQL content.
Common defensive patterns include:
- Replacing keyword-based filtering with a narrowly defined, parser-backed import format
- Allowing only explicitly supported schema and data operations
- Rejecting H2 functions, aliases, script commands, file operations, and other side-effecting constructs by default
- Separating data import from database administration and code-generation capabilities
- Enforcing strong authorization and multifactor protection for administrative import functions
- Running the application with a dedicated, least-privileged service account
- Restricting filesystem access and preventing writes to executable or startup locations
- Applying secure-by-default database and application configurations
- Preserving validation and authorization checks throughout the import pipeline rather than relying on a single filter
Mitigation focuses on removing executable behavior from database import workflows and reducing trust in uploaded SQL content.
Common defensive patterns include:
- Replacing keyword-based filtering with a narrowly defined, parser-backed import format
- Allowing only explicitly supported schema and data operations
- Rejecting H2 functions, aliases, script commands, file operations, and other side-effecting constructs by default
- Separating data import from database administration and code-generation capabilities
- Enforcing strong authorization and multifactor protection for administrative import functions
- Running the application with a dedicated, least-privileged service account
- Restricting filesystem access and preventing writes to executable or startup locations
- Applying secure-by-default database and application configurations
- Preserving validation and authorization checks throughout the import pipeline rather than relying on a single filter
How teams detect issues like this
Detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis rules to identify SQL allowlists based on substring or keyword matching
- Review code paths that pass uploaded content to H2 RUNSCRIPT or equivalent script execution APIs
- Flag database import functionality that permits CREATE ALIAS, file functions, or dynamic code generation
- Monitor administrative import requests, unusual SQL uploads, and database errors involving file or alias operations
- Alert on unexpected writes by the JVM service account to configuration, startup, or user-site directories
- Enforce CI policies that prohibit unsafe database script execution and require parser-backed validation
- Neutral automated code-review tools may help identify dangerous SQL execution and insufficient input validation patterns
Detection can combine source review, runtime monitoring, and policy enforcement:
- Use static analysis rules to identify SQL allowlists based on substring or keyword matching
- Review code paths that pass uploaded content to H2 RUNSCRIPT or equivalent script execution APIs
- Flag database import functionality that permits CREATE ALIAS, file functions, or dynamic code generation
- Monitor administrative import requests, unusual SQL uploads, and database errors involving file or alias operations
- Alert on unexpected writes by the JVM service account to configuration, startup, or user-site directories
- Enforce CI policies that prohibit unsafe database script execution and require parser-backed validation
- Neutral automated code-review tools may help identify dangerous SQL execution and insufficient input validation patterns
