Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect 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.

5641 vulnerabilities reference this CWE, most recent first.

GHSA-9F29-V6MM-PW6W

Vulnerability from github – Published: 2026-02-18 15:25 – Updated: 2026-02-19 21:56

Summary

opa-envoy-plugin has an Authorization Bypass via Double-Slash Path Misinterpretation in input.parsed_path

Details

A security vulnerability has been discovered in how the input.parsed_path field is constructed. HTTP request paths are treated as full URIs when parsed; interpreting leading path segments prefixed with double slashes (//) as authority components, and therefore dropping them from the parsed path. This creates a path interpretation mismatch between authorization policies and backend servers, enabling attackers to bypass access controls by crafting requests where the authorization filter evaluates a different path than the one ultimately served.

Attack example

HTTP request:

GET //admin/users HTTP/1.1
Host: example.com

Policy sees:

The leading //admin path segment is interpreted as an authority component, and dropped from input.parsed_path field:

{
  "parsed_path": ["users"]
}

Backend receives:

//admin/users path, normalized to /admin/users.

Affected Request Pattern Examples

Request path	`input.parsed_path`	`input.attributes.request.http.path`	Discrepancy
/	[""]	/	✅ None
//foo	[""]	//foo	❌ Mismatch
/admin	["admin"]	/admin	✅ None
/admin/users	["admin", "users"]	/admin/users	✅ None
//admin/users	["users"]	//admin/users	❌ Mismatch

Impact

Users are impacted if all the following conditions apply:

Protected resources are path-hierarchical (e.g., /admin/users vs /users)
Authorization policies use input.parsed_path for path-based decisions
Backend servers apply lenient path normalization

Patches

Go: v1.13.2-envoy-2 Docker: 1.13.2-envoy-2, 1.13.2-envoy-2-static

Workarounds

Users who cannot immediately upgrade opa-envoy-plugin are recommended to apply one, or more, of the workarrounds described below.

1. Enable the `merge_slashes` Envoy configuration option

As per Envoy best practices, enabling the merge_slashes configuration option in Envoy will remove redundant slashes from the request path before filtering is applied, effectively mitigating the input.parsed_path issue described in this advisory.

2. Use `input.attributes.request.http.path` instead of `input.parsed_path` in policies

The input.attributes.request.http.path field contains the unprocessed, raw request path. Users are recommended to update any policy using input.parsed_path to instead use the input.attributes.request.http.path field.

Example

package example

# Use instead of input.parsed_path
parsed_path := split(                                        # tokenize into array
    trim_left(                                               # drop leading slashes
        urlquery.decode(input.attributes.request.http.path), # url-decode the path
        "/",
    ),
    "/",
)

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.13.1-envoy"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/open-policy-agent/opa-envoy-plugin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.13.2-envoy-2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26205"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T15:25:04Z",
    "nvd_published_at": "2026-02-19T20:25:43Z",
    "severity": "HIGH"
  },
  "details": "A security vulnerability has been discovered in how the `input.parsed_path` field is constructed. HTTP request paths are treated as full URIs when parsed; interpreting leading path segments prefixed with double slashes (`//`) as [authority](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2) components, and therefore dropping them from the parsed path. This creates a path interpretation mismatch between authorization policies and backend servers, enabling attackers to bypass access controls by crafting requests where the authorization filter evaluates a different path than the one ultimately served.\n\n#### Attack example\n\n**HTTP request:**\n\n```\nGET //admin/users HTTP/1.1\nHost: example.com\n```\n\n**Policy sees:**\n\nThe leading `//admin` path segment is interpreted as an authority component, and dropped from `input.parsed_path` field:\n\n\n```json\n{\n  \"parsed_path\": [\"users\"]\n}\n```\n\n**Backend receives:**\n\n`//admin/users` path, normalized to `/admin/users`.\n\n#### Affected Request Pattern Examples\n\n| Request path | `input.parsed_path` | `input.attributes.request.http.path` | Discrepancy |\n| - | - | - | - |\n| / | [\"\"] | / | \u2705 None |\n| //foo  | [\"\"] | //foo| \u274c Mismatch |\n| /admin | [\"admin\"] | /admin | \u2705 None |\n| /admin/users | [\"admin\", \"users\"] |  /admin/users | \u2705 None |\n| //admin/users  | [\"users\"] | //admin/users | \u274c Mismatch |\n\n### Impact\n\nUsers are impacted if all the following conditions apply:\n\n1. Protected resources are path-hierarchical (e.g., `/admin/users` vs `/users`)\n2. Authorization policies use `input.parsed_path` for path-based decisions\n3. Backend servers apply lenient path normalization\n\n### Patches\n\nGo: `v1.13.2-envoy-2`\nDocker: `1.13.2-envoy-2`, `1.13.2-envoy-2-static`\n\n### Workarounds\n\nUsers who cannot immediately upgrade opa-envoy-plugin are recommended to apply one, or more, of the workarrounds described below.\n\n#### 1. Enable the `merge_slashes` Envoy configuration option\n\nAs per [Envoy best practices](https://www.envoyproxy.io/docs/envoy/v1.37.0/configuration/best_practices/edge.html), enabling the [merge_slashes](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-merge-slashes) configuration option in Envoy will remove redundant slashes from the request path before filtering is applied, effectively mitigating the `input.parsed_path` issue described in this advisory.\n\n\n#### 2. Use `input.attributes.request.http.path` instead of `input.parsed_path` in policies\n\nThe `input.attributes.request.http.path` field contains the unprocessed, raw request path. Users are recommended to update any policy using `input.parsed_path` to instead use the `input.attributes.request.http.path` field.\n\n##### Example ####\n\n```rego\npackage example\n\n# Use instead of input.parsed_path\nparsed_path := split(                                        # tokenize into array\n\ttrim_left(                                               # drop leading slashes\n\t\turlquery.decode(input.attributes.request.http.path), # url-decode the path\n\t\t\"/\",\n\t),\n\t\"/\",\n)\n```",
  "id": "GHSA-9f29-v6mm-pw6w",
  "modified": "2026-02-19T21:56:34Z",
  "published": "2026-02-18T15:25:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-policy-agent/opa-envoy-plugin/security/advisories/GHSA-9f29-v6mm-pw6w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26205"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-policy-agent/opa-envoy-plugin/commit/58c44d4ec408d5852d1d0287599e7d5c5e2bc5c3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-policy-agent/opa-envoy-plugin"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-policy-agent/opa-envoy-plugin/releases/tag/v1.13.2-envoy-2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "opa-envoy-plugin has an Authorization Bypass via Double-Slash Path Misinterpretation in input.parsed_path"
}

