CVE-2026-57485 in Stirling-PDF
Summary
by MITRE • 08/17/2026
Stirling-PDF is a locally hosted web application that facilitates various operations on PDF files. Prior to 2.9.0, the /api/v1/pipeline/handleData endpoint in app/core/src/main/java/stirling/software/SPDF/controller/api/pipeline/PipelineProcessor.java injects the STIRLING-PDF-BACKEND-API-USER API key into pipeline subrequests, allowing an authenticated ROLE_USER to retrieve the key through /api/v1/user/get-api-key, impersonate the internal service account, bypass normal rate limits, and access internal endpoints including /api/v1/info/requests/all and /api/v1/info/load/all. This issue is fixed in version 2.9.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
Stirling-PDF serves as a locally hosted web application designed to facilitate various operations on PDF files, providing users with tools for manipulation, conversion, and management of document formats. The software architecture relies heavily on internal service communication, where different components interact via API endpoints. A critical security flaw was identified in the pipeline processing logic prior version 2.9.0, specifically within the /api/v1/pipeline/handleData endpoint located in the PipelineProcessor.java file. This vulnerability stems from improper access control and insecure handling of authentication credentials during internal service requests. The application injects a high-privilege API key designated as STIRLING-PDF-BACKEND-API-USER into subrequests made by pipeline operations, intending to authenticate these internal calls against backend services without requiring user interaction.
The core technical flaw lies in the fact that this sensitive administrative credential is accessible through standard user-facing endpoints under certain conditions. An authenticated attacker possessing a basic ROLE_USER privilege level can exploit this misconfiguration by invoking specific API methods such as /api/v1/user/get-api-key to retrieve the internal service account key. This action effectively allows the low-privileged user to escalate their privileges significantly, obtaining credentials that are meant exclusively for backend-to-backend communication. By acquiring the STIRLING-PDF-BACKEND-API-USER key, the attacker can impersonate the internal service account, thereby bypassing standard authentication checks and authorization boundaries designed to protect sensitive application functions.
The operational impact of this vulnerability is severe due to the breadth of access granted by the compromised credentials. Once an attacker possesses the backend API key, they are no longer constrained by the limitations applied to regular user accounts. This includes the ability to bypass normal rate limits that would otherwise throttle excessive requests and prevent abuse or denial-of-service conditions. Furthermore, the attacker gains unrestricted access to internal endpoints that expose sensitive operational data. Specifically, endpoints such as /api/v1/info/requests/all and /api/v1/info/load/all become accessible, allowing the retrieval of detailed information regarding all processed requests and system load metrics. This exposure can lead to significant privacy violations for other users whose documents are being processed, as well as providing intelligence that could facilitate further attacks against the infrastructure hosting Stirling-PDF.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves an actor bypassing intended restrictions on access rights or privileges. It also relates to CWE-798 Use of Hard-coded Credentials if the key is statically defined for internal services and improperly exposed via user-facing APIs. In terms of adversary tactics, this scenario maps to ATT&CK technique T1078 Valid Accounts, where an attacker uses legitimate credentials obtained through exploitation to maintain access or escalate privileges within a system. The ability to bypass rate limits also touches upon aspects of resource exhaustion prevention failures often categorized under CWE-770 Allocation of Resources Without Limits or Throttling.
To mitigate this vulnerability and prevent similar issues in future versions, it is imperative that internal service credentials are never exposed through user-facing API endpoints. Authentication mechanisms for backend services should rely on secure methods such as mutual TLS, shared secrets stored securely outside the application context, or short-lived tokens generated by a dedicated identity provider rather than static keys accessible via standard HTTP requests. Developers must implement strict separation of concerns between public APIs and internal service communication channels, ensuring that sensitive administrative credentials are not serializable or retrievable through general user profile endpoints. Additionally, implementing robust input validation and output encoding for all API responses is essential to prevent information leakage. Organizations running Stirling-PDF should immediately upgrade to version 2.9.0 or later where this issue has been resolved. Until the update is applied, administrators should restrict network access to internal endpoints if possible and monitor logs for unusual patterns of credential retrieval or high-volume requests indicative of exploitation attempts.