Description

SpringBlade versions 2.7.3 through 3.5.0 contain a privilege escalation vulnerability that allows authenticated attackers to create system administrator accounts by sending crafted POST requests to an unprotected internal Feign user-creation endpoint exposed via @RestController without authorization checks. Attackers can exploit the gateway's authentication filter, which only validates JWT parsing without verifying user roles or caller identity, and leverage a hardcoded JWT signing key embedded in publicly available JARs to forge tokens and escalate privileges from a low-privilege user to administrator, enabling cross-tenant data pollution and persistent backdoor access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-28T20:18:30.640Z",
  "pubdate": "2026-08-28T20:18:30.640Z",
  "executiveSummary": "SpringBlade versions 2.7.3 through 3.5.0 contain a critical privilege escalation vulnerability rooted in insecure internal endpoint exposure and improper JWT validation.\nThe vulnerability allows an authenticated attacker to bypass authorization controls, create system administrator accounts, and perform cross-tenant data manipulation.\nThis flaw stems from an unprotected Feign user-creation endpoint exposed via @RestController that lacks necessary authorization checks.\nThe gateway’s authentication filter performs superficial JWT structure validation but fails to verify role-based access control (RBAC) or the caller's identity.\nBy leveraging a hardcoded JWT signing key recovered from public distribution JARs, attackers can forge administrative tokens.\nSuccessful exploitation grants persistent backdoor access and full administrative control over the platform, posing a severe risk to data confidentiality and integrity.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper architectural design of the SpringBlade authentication flow and the exposure of internal Feign client interfaces. The application exposes a user-creation functionality through an @RestController that serves as an internal endpoint intended for microservice-to-microservice communication, yet it remains reachable by external clients through the gateway.\nThe gateway authentication filter exhibits a design flaw where it performs only cursory validation of JWT structure. It parses the token to verify its integrity without enforcing server-side authorization checks or validating the cryptographic signature against a secure, environment-specific secret. Because the JWT signing key is hardcoded and distributed within the application's publicly accessible JAR files, any authenticated user can extract this key to sign arbitrary payloads.\nThe exploitation flow proceeds as follows: First, an attacker obtains a valid session or low-privileged token to interact with the gateway. Second, the attacker utilizes the discovered hardcoded signing key to construct a forged JWT containing administrative claims and elevated role identifiers. Third, the attacker transmits a crafted POST request to the exposed user-creation endpoint. Because the gateway filter only checks for the presence and structural validity of the forged token, it forwards the request to the target controller.\nThe target controller processes the request without secondary authorization checks, allowing the creation of a new, rogue administrative account. This process enables an attacker to achieve privilege escalation from a low-privilege user to full system administrator. Once elevated, the attacker can exploit the cross-tenant architecture to access, modify, or exfiltrate data across different tenants. The capability to create administrative accounts ensures that the attacker maintains persistent access to the system, facilitating long-term compromise and data pollution even if the initial low-privileged account is revoked or the original session expires."
}