GHSA-9F32-PF5H-P947

Vulnerability from github – Published: 2026-06-29 18:31 – Updated: 2026-06-29 18:31

Details

Mythic before 3.4.0.60 contains a broken hasura permission filter on the payload_build_step table with an always-satisfied _or condition that bypasses operation-scoped access controls. Authenticated operators and spectators can query payload_build_step to read step_stdout, step_stderr, step_name, and step_description across all operations on the server.

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-57951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-29T18:16:40Z",
    "severity": "HIGH"
  },
  "details": "Mythic before 3.4.0.60 contains a broken hasura permission filter on the payload_build_step table with an always-satisfied _or condition that bypasses operation-scoped access controls. Authenticated operators and spectators can query payload_build_step to read step_stdout, step_stderr, step_name, and step_description across all operations on the server.",
  "id": "GHSA-9f32-pf5h-p947",
  "modified": "2026-06-29T18:31:56Z",
  "published": "2026-06-29T18:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-57951"
    },
    {
      "type": "WEB",
      "url": "https://github.com/its-a-feature/Mythic/issues/563"
    },
    {
      "type": "WEB",
      "url": "https://github.com/its-a-feature/Mythic/commit/82648e8241b800a32e1882afc310e7316d98ebaa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/its-a-feature/Mythic/releases/tag/v3.4.0.60"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/mythic-broken-permission-filter-in-payload-build-step-table"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/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-9F3R-2VGW-M8XP

Vulnerability from github – Published: 2026-03-16 20:45 – Updated: 2026-03-30 14:00

Summary

File Browser has an Access Rule Bypass via Path Traversal in Copy/Rename Destination Parameter

Details

Description

The resourcePatchHandler in http/resource.go validates the destination path against configured access rules before the path is cleaned/normalized. The rules engine (rules/rules.go) uses literal string prefix matching (strings.HasPrefix) or regex matching against the raw path. The actual file operation (fileutils.Copy, patchAction) subsequently calls path.Clean() which resolves .. sequences, producing a different effective path than the one validated.

This allows an authenticated user with Create or Rename permissions to bypass administrator-configured deny rules by including .. (dot-dot) path traversal sequences in the destination query parameter of a PATCH request.

Steps to Reproduce

1. Verify the rule works normally

# This should return 403 Forbidden
curl -X PATCH \
  -H "X-Auth: <alice_jwt>" \
  "http://host/api/resources/public/test.txt?action=copy&destination=%2Frestricted%2Fcopied.txt"

2. Exploit the bypass

# This should succeed despite the deny rule
curl -X PATCH \
  -H "X-Auth: <alice_jwt>" \
  "http://host/api/resources/public/test.txt?action=copy&destination=%2Fpublic%2F..%2Frestricted%2Fcopied.txt"

3. Result

The file test.txt is copied to /restricted/copied.txt despite the deny rule for /restricted/.

Root Cause Analysis

In http/resource.go:209-257:

dst := r.URL.Query().Get("destination")       // line 212
dst, err := url.QueryUnescape(dst)             // line 214 — dst contains ".."
if !d.Check(src) || !d.Check(dst) {            // line 215 — CHECK ON UNCLEANED PATH
    return http.StatusForbidden, nil
}

In rules/rules.go:29-35:

func (r *Rule) Matches(path string) bool {
    if r.Regex {
        return r.Regexp.MatchString(path)      // regex on literal path
    }
    return strings.HasPrefix(path, r.Path)     // prefix on literal path
}

In fileutils/copy.go:12-17:

func Copy(afs afero.Fs, src, dst string, ...) error {
    if dst = path.Clean("/" + dst); dst == "" { // CLEANING HAPPENS HERE, AFTER CHECK
        return os.ErrNotExist
    }

The rules check sees /public/../restricted/copied.txt (no match for /restricted/ prefix). The file operation resolves it to /restricted/copied.txt (within the restricted path).

Secondary Issue

In the same handler, the error from url.QueryUnescape is checked after d.Check() runs (lines 214-220), meaning the rules check executes on a potentially malformed string if unescaping fails.

Impact

An authenticated user with Copy (Create) or Rename permission can write or move files into any path within their scope that is protected by deny rules. This bypasses both:

Prefix-based rules: strings.HasPrefix on uncleaned path misses the match
Regex-based rules: Standard patterns like ^/restricted/.* fail on uncleaned path

Cannot be used to:

Escape the user's BasePathFs scope (afero prevents this)
Read from restricted paths (GET handler uses cleaned r.URL.Path)

Suggested Fix

Clean the destination path before the rules check:

dst, err := url.QueryUnescape(dst)
if err != nil {
    return errToStatus(err), err
}
dst = path.Clean("/" + dst)
src = path.Clean("/" + src)
if !d.Check(src) || !d.Check(dst) {
    return http.StatusForbidden, nil
}
if dst == "/" || src == "/" {
    return http.StatusForbidden, nil
}

Severity

6.5 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.61.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.62.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32758"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-16T20:45:12Z",
    "nvd_published_at": "2026-03-20T00:16:17Z",
    "severity": "MODERATE"
  },
  "details": "## Description\n\nThe `resourcePatchHandler` in `http/resource.go` validates the destination path against configured access rules before the path is cleaned/normalized. The rules engine (`rules/rules.go`) uses literal string prefix matching (`strings.HasPrefix`) or regex matching against the raw path. The actual file operation (`fileutils.Copy`, `patchAction`) subsequently calls `path.Clean()` which resolves `..` sequences, producing a different effective path than the one validated.\n\nThis allows an authenticated user with Create or Rename permissions to bypass administrator-configured deny rules by including `..` (dot-dot) path traversal sequences in the `destination` query parameter of a PATCH request.\n\n## Steps to Reproduce\n\n### 1. Verify the rule works normally\n\n```bash\n# This should return 403 Forbidden\ncurl -X PATCH \\\n  -H \"X-Auth: \u003calice_jwt\u003e\" \\\n  \"http://host/api/resources/public/test.txt?action=copy\u0026destination=%2Frestricted%2Fcopied.txt\"\n```\n\n### 2. Exploit the bypass\n\n```bash\n# This should succeed despite the deny rule\ncurl -X PATCH \\\n  -H \"X-Auth: \u003calice_jwt\u003e\" \\\n  \"http://host/api/resources/public/test.txt?action=copy\u0026destination=%2Fpublic%2F..%2Frestricted%2Fcopied.txt\"\n```\n\n### 3. Result\n\nThe file `test.txt` is copied to `/restricted/copied.txt` despite the deny rule for `/restricted/`.\n\n## Root Cause Analysis\n\nIn `http/resource.go:209-257`:\n\n```go\ndst := r.URL.Query().Get(\"destination\")       // line 212\ndst, err := url.QueryUnescape(dst)             // line 214 \u2014 dst contains \"..\"\nif !d.Check(src) || !d.Check(dst) {            // line 215 \u2014 CHECK ON UNCLEANED PATH\n    return http.StatusForbidden, nil\n}\n```\n\nIn `rules/rules.go:29-35`:\n\n```go\nfunc (r *Rule) Matches(path string) bool {\n    if r.Regex {\n        return r.Regexp.MatchString(path)      // regex on literal path\n    }\n    return strings.HasPrefix(path, r.Path)     // prefix on literal path\n}\n```\n\nIn `fileutils/copy.go:12-17`:\n\n```go\nfunc Copy(afs afero.Fs, src, dst string, ...) error {\n    if dst = path.Clean(\"/\" + dst); dst == \"\" { // CLEANING HAPPENS HERE, AFTER CHECK\n        return os.ErrNotExist\n    }\n```\n\nThe rules check sees `/public/../restricted/copied.txt` (no match for `/restricted/` prefix).\nThe file operation resolves it to `/restricted/copied.txt` (within the restricted path).\n\n## Secondary Issue\n\nIn the same handler, the error from `url.QueryUnescape` is checked after `d.Check()` runs (lines 214-220), meaning the rules check executes on a potentially malformed string if unescaping fails.\n\n## Impact\n\nAn authenticated user with Copy (Create) or Rename permission can write or move files into any path within their scope that is protected by deny rules. This bypasses both:\n\n- Prefix-based rules: `strings.HasPrefix` on uncleaned path misses the match\n- Regex-based rules: Standard patterns like `^/restricted/.*` fail on uncleaned path\n\nCannot be used to:\n\n- Escape the user\u0027s BasePathFs scope (afero prevents this)\n- Read from restricted paths (GET handler uses cleaned `r.URL.Path`)\n\n## Suggested Fix\n\nClean the destination path before the rules check:\n\n```go\ndst, err := url.QueryUnescape(dst)\nif err != nil {\n    return errToStatus(err), err\n}\ndst = path.Clean(\"/\" + dst)\nsrc = path.Clean(\"/\" + src)\nif !d.Check(src) || !d.Check(dst) {\n    return http.StatusForbidden, nil\n}\nif dst == \"/\" || src == \"/\" {\n    return http.StatusForbidden, nil\n}\n```",
  "id": "GHSA-9f3r-2vgw-m8xp",
  "modified": "2026-03-30T14:00:51Z",
  "published": "2026-03-16T20:45:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-9f3r-2vgw-m8xp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32758"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/4bd7d69c82163b201a987e99c0c50d7ecc6ee5f1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.62.0"
    }
  ],
  "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"
    }
  ],
  "summary": "File Browser has an Access Rule Bypass via Path Traversal in Copy/Rename Destination Parameter"
}

