CVE-2026-57485: Stirling-PDF Auth Bypass Vulnerability

CVE-2026-57485 Overview

CVE-2026-57485 is an information disclosure vulnerability in Stirling-PDF, a locally hosted web application for PDF file operations. The flaw resides in the /api/v1/pipeline/handleData endpoint within PipelineProcessor.java. Prior to version 2.9.0, this endpoint injects the STIRLING-PDF-BACKEND-API-USER API key into pipeline subrequests. An authenticated ROLE_USER can retrieve the key through /api/v1/user/get-api-key, then impersonate the internal service account. The issue is tracked under [CWE-200] and fixed in Stirling-PDF 2.9.0.

Critical Impact
Authenticated low-privilege users can extract the internal backend API key, bypass rate limits, and access privileged endpoints including /api/v1/info/requests/all and /api/v1/info/load/all.

Affected Products

Stirling-PDF versions prior to 2.9.0
app/core/src/main/java/stirling/software/SPDF/controller/api/pipeline/PipelineProcessor.java
Deployments exposing /api/v1/pipeline/handleData to authenticated users

Discovery Timeline

2026-08-17 - CVE-2026-57485 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-57485

Vulnerability Analysis

Stirling-PDF exposes a pipeline endpoint that orchestrates multi-step PDF operations by issuing internal subrequests. To authenticate these subrequests, PipelineProcessor.java attaches the backend service account API key (STIRLING-PDF-BACKEND-API-USER) to outbound calls. The problem is that this internal key is retrievable through the standard user API key endpoint. Any authenticated user holding ROLE_USER can call /api/v1/user/get-api-key and receive the service account credential.

Once obtained, the attacker impersonates the internal service account. This unlocks endpoints intended for backend use only and bypasses rate-limiting controls tied to normal user roles. Reachable endpoints include /api/v1/info/requests/all and /api/v1/info/load/all, exposing request telemetry and load information across all users.

Root Cause

The root cause is a privilege boundary violation. The pipeline processor treats a service account credential as user-scoped data by injecting it into a context that user-facing APIs can read. There is no separation between the credential used to authenticate internal subrequests and the credential returned to the requesting user through get-api-key.

Attack Vector

Exploitation requires network access and valid ROLE_USER credentials. No user interaction is needed. The attacker authenticates, triggers a pipeline call to /api/v1/pipeline/handleData, then queries /api/v1/user/get-api-key to harvest the injected backend key. With the key in hand, the attacker issues authenticated requests as the internal service account.

java

// Patch: PipelineProcessor.java (v2.9.0)
// Removed import indicates refactored role/credential handling
 import stirling.software.SPDF.model.PipelineOperation;
 import stirling.software.SPDF.model.PipelineResult;
 import stirling.software.SPDF.service.ApiDocService;
-import stirling.software.common.model.enumeration.Role;
 import stirling.software.common.service.UserServiceInterface;

// UserServiceInterface.java (v2.9.0)
// New method separates current-user API key retrieval
     String getCurrentUsername();
+    String getCurrentUserApiKey();
     long getTotalUsersCount();

Source: GitHub Commit de96259

Detection Methods for CVE-2026-57485

Indicators of Compromise

Unexpected calls to /api/v1/user/get-api-key immediately following /api/v1/pipeline/handleData requests from the same session
Requests to /api/v1/info/requests/all or /api/v1/info/load/all originating from ROLE_USER accounts
API traffic authenticated with the STIRLING-PDF-BACKEND-API-USER key from external client IPs

Detection Strategies

Correlate authentication events with role assignments to identify user sessions issuing service-account-scoped requests
Alert on any usage of the backend service account key from source addresses that are not the Stirling-PDF host itself
Baseline normal pipeline usage patterns and flag sequential access to pipeline plus get-api-key endpoints

Monitoring Recommendations

Enable verbose HTTP access logging on the Stirling-PDF reverse proxy and forward logs to a central analytics platform
Track per-user request rates against /api/v1/info/* endpoints and alert on any non-admin access
Retain audit trails for all API key retrieval operations for post-incident review

How to Mitigate CVE-2026-57485

Immediate Actions Required

Upgrade Stirling-PDF to version 2.9.0 or later without delay
Rotate the STIRLING-PDF-BACKEND-API-USER API key and any user API keys issued while the vulnerable version was in use
Review access logs for prior invocations of /api/v1/info/requests/all and /api/v1/info/load/all by non-administrative users

Patch Information

The fix is included in Stirling-PDF v2.9.0, delivered via Pull Request #6047 and commit de96259. The patch refactors PipelineProcessor.java and introduces getCurrentUserApiKey() in UserServiceInterface so that pipeline subrequests no longer leak the backend service account credential. See the GitHub Security Advisory GHSA-3xxh-mm3g-c9w5 for the full disclosure.

Workarounds

Restrict access to /api/v1/pipeline/handleData at the reverse proxy layer until the upgrade is applied
Block external access to /api/v1/info/requests/all and /api/v1/info/load/all via web server ACLs
Limit account creation and enforce strong authentication to reduce the pool of accounts able to reach the vulnerable endpoint

bash

# Example NGINX restriction until patching completes
location ~ ^/api/v1/(pipeline/handleData|info/(requests|load)/all)$ {
    allow 10.0.0.0/8;      # internal management network only
    deny all;
    proxy_pass http://stirling_pdf_upstream;
}