CWE-863
Allowed-with-ReviewIncorrect Authorization
Abstraction: Class · Status: Incomplete
The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
8003 vulnerabilities reference this CWE, most recent first.
GHSA-373M-8W83-9JWP
Vulnerability from github – Published: 2022-06-14 00:00 – Updated: 2022-06-23 00:00Improper access control vulnerability in Rakuten Casa version AP_F_V1_4_1 or AP_F_V2_0_0 allows a remote attacker to log in with the root privilege and perform an arbitrary operation if the product is in its default settings in which is set to accept SSH connections from the WAN side, and is also connected to the Internet with the authentication information unchanged from the default settings.
{
"affected": [],
"aliases": [
"CVE-2022-28704"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-13T05:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control vulnerability in Rakuten Casa version AP_F_V1_4_1 or AP_F_V2_0_0 allows a remote attacker to log in with the root privilege and perform an arbitrary operation if the product is in its default settings in which is set to accept SSH connections from the WAN side, and is also connected to the Internet with the authentication information unchanged from the default settings.",
"id": "GHSA-373m-8w83-9jwp",
"modified": "2022-06-23T00:00:34Z",
"published": "2022-06-14T00:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28704"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN46892984/index.html"
},
{
"type": "WEB",
"url": "https://network.mobile.rakuten.co.jp/information/news/product/1033"
}
],
"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"
}
]
}
GHSA-3754-735C-C4RM
Vulnerability from github – Published: 2022-06-21 00:00 – Updated: 2022-06-29 00:00A vulnerability has been found in Adminer Login 1.4.4 and classified as problematic. This vulnerability affects unknown code. The manipulation leads to improper access controls. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.
{
"affected": [],
"aliases": [
"CVE-2017-20066"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-20T20:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability has been found in Adminer Login 1.4.4 and classified as problematic. This vulnerability affects unknown code. The manipulation leads to improper access controls. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used.",
"id": "GHSA-3754-735c-c4rm",
"modified": "2022-06-29T00:00:25Z",
"published": "2022-06-21T00:00:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-20066"
},
{
"type": "WEB",
"url": "https://sumofpwn.nl/advisory/2016/wordpress_adminer_plugin_allows_public__local__database_login.html"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.97384"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/Feb/96"
}
],
"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"
}
]
}
GHSA-3759-QV8M-9CV6
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-09 18:30An Incorrect Authorization vulnerability [CWE-863] in FortiPortal 7.4.0 through 7.4.5 may allow an authenticated attacker to reboot a shared FortiGate device via crafted HTTP requests.
{
"affected": [],
"aliases": [
"CVE-2025-54838"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T18:15:54Z",
"severity": "MODERATE"
},
"details": "An Incorrect Authorization vulnerability [CWE-863] in FortiPortal 7.4.0 through 7.4.5 may allow an authenticated attacker to reboot a shared FortiGate device via crafted HTTP requests.",
"id": "GHSA-3759-qv8m-9cv6",
"modified": "2025-12-09T18:30:45Z",
"published": "2025-12-09T18:30:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54838"
},
{
"type": "WEB",
"url": "https://fortiguard.fortinet.com/psirt/FG-IR-25-032"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-375P-5QHX-8WQ4
Vulnerability from github – Published: 2026-10-28 19:54 – Updated: 2026-10-28 19:54Summary
When middleware.Static is mounted globally (e.Use(middleware.Static(...))) and an application relies on a route- or group-level middleware guard to restrict a path that also falls under the served static root, a %2F-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for StaticFS/StaticDirectoryHandler in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the middleware.Static path. In addition, the StaticConfig.EnablePathUnescaping docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.
This is not path traversal: no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and %2F-encoded forms of the same path.
Details
Root cause — the router and the static handler disagree on how to interpret %2F:
- The router matches routes on the raw, still-encoded path, so
GET /admin%2Fsecret.txtdoes not match a/admin/...route or group; any middleware attached to that route/group is therefore skipped. middleware.Staticselects its path source inmiddleware/static.go(~L219): with a globale.Usemount there is no wildcard route, so it usesc.Request().URL.Path, whichnet/httphas already decoded (%2F→/). It thenpath.Cleans (~L235) andOpens (~L259)admin/secret.txt, serving the file.
Net effect: for the literal path the guard runs; for the %2F-encoded path the guard is skipped but the same file is served.
Relevant code:
- middleware/static.go ~L219 (p := c.Request().URL.Path), ~L235 (path.Clean), ~L259 (currentFS.Open)
- StaticConfig.EnablePathUnescaping docstring (static.go ~L60-67) — claims the default prevents the /admin%2fprivate.txt → /admin/* guard bypass; this is not true for the global mount.
Relationship to prior advisories:
- CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq (patched 5.2.0): same %2F router-vs-handler mismatch, but fixed for StaticFS/StaticDirectoryHandler. The middleware.Static path was not covered — this report is that gap.
- CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9 (patched 5.0.3): a different issue (Windows backslash traversal outside the root). Referenced only to disambiguate; not the same as this report.
PoC
Environment: golang:1.25, module using the official release (go get github.com/labstack/echo/v5@v5.3.1, no local replace). Static root public/ contains a marker file public/admin/secret.txt = SECRET.
Minimal app (the pattern under test: static served globally + a group guard intended to protect /admin):
package main
import (
"net/http"
"github.com/labstack/echo/v5"
"github.com/labstack/echo/v5/middleware"
)
func main() {
e := echo.New()
e.Use(middleware.Static("public")) // serves ./public globally (default filesystem)
admin := e.Group("/admin", func(next echo.HandlerFunc) echo.HandlerFunc {
return func(c *echo.Context) error { return c.String(http.StatusUnauthorized, "auth required") }
})
admin.GET("/secret.txt", func(c *echo.Context) error { return c.String(http.StatusOK, "handler") })
e.Start(":1323")
}
Requests (unauthenticated):
# Literal: route matches -> group guard runs
curl -i http://localhost:1323/admin/secret.txt
# => 401
# %2F-encoded: route does NOT match -> guard skipped, but middleware.Static serves the file
curl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt
# => 200, body: SECRET
Observed on v5.3.1: literal → 401; %2F → 200 with the file contents. For contrast, serving via the (patched) e.StaticFS("/") returns 404 for the same %2F request, showing the middleware.Static path was not covered by the CVE-2026-55677 fix.
Impact
An unauthenticated remote user can retrieve a file served by middleware.Static even when the application attached a route/group middleware guard to that path, by substituting / with %2F. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) — there is no access to files outside the static root.
Honest caveat on validity / severity: this only has security impact for applications that (a) serve a directory statically to the public and (b) place a sensitive file inside that same directory while relying on a route-level guard to protect it. That combination is arguably a misconfiguration — a statically-served directory is public by design — so maintainers may reasonably classify this as a documentation fix (correct the EnablePathUnescaping claim) or won't-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler %2F inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for middleware.Static, and (2) the docstring currently promises protection it does not provide.
Patches
Fixed in github.com/labstack/echo/v5 v5.4.0 and github.com/labstack/echo/v4 v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as /admin%2Fsecret.txt or /%61dmin/secret.txt no longer reach a file under a guarded route. Paths with ., .. or empty segments are no longer served.
Note: middleware registered with Echo#Use runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with Echo#Static behind the guard.
Workarounds
Keep files that need protection outside the Static middleware's root directory.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/labstack/echo/v5"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "5.4.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/labstack/echo/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-118650"
],
"database_specific": {
"cwe_ids": [
"CWE-177",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-28T19:54:20Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nWhen `middleware.Static` is mounted globally (`e.Use(middleware.Static(...))`) and an application relies on a **route- or group-level middleware guard** to restrict a path that also falls under the served static root, a `%2F`-encoded request bypasses that guard while the file is still served. This is the same encoding/decoding mismatch fixed for `StaticFS`/`StaticDirectoryHandler` in CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq, but the fix did not cover the `middleware.Static` path. In addition, the `StaticConfig.EnablePathUnescaping` docstring states the default configuration prevents exactly this bypass, which is inaccurate for the global-mount case.\n\n**This is not path traversal:** no file outside the static root is accessed. The served file lives inside the static root; the issue is that access-control expectations set by a route guard are inconsistent between the literal and `%2F`-encoded forms of the same path.\n\n## Details\n\nRoot cause \u2014 the router and the static handler disagree on how to interpret `%2F`:\n\n- The router matches routes on the **raw, still-encoded** path, so `GET /admin%2Fsecret.txt` does **not** match a `/admin/...` route or group; any middleware attached to that route/group is therefore skipped.\n- `middleware.Static` selects its path source in `middleware/static.go` (~L219): with a global `e.Use` mount there is no wildcard route, so it uses `c.Request().URL.Path`, which `net/http` has already **decoded** (`%2F` \u2192 `/`). It then `path.Clean`s (~L235) and `Open`s (~L259) `admin/secret.txt`, serving the file.\n\nNet effect: for the literal path the guard runs; for the `%2F`-encoded path the guard is skipped but the same file is served.\n\nRelevant code:\n- `middleware/static.go` ~L219 (`p := c.Request().URL.Path`), ~L235 (`path.Clean`), ~L259 (`currentFS.Open`)\n- `StaticConfig.EnablePathUnescaping` docstring (`static.go` ~L60-67) \u2014 claims the default prevents the `/admin%2fprivate.txt` \u2192 `/admin/*` guard bypass; this is not true for the global mount.\n\nRelationship to prior advisories:\n- **CVE-2026-55677 / GHSA-vfp3-v2gw-7wfq** (patched 5.2.0): same `%2F` router-vs-handler mismatch, but fixed for `StaticFS`/`StaticDirectoryHandler`. The `middleware.Static` path was not covered \u2014 this report is that gap.\n- **CVE-2026-25766 / GHSA-pgvm-wxw2-hrv9** (patched 5.0.3): a *different* issue (Windows backslash traversal **outside** the root). Referenced only to disambiguate; not the same as this report.\n\n## PoC\n\nEnvironment: `golang:1.25`, module using the official release (`go get github.com/labstack/echo/v5@v5.3.1`, no local `replace`). Static root `public/` contains a marker file `public/admin/secret.txt` = `SECRET`.\n\nMinimal app (the pattern under test: static served globally + a group guard intended to protect `/admin`):\n\n```go\npackage main\n\nimport (\n\t\"net/http\"\n\n\t\"github.com/labstack/echo/v5\"\n\t\"github.com/labstack/echo/v5/middleware\"\n)\n\nfunc main() {\n\te := echo.New()\n\te.Use(middleware.Static(\"public\")) // serves ./public globally (default filesystem)\n\n\tadmin := e.Group(\"/admin\", func(next echo.HandlerFunc) echo.HandlerFunc {\n\t\treturn func(c *echo.Context) error { return c.String(http.StatusUnauthorized, \"auth required\") }\n\t})\n\tadmin.GET(\"/secret.txt\", func(c *echo.Context) error { return c.String(http.StatusOK, \"handler\") })\n\n\te.Start(\":1323\")\n}\n```\n\nRequests (unauthenticated):\n\n```\n# Literal: route matches -\u003e group guard runs\ncurl -i http://localhost:1323/admin/secret.txt\n# =\u003e 401\n\n# %2F-encoded: route does NOT match -\u003e guard skipped, but middleware.Static serves the file\ncurl -i --path-as-is http://localhost:1323/admin%2Fsecret.txt\n# =\u003e 200, body: SECRET\n```\n\nObserved on `v5.3.1`: literal \u2192 `401`; `%2F` \u2192 `200` with the file contents. For contrast, serving via the (patched) `e.StaticFS(\"/\")` returns `404` for the same `%2F` request, showing the `middleware.Static` path was not covered by the CVE-2026-55677 fix.\n\n## Impact\n\nAn unauthenticated remote user can retrieve a file served by `middleware.Static` even when the application attached a route/group middleware guard to that path, by substituting `/` with `%2F`. The consequence is limited to files already inside the served static root (CWE-863 authorization inconsistency; CWE-436 interpretation conflict) \u2014 **there is no access to files outside the static root**.\n\n**Honest caveat on validity / severity:** this only has security impact for applications that (a) serve a directory statically to the public *and* (b) place a sensitive file inside that same directory while relying on a *route-level* guard to protect it. That combination is arguably a misconfiguration \u2014 a statically-served directory is public by design \u2014 so maintainers may reasonably classify this as a documentation fix (correct the `EnablePathUnescaping` claim) or won\u0027t-fix rather than a code vulnerability. It is filed primarily because (1) the router-vs-handler `%2F` inconsistency is the exact class fixed in CVE-2026-55677 but left uncovered for `middleware.Static`, and (2) the docstring currently promises protection it does not provide.\n\n## Patches\n\nFixed in `github.com/labstack/echo/v5` v5.4.0 and `github.com/labstack/echo/v4` v4.16.0. With the default settings, the Static middleware resolves files from the same form of the path that the router matched, so percent-encoded paths such as `/admin%2Fsecret.txt` or `/%61dmin/secret.txt` no longer reach a file under a guarded route. Paths with `.`, `..` or empty segments are no longer served.\n\nNote: middleware registered with `Echo#Use` runs before route and group middleware, so route guards never protect files served by a global Static middleware. Keep protected files outside its root directory, or serve them with `Echo#Static` behind the guard.\n\n## Workarounds\n\nKeep files that need protection outside the Static middleware\u0027s root directory.",
"id": "GHSA-375p-5qhx-8wq4",
"modified": "2026-10-28T19:54:20Z",
"published": "2026-10-28T19:54:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/labstack/echo/security/advisories/GHSA-375p-5qhx-8wq4"
},
{
"type": "WEB",
"url": "https://github.com/labstack/echo/commit/b838391e2eade87ae7e5a09d7bb5087bec271ec1"
},
{
"type": "WEB",
"url": "https://github.com/labstack/echo/commit/fc410094b2f3415cf2bf5204082137b205bfd5af"
},
{
"type": "PACKAGE",
"url": "https://github.com/labstack/echo"
},
{
"type": "WEB",
"url": "https://github.com/labstack/echo/releases/tag/v4.16.0"
},
{
"type": "WEB",
"url": "https://github.com/labstack/echo/releases/tag/v5.4.0"
}
],
"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"
}
],
"summary": "Echo\u0027s middleware.Static: `%2F`-encoded path bypasses route/group middleware guarding a statically-served path"
}
GHSA-3769-FJ8M-CRFP
Vulnerability from github – Published: 2024-12-02 15:31 – Updated: 2024-12-03 18:31Incorrect access control in wms-Warehouse management system-zeqp v2.20.9.1 due to the token value of the zeqp system being reused.
{
"affected": [],
"aliases": [
"CVE-2024-52732"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-02T15:15:12Z",
"severity": "CRITICAL"
},
"details": "Incorrect access control in wms-Warehouse management system-zeqp v2.20.9.1 due to the token value of the zeqp system being reused.",
"id": "GHSA-3769-fj8m-crfp",
"modified": "2024-12-03T18:31:03Z",
"published": "2024-12-02T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-52732"
},
{
"type": "WEB",
"url": "https://gist.github.com/LINF2009/fe2f0681389d4521d236a34ec2109a24"
},
{
"type": "WEB",
"url": "https://github.com/dotNetTreasury/WMS/blob/master/README.md"
},
{
"type": "WEB",
"url": "https://github.com/dotNetTreasury/WMS/tree/master/src"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-376R-8QWC-R5QG
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:55On NXP Kinetis KV1x, Kinetis KV3x, and Kinetis K8x devices, Flash Access Controls (FAC) (a software IP protection method for execute-only access) can be defeated by observing CPU registers and the effect of code/instruction execution.
{
"affected": [],
"aliases": [
"CVE-2019-14237"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-12T18:15:00Z",
"severity": "CRITICAL"
},
"details": "On NXP Kinetis KV1x, Kinetis KV3x, and Kinetis K8x devices, Flash Access Controls (FAC) (a software IP protection method for execute-only access) can be defeated by observing CPU registers and the effect of code/instruction execution.",
"id": "GHSA-376r-8qwc-r5qg",
"modified": "2024-04-04T01:55:38Z",
"published": "2022-05-24T16:56:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14237"
},
{
"type": "WEB",
"url": "https://www.usenix.org/system/files/woot19-paper_schink.pdf"
}
],
"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-3775-99MW-8RP4
Vulnerability from github – Published: 2026-05-04 20:11 – Updated: 2026-05-13 13:39The fix for CVE-2026-31892 (commit 534f4ff) blocks podSpecPatch when templateReferencing: Strict is active, but doesn't restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set hostNetwork: true, override serviceAccountName, or change securityContext on their Workflow while referencing a hardened template -- these survive JoinWorkflowSpec and get applied at pod creation.
The check in setExecWorkflow gates on HasPodSpecPatch() only:
if woc.controller.Config.WorkflowRestrictions.MustUseReference() && woc.wf.Spec.HasPodSpecPatch() {
Everything else passes through. createWorkflowPod reads hostNetwork, securityContext, serviceAccountName, tolerations, and automountServiceAccountToken from the merged spec and applies them directly to the pod.
JoinWorkflowSpec constructs the merge target from the user's spec and applies the template as a patch -- user fields take priority. When the template doesn't explicitly set a field like hostNetwork (most won't -- false is the zero value and gets omitted), the user's true survives. For fields like securityContext and serviceAccountName, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.
Both Strict and Secure modes are affected. Secure stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent MustNotChangeSpec comparisons pass.
Steps to reproduce
Tested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.
# enable strict mode
kubectl patch configmap workflow-controller-configmap -n argo --type merge \
-p '{"data":{"workflowRestrictions":"templateReferencing: Strict\n"}}'
kubectl rollout restart deployment workflow-controller -n argo
A template that lists network interfaces:
cat <<'EOF' | kubectl apply -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: netcheck
spec:
entrypoint: check
templates:
- name: check
container:
image: alpine:latest
command: ["/bin/sh", "-c"]
args: ["ip addr show | grep -E '^[0-9]+:' | cut -d: -f2"]
EOF
Submit a workflow with hostNetwork: true:
cat <<'EOF' | kubectl create -n argo -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: bypass-
spec:
workflowTemplateRef:
name: netcheck
hostNetwork: true
EOF
Pod gets host networking:
$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath='{.items[0].spec.hostNetwork}'
true
Container without the override sees eth0@if20. With the override, the pod sees the host's full network namespace -- all veth interfaces for other containers on the node.
podSpecPatch IS correctly blocked on the same cluster:
$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath='{.status.message}'
podSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction
serviceAccountName override also works -- a workflow with serviceAccountName: argo-server creates a pod running under the argo-server SA instead of the namespace default:
$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath='{.items[0].spec.serviceAccountName}'
argo-server
Tested in Secure mode as well -- same result. Pod created with hostNetwork: true before the workflow errors on an unrelated permission issue.
Impact
A user with create Workflow permission can bypass templateReferencing: Strict to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature.
The practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like hostNetwork). Clusters that rely on Argo's Strict mode as the primary enforcement layer are fully exposed.
Fix direction
The check in setExecWorkflow should cover all WorkflowSpec fields that influence pod security posture, not just podSpecPatch. The affected fields that I confirmed in createWorkflowPod: hostNetwork, securityContext, serviceAccountName, automountServiceAccountToken, tolerations, dnsPolicy, schedulerName, hostAliases, volumes.
An alternative approach: when MustUseReference() is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.
Affected versions
All versions supporting templateReferencing, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-workflows/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.7.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/argoproj/argo-workflows/v4"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0"
},
{
"fixed": "4.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42296"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-04T20:11:38Z",
"nvd_published_at": "2026-05-09T04:16:25Z",
"severity": "HIGH"
},
"details": "The fix for CVE-2026-31892 (commit 534f4ff) blocks `podSpecPatch` when `templateReferencing: Strict` is active, but doesn\u0027t restrict other WorkflowSpec fields that flow through the same merge path and get applied to pods. A user can set `hostNetwork: true`, override `serviceAccountName`, or change `securityContext` on their Workflow while referencing a hardened template -- these survive `JoinWorkflowSpec` and get applied at pod creation.\n\nThe check in `setExecWorkflow` gates on `HasPodSpecPatch()` only:\n\n```go\nif woc.controller.Config.WorkflowRestrictions.MustUseReference() \u0026\u0026 woc.wf.Spec.HasPodSpecPatch() {\n```\n\nEverything else passes through. `createWorkflowPod` reads `hostNetwork`, `securityContext`, `serviceAccountName`, `tolerations`, and `automountServiceAccountToken` from the merged spec and applies them directly to the pod.\n\n`JoinWorkflowSpec` constructs the merge target from the user\u0027s spec and applies the template as a patch -- user fields take priority. When the template doesn\u0027t explicitly set a field like `hostNetwork` (most won\u0027t -- `false` is the zero value and gets omitted), the user\u0027s `true` survives. For fields like `securityContext` and `serviceAccountName`, the template-level value takes precedence IF the template explicitly sets it. The bypass applies when the template relies on defaults.\n\nBoth `Strict` and `Secure` modes are affected. `Secure` stores the merged spec on first submission, so user overrides get baked into the stored spec and subsequent `MustNotChangeSpec` comparisons pass.\n\n## Steps to reproduce\n\nTested on v4.0.2 (the CVE-2026-31892 patched version) on kind v0.27.0 / K8s v1.35.0.\n\n```bash\n# enable strict mode\nkubectl patch configmap workflow-controller-configmap -n argo --type merge \\\n -p \u0027{\"data\":{\"workflowRestrictions\":\"templateReferencing: Strict\\n\"}}\u0027\nkubectl rollout restart deployment workflow-controller -n argo\n```\n\nA template that lists network interfaces:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl apply -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: WorkflowTemplate\nmetadata:\n name: netcheck\nspec:\n entrypoint: check\n templates:\n - name: check\n container:\n image: alpine:latest\n command: [\"/bin/sh\", \"-c\"]\n args: [\"ip addr show | grep -E \u0027^[0-9]+:\u0027 | cut -d: -f2\"]\nEOF\n```\n\nSubmit a workflow with `hostNetwork: true`:\n\n```bash\ncat \u003c\u003c\u0027EOF\u0027 | kubectl create -n argo -f -\napiVersion: argoproj.io/v1alpha1\nkind: Workflow\nmetadata:\n generateName: bypass-\nspec:\n workflowTemplateRef:\n name: netcheck\n hostNetwork: true\nEOF\n```\n\nPod gets host networking:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-bmg9b -o jsonpath=\u0027{.items[0].spec.hostNetwork}\u0027\ntrue\n```\n\nContainer without the override sees `eth0@if20`. With the override, the pod sees the host\u0027s full network namespace -- all veth interfaces for other containers on the node.\n\n`podSpecPatch` IS correctly blocked on the same cluster:\n\n```\n$ kubectl get workflow patched-check-jd272 -n argo -o jsonpath=\u0027{.status.message}\u0027\npodSpecPatch is not permitted when using workflowTemplateRef with templateReferencing restriction\n```\n\n`serviceAccountName` override also works -- a workflow with `serviceAccountName: argo-server` creates a pod running under the `argo-server` SA instead of the namespace default:\n\n```\n$ kubectl get pod -n argo -l workflows.argoproj.io/workflow=bypass-sa-slmjs -o jsonpath=\u0027{.items[0].spec.serviceAccountName}\u0027\nargo-server\n```\n\nTested in Secure mode as well -- same result. Pod created with `hostNetwork: true` before the workflow errors on an unrelated permission issue.\n\n## Impact\n\nA user with `create Workflow` permission can bypass `templateReferencing: Strict` to get host network access, switch service accounts, override pod security context, add tolerations to schedule on control-plane nodes, or enable SA token mounting. This defeats the stated purpose of the feature.\n\nThe practical impact depends on what Kubernetes-level controls are in place. Clusters with PodSecurity admission or OPA/Gatekeeper would independently block some of these (like `hostNetwork`). Clusters that rely on Argo\u0027s Strict mode as the primary enforcement layer are fully exposed.\n\n## Fix direction\n\nThe check in `setExecWorkflow` should cover all WorkflowSpec fields that influence pod security posture, not just `podSpecPatch`. The affected fields that I confirmed in `createWorkflowPod`: `hostNetwork`, `securityContext`, `serviceAccountName`, `automountServiceAccountToken`, `tolerations`, `dnsPolicy`, `schedulerName`, `hostAliases`, `volumes`.\n\nAn alternative approach: when `MustUseReference()` is true, strip all user-set WorkflowSpec fields except a known-safe allowlist (entrypoint, arguments, labels, annotations) before merging. This avoids a growing denylist as new fields get added.\n\n## Affected versions\n\nAll versions supporting `templateReferencing`, including v4.0.2 and v3.7.11 which patched CVE-2026-31892.",
"id": "GHSA-3775-99mw-8rp4",
"modified": "2026-05-13T13:39:21Z",
"published": "2026-05-04T20:11:38Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3775-99mw-8rp4"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/security/advisories/GHSA-3wf5-g532-rcrr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42296"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/commit/2727f3f701677d467dfb5e053c57237cbc752c3c"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/commit/534f4ff1cbd86908e8ff76d97d553ad5a49a950d"
},
{
"type": "PACKAGE",
"url": "https://github.com/argoproj/argo-workflows"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/releases/tag/v3.7.14"
},
{
"type": "WEB",
"url": "https://github.com/argoproj/argo-workflows/releases/tag/v4.0.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Argo has incomplete fix for CVE-2026-31892: hostNetwork, securityContext, serviceAccountName bypass templateReferencing Strict/Secure"
}
GHSA-37F2-JV37-C7JF
Vulnerability from github – Published: 2026-07-28 21:31 – Updated: 2026-07-28 21:31Bridge is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. An attacker could leverage this vulnerability to gain unauthorized read and write access. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed.
{
"affected": [],
"aliases": [
"CVE-2026-48390"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-28T19:17:35Z",
"severity": "HIGH"
},
"details": "Bridge is affected by an Incorrect Authorization vulnerability that could result in privilege escalation. An attacker could leverage this vulnerability to gain unauthorized read and write access. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Scope is changed.",
"id": "GHSA-37f2-jv37-c7jf",
"modified": "2026-07-28T21:31:32Z",
"published": "2026-07-28T21:31:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48390"
},
{
"type": "WEB",
"url": "https://helpx.adobe.com/security/products/bridge/apsb26-89.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-37F6-M354-672C
Vulnerability from github – Published: 2022-03-08 00:00 – Updated: 2022-03-17 00:02The UsersWP WordPress plugin before 1.2.3.1 is missing access controls when updating a user avatar, and does not make sure file names for user avatars are unique, allowing a logged in user to overwrite another users avatar.
{
"affected": [],
"aliases": [
"CVE-2022-0442"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-07T09:15:00Z",
"severity": "MODERATE"
},
"details": "The UsersWP WordPress plugin before 1.2.3.1 is missing access controls when updating a user avatar, and does not make sure file names for user avatars are unique, allowing a logged in user to overwrite another users avatar.",
"id": "GHSA-37f6-m354-672c",
"modified": "2022-03-17T00:02:55Z",
"published": "2022-03-08T00:00:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0442"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/9cf0822a-c9d6-4ebc-b905-95b143d1a692"
}
],
"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"
}
]
}
GHSA-37J9-5RXJ-3HWP
Vulnerability from github – Published: 2026-09-29 21:33 – Updated: 2026-09-29 21:33An authenticated user with edit permission on one folder can move a library panel into another folder where they only have view permission, through the library elements API or the equivalent App Platform resource. The update path did not check library panel create permission on the destination folder (incorrect authorization). No data from the destination folder is disclosed, and existing content there cannot be changed.
{
"affected": [],
"aliases": [
"CVE-2026-81842"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-29T21:19:31Z",
"severity": "MODERATE"
},
"details": "An authenticated user with edit permission on one folder can move a library panel into another folder where they only have view permission, through the library elements API or the equivalent App Platform resource. The update path did not check library panel create permission on the destination folder (incorrect authorization). No data from the destination folder is disclosed, and existing content there cannot be changed.",
"id": "GHSA-37j9-5rxj-3hwp",
"modified": "2026-09-29T21:33:27Z",
"published": "2026-09-29T21:33:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81842"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/cve-2026-81842"
}
],
"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"
}
]
}
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) [REF-229] 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 access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied 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 [REF-7].
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.
No CAPEC attack patterns related to this CWE.