GHSA-9F3V-4733-P868

Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-05-24 19:17

Details

Operation restriction bypass in the management screen of Cybozu Remote Service 3.1.8 to 3.1.9 allows a remote authenticated attacker to alter the data of the management screen.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2021-20803"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-13T09:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Operation restriction bypass in the management screen of Cybozu Remote Service 3.1.8 to 3.1.9 allows a remote authenticated attacker to alter the data of the management screen.",
  "id": "GHSA-9f3v-4733-p868",
  "modified": "2022-05-24T19:17:25Z",
  "published": "2022-05-24T19:17:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20803"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN52694228/index.html"
    },
    {
      "type": "WEB",
      "url": "https://kb.cybozu.support/article/37421"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9F52-RJQV-25QV

Vulnerability from github – Published: 2026-06-09 06:31 – Updated: 2026-06-09 06:31

Details

A vulnerability in Spring Expression Language (SpEL) evaluation logic allows for arbitrary zero-argument method invocation, even within restricted or read-only contexts, which may allow an attacker to invoke unintended application logic.

Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-41852"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T05:16:37Z",
    "severity": "LOW"
  },
  "details": "A vulnerability in Spring Expression Language (SpEL) evaluation logic allows for arbitrary zero-argument method invocation, even within restricted or read-only contexts, which may allow an attacker to invoke unintended application logic.\n\nAffected versions:\nSpring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48.",
  "id": "GHSA-9f52-rjqv-25qv",
  "modified": "2026-06-09T06:31:58Z",
  "published": "2026-06-09T06:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41852"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-41852"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9F9G-FJV5-H5G7

