SpringBlade OAuth Account Binding Hijacking via /user-auth-info

SpringBlade Vulnerability Key Information Summary Vulnerability Overview The endpoint in SpringBlade accepts and provided by the client, binding them persistently to an OAuth principal identified by and . Attackers can exploit this vulnerability to bind arbitrary OAuth identities to arbitrary local accounts (including administrator accounts), resulting in the resolution to the victim's account and the retrieval of their authentication context during subsequent OAuth logins. Attack Prerequisites: The attacker has access to the endpoint The attacker can control the OAuth pair Possession of a low-privilege JWT token (specific requirements depend on deployment exposure) Affected Endpoint: Affected Authorization Attributes: , , , Security Impact: Persistent OAuth account binding hijacking, account takeover, privilege escalation, potential exposure of serialized password hashes Severity: Authenticated attacker scenario: High (CVSS 3.1: 8.8) - Anonymous reachable scenario: Critical (CVSS 3.1: 9.8) - Scope of Impact Test Environment: SpringBlade v4.10.0 deployment, including , , SpringBlade Gateway, Nacos, MySQL, Redis Attacker Capabilities: - Complete account takeover - Privilege escalation to administrator accounts - Persistence of malicious associations in - Future OAuth logins authenticating as the victim - Exposure of stored password hashes when serializes the password field Attacker Does NOT Need: Victim's OAuth account, OAuth credentials, or passwords Attacker Needs: Knowledge or ability to enumerate a controlled OAuth identity and the target local user ID Root Cause 1. Publicly Accessible Feign Endpoint: Feign itself does not restrict direct HTTP access; the interface is exposed via a standard REST controller. 2. Improper Trust in Client-Provided : The implementation persists the complete object provided by the client without verifying caller ownership, OAuth ownership, tenant boundaries, or authorization scopes. 3. Lack of Inter-Service and Account Binding Controls: The endpoint does not require trusted service authentication, does not derive the target account from the currently authenticated user, and does not enforce explicit user consent. Remediation 1. Restrict Endpoint Access: Limit the endpoint to internal access only. Protect inter-service communication using mTLS, workload identity, signed requests, and network isolation. 2. Remove Client-Controlled Fields: Remove client-controlled , , and . OAuth lookup requests should only include provider-verified , , and server-derived tenant context. 3. Implement Account Linking Workflow: Establish a separate authorized workflow that requires an authenticated local session, verified OAuth ownership, tenant validation, and explicit user consent. Security Invariant: Verification Criteria Unauthorized callers receive HTTP 403 or equivalent rejection. Out-of-scope target identifiers are rejected before database writes or sensitive reads. Tenant and ownership boundaries are enforced on the server side. Direct HTTP requests to internal endpoints are rejected, even if frontend controls are hidden. POC Code Attack Request Initial Response (Guest User, but application has persisted) Subsequent Requests (Same and ) Reverse Verification is associated with user ID , and subsequent resolution returns user . Key Code Evidence 1. UserController.java - REST Mapping (L69-L70) 2. UserClient.java - Forwarding Request (L53-L56) 3. UserServiceImpl.java - Trusting Stored (L118-L129) 4. SocialTokenGranter.java - Building OAuth Binding (L87) --- Reference Link: https://lab008.github.io/CVERequest/SpringBlade/issue2.html

Goal Reached Thanks to every supporter — we hit 100%!

SpringBlade OAuth Account Binding Hijacking via /user-auth-info