The core vulnerability in CVE-2026-57485 isn't simply that an API key was exposed—it's that Stirling-PDF maintained a privileged internal service account (STIRLING-PDF-BACKEND-API-USER) whose credential was retrievable through the normal user-facing API endpoint /api/v1/user/get-api-key. This represents a fundamental trust boundary failure: internal service accounts exist precisely because their credentials should never be accessible through the application surface. By collapsing this boundary, any authenticated user could retrieve credentials that carried internal service privileges.
The exposed endpoint granted access beyond what typical users have—rate-limit bypass and visibility into monitoring endpoints like /api/v1/info/requests/all and /api/v1/info/load/all. That monitoring access creates a reconnaissance advantage: an attacker can observe which operations trigger expensive processing, external calls, or audit events, enabling precision targeting rather than noisy probing.
The critical gap in assessing whether version 2.9.0 fully remediated this: was the STIRLING-PDF-BACKEND-API-USER credential rotated, or was access to it merely restricted? Static API keys don't become invalid when you stop returning them—they remain functional until deliberately rotated. If the fix only gated /api/v1/user/get-api-key without rotating the credential, anyone who extracted the key before patching still holds a valid internal credential. The burden of proof for complete remediation requires key rotation, not just endpoint restriction.
The deeper architectural issue: the codebase lacked a data model distinguishing service keys from user keys at the schema level. The retrieval endpoint treated all credentials as equivalent. If the fix only restricts this specific credential rather than correcting the underlying data model, other credentials could still traverse the same exposure path.
What you should check: Confirm with maintainers whether the backend service credential was rotated in 2.9.0. Audit whether the STIRLING-PDF-BACKEND-API-USER account accumulated permissions beyond its original pipeline function—internal service accounts often quietly gain cross-cutting access. Review logs from the vulnerable window for any access to /api/v1/user/get-api-key that might indicate pre-patch extraction. Treat the fix as partial until rotation is confirmed.