Vulnerability from github – Published: 2023-12-21 21:30 – Updated: 2024-12-16 21:30

Details

An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed issue comments to be updated with an improperly scoped token. This vulnerability did not allow unauthorized access to any repository content as it also required contents:write and issues:read permissions. This vulnerability affected all versions of GitHub Enterprise Server since 3.7 and was fixed in version 3.17.19, 3.8.12, 3.9.7, 3.10.4, and 3.11.1.

Severity

4.9 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-51379"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-21T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed issue comments to be updated with an improperly scoped token. This vulnerability did not allow unauthorized access to any repository content as it also required contents:write and issues:read permissions. This vulnerability affected all versions of GitHub Enterprise Server since 3.7 and was fixed in version 3.17.19, 3.8.12, 3.9.7, 3.10.4, and 3.11.1.\u00a0",
  "id": "GHSA-9f9g-fjv5-h5g7",
  "modified": "2024-12-16T21:30:54Z",
  "published": "2023-12-21T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51379"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.4"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.1"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.7/admin/release-notes#3.7.19"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.8/admin/release-notes#3.8.12"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9FG6-4JC3-M2X8

Vulnerability from github – Published: 2022-05-24 17:40 – Updated: 2022-05-24 17:40

Details

newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-23449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-26T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.",
  "id": "GHSA-9fg6-4jc3-m2x8",
  "modified": "2022-05-24T17:40:06Z",
  "published": "2022-05-24T17:40:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/newbee-ltd/newbee-mall/issues/35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9FHM-53XW-H9C3

Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-21 21:32

Details

Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices' configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-56144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T20:17:02Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices\u0027 configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.",
  "id": "GHSA-9fhm-53xw-h9c3",
  "modified": "2026-07-21T21:32:40Z",
  "published": "2026-07-21T21:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56144"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-18-9-3-7-9-4-4-security-update-esa-2026-56/388555"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G2Q-W3W2-VF7Q

Vulnerability from github – Published: 2026-05-06 18:28 – Updated: 2026-05-06 18:28

Summary

Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation

Details

Summary

Any ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system — regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.

Details

TimesheetVoter::voteOnAttribute() maps permissions to own_timesheet or other_timesheet without checking team membership. The voter's own comment confirms this is a known gap:

// extend me for "team" support later on
if ($subject->getUser()?->getId() === $user->getId()) {
    $permission .= 'own';
} else {
    $permission .= 'other';
}

PoC

Tested against Kimai 2.52.0 Docker instance.

Setup: - User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description "Private timesheet - UserA only" - User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A

User B reads User A's timesheet data:

GET /api/timesheets/2 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 200 — returns full timesheet record including description "Private timesheet - UserA only".

User B deletes User A's timesheet:

DELETE /api/timesheets/3 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 204 No Content — timesheet permanently deleted.

User B tampers User A's timesheet:

PATCH /api/timesheets/6 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>
Content-Type: application/json

{"begin":"2026-03-24T08:00:00","end":"2026-03-24T18:00:00","project":1,"activity":1,"description":"TAMPERED","exported":false,"billable":false}

Response: HTTP 200 OK — duration inflated from 3600s to 36000s, description overwritten.

Note: ROLE_USER (userc) is correctly blocked — DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.

Impact

Any authenticated user with ROLE_TEAMLEAD or above can:

Permanently delete timesheets belonging to any user system-wide — destroying billable hours, payroll data, and project billing history
Silently alter timesheet descriptions, hours, and billing flags — forging hours up or down, directly affecting invoicing and payroll
Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records

No user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.

Maintainers answer: why this is not eligible for a CVE

The behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to ROLE_TEAMLEAD are:

edit_other_timesheet — Edit existing records of other users
delete_other_timesheet — Delete existing records of other users

These permissions were global by design, not team-scoped. The UI surfaces only the teamlead's own team timesheets, but the API has historically honored these permissions as documented: a role holding *_other_timesheet can act on any other user's timesheet. The inline comment // extend me for "team" support later on reflects this accurately — team-scoped enforcement was a planned enhancement, not a security control that existed and failed.

The report frames this as authorization bypass, but no authorization boundary is being crossed: ROLE_TEAMLEAD is operating within its documented permissions.

Kimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.

Solution

Team-scoped timesheet permission checks were added in 2.56.0.

Operators of Kimai <= 2.55 who need stricter isolation between teamleads should not grant ROLE_TEAMLEAD to users who must not act on other teams' timesheets.

Severity

5.7 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.55.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.56.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:28:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAny ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system \u2014 regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.\n\n### Details\n\n`TimesheetVoter::voteOnAttribute()` maps permissions to `own_timesheet` or `other_timesheet` without checking team membership. The voter\u0027s own comment confirms this is a known gap:\n\n```php\n// extend me for \"team\" support later on\nif ($subject-\u003egetUser()?-\u003egetId() === $user-\u003egetId()) {\n    $permission .= \u0027own\u0027;\n} else {\n    $permission .= \u0027other\u0027;\n}\n```\n\n### PoC\n\nTested against Kimai 2.52.0 Docker instance.\n\nSetup:\n- User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description \"Private timesheet - UserA only\"\n- User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A\n\n**User B reads User A\u0027s timesheet data:**\n\n```\nGET /api/timesheets/2 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 200 \u2014 returns full timesheet record including description \"Private timesheet - UserA only\".\n\n**User B deletes User A\u0027s timesheet:**\n\n```\nDELETE /api/timesheets/3 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 204 No Content \u2014 timesheet permanently deleted.\n\n**User B tampers User A\u0027s timesheet:**\n\n```\nPATCH /api/timesheets/6 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\nContent-Type: application/json\n\n{\"begin\":\"2026-03-24T08:00:00\",\"end\":\"2026-03-24T18:00:00\",\"project\":1,\"activity\":1,\"description\":\"TAMPERED\",\"exported\":false,\"billable\":false}\n```\n\nResponse: HTTP 200 OK \u2014 duration inflated from 3600s to 36000s, description overwritten.\n\n**Note:** ROLE_USER (userc) is correctly blocked \u2014 DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.\n\n### Impact\n\nAny authenticated user with ROLE_TEAMLEAD or above can:\n\n1. Permanently delete timesheets belonging to any user system-wide \u2014 destroying billable hours, payroll data, and project billing history\n2. Silently alter timesheet descriptions, hours, and billing flags \u2014 forging hours up or down, directly affecting invoicing and payroll\n3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records\n\nNo user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.\n\n### Maintainers answer: why this is not eligible for a CVE\n\nThe behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to `ROLE_TEAMLEAD` are:\n\n- `edit_other_timesheet` \u2014 Edit existing records of other users\n- `delete_other_timesheet` \u2014 Delete existing records of other users\n\nThese permissions were global by design, not team-scoped. The UI surfaces only the teamlead\u0027s own team timesheets, but the API has historically honored these permissions as documented: a role holding `*_other_timesheet` can act on any other user\u0027s timesheet. The inline comment `// extend me for \"team\" support later on` reflects this accurately \u2014 team-scoped enforcement was a planned enhancement, not a security control that existed and failed.\n\nThe report frames this as authorization bypass, but no authorization boundary is being crossed: `ROLE_TEAMLEAD` is operating within its documented permissions.\n\nKimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.\n\n### Solution\n\nTeam-scoped timesheet permission checks were added in 2.56.0.\n\nOperators of Kimai \u003c= 2.55 who need stricter isolation between teamleads should not grant `ROLE_TEAMLEAD` to users who must not act on other teams\u0027 timesheets.",
  "id": "GHSA-9g2q-w3w2-vf7q",
  "modified": "2026-05-06T18:28:46Z",
  "published": "2026-05-06T18:28:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-9g2q-w3w2-vf7q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation"
}

GHSA-9G39-JGF9-9MXX

Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-05-24 17:14

Details

A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2020-9004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.",
  "id": "GHSA-9g39-jgf9-9mxx",
  "modified": "2022-05-24T17:14:18Z",
  "published": "2022-05-24T17:14:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DrunkenShells/Disclosures/tree/master/CVE-2020-9004-Authenticated%20Remote%20Authorization%20Bypass%20Leading%20to%20RCE-Wowza"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/main/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/master/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.wowza.com/docs/wowza-streaming-engine-4-8-5-release-notes"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation

Architecture and Design

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

Architecture and Design

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

Architecture and Design

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

Architecture and Design

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

System Configuration Installation

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.

← Back to the CWE list

CWE-863

Incorrect Authorization

Attack example

Affected Request Pattern Examples

Impact

Patches

Workarounds

1. Enable the merge_slashes Envoy configuration option

2. Use input.attributes.request.http.path instead of input.parsed_path in policies

Example

Description

Steps to Reproduce

1. Verify the rule works normally

2. Exploit the bypass

3. Result

Root Cause Analysis

Secondary Issue

Impact

Suggested Fix

Summary

Details

PoC

Impact

Maintainers answer: why this is not eligible for a CVE

Solution

Mitigation

Mitigation

Mitigation MIT-4.4

Mitigation

Mitigation

1. Enable the `merge_slashes` Envoy configuration option

2. Use `input.attributes.request.http.path` instead of `input.parsed_path` in policies