Common Weakness Enumeration

CWE-863

Allowed-with-Review

Incorrect Authorization

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

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.

5686 vulnerabilities reference this CWE, most recent first.

GHSA-HM24-6W8P-GGGP

Vulnerability from github – Published: 2025-11-27 15:31 – Updated: 2025-11-27 15:31
VLAI
Details

The Folders – Unlimited Folders to Organize Media Library Folder, Pages, Posts, File Manager plugin for WordPress is vulnerable to unauthorized modification of data due to a misconfigured capability check on the 'wcp_change_post_folder' function in all versions up to, and including, 3.1.5. This makes it possible for authenticated attackers, with Contributor-level access and above, to move arbitrary folder contents to arbitrary folders.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-12971"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-27T13:15:58Z",
    "severity": "MODERATE"
  },
  "details": "The Folders \u2013 Unlimited Folders to Organize Media Library Folder, Pages, Posts, File Manager plugin for WordPress is vulnerable to unauthorized modification of data due to a misconfigured capability check on the \u0027wcp_change_post_folder\u0027 function in all versions up to, and including, 3.1.5. This makes it possible for authenticated attackers, with Contributor-level access and above, to move arbitrary folder contents to arbitrary folders.",
  "id": "GHSA-hm24-6w8p-gggp",
  "modified": "2025-11-27T15:31:25Z",
  "published": "2025-11-27T15:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12971"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/browser/folders/trunk/includes/folders.class.php#L3291"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3402986"
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2025-12971"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/f3845071-8419-4bb2-b22d-f9ae22fb7d6a?source=cve"
    }
  ],
  "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-HM2H-WWWH-G49X

Vulnerability from github – Published: 2026-04-10 19:49 – Updated: 2026-04-10 19:49
VLAI
Summary
Ech0 Scope Bypass: profile:read Access Token Can Change Admin Password and Escalate to Unrestricted Session
Details

Summary

The PUT /user endpoint is protected by RequireScopes("profile:read"), which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin's restricted profile:read access token can change the admin's password, then login to receive an unrestricted session token that bypasses all scope enforcement.

Details

The scope enforcement system defines granular scopes (e.g., echo:read, echo:write, admin:user) but has no profile:write scope. The PUT /user route is protected only by profile:read:

// internal/router/user.go:40-44
appRouterGroup.AuthRouterGroup.PUT(
    "/user",
    middleware.RequireScopes(authModel.ScopeProfileRead),
    h.UserHandler.UpdateUser(),
)

The RequireScopes middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes:

// internal/middleware/scope.go:14-19
func RequireScopes(scopes ...string) gin.HandlerFunc {
    return func(ctx *gin.Context) {
        v := viewer.MustFromContext(ctx.Request.Context())
        if v.TokenType() == authModel.TokenTypeSession {
            ctx.Next()
            return
        }
        // ... checks access token has required scopes (line 53)

The UpdateUser service checks user.IsAdmin but does not verify the token's scope is sufficient for write operations:

// internal/service/user/user.go:271-300
func (userService *UserService) UpdateUser(ctx context.Context, userdto model.UserInfoDto) error {
    userid := viewer.MustFromContext(ctx).UserID()
    user, err := userService.userRepository.GetUserByID(ctx, userid)
    // ...
    if !user.IsAdmin {
        return errors.New(commonModel.NO_PERMISSION_DENIED)
    }
    // ...
    if userdto.Password != "" && cryptoUtil.MD5Encrypt(userdto.Password) != user.Password {
        user.Password = cryptoUtil.MD5Encrypt(userdto.Password)  // line 299
    }

After the password is changed, the attacker logs in via POST /login which calls issueUserToken → CreateClaims, producing a session token with Type: "session" (jwt.go:33). Session tokens bypass RequireScopes entirely, granting unrestricted API access.

Escalation chain: profile:read access token → password change → login → unrestricted session token (bypasses all scope checks) → full admin access including admin:settings, admin:user, admin:token, file:write, etc.

PoC

# Prerequisites: Admin has created a profile:read access token for a read-only integration
# The attacker has obtained this token (e.g., from compromised integration, log leak, etc.)

ACCESS_TOKEN="<admin_profile_read_access_token>"
SERVER="http://localhost:8080"

# Step 1: Verify the token only has profile:read scope (can read profile)
curl -s -X GET "$SERVER/api/user" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
# Expected: 200 OK with user profile data

# Step 2: Verify the token CANNOT access admin endpoints (scope enforcement works)
curl -s -X GET "$SERVER/api/allusers" \
  -H "Authorization: Bearer $ACCESS_TOKEN"
# Expected: 403 Forbidden (requires admin:user scope)

# Step 3: Change the admin's password using the profile:read token
curl -s -X PUT "$SERVER/api/user" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"password":"attackerpass123"}'
# Expected: 200 OK — password changed despite only having profile:read scope

# Step 4: Login with the new password to get an unrestricted session token
curl -s -X POST "$SERVER/api/login" \
  -H "Content-Type: application/json" \
  -d '{"username":"admin","password":"attackerpass123"}'
# Expected: 200 OK with session JWT token

# Step 5: Use the session token to access admin-only endpoints
SESSION_TOKEN="<session_token_from_step_4>"
curl -s -X GET "$SERVER/api/allusers" \
  -H "Authorization: Bearer $SESSION_TOKEN"
# Expected: 200 OK — full admin access, all scope restrictions bypassed

Impact

An attacker who obtains an admin's profile:read access token — intended to be the most restrictive scope available — can:

  1. Change the admin's password without any write-level scope, violating the principle of least privilege
  2. Escalate to a full unrestricted session token by logging in with the new credentials
  3. Gain complete admin access including user management (admin:user), system settings (admin:settings), token management (admin:token), file operations (file:write), and all content operations
  4. Lock the original admin out of password-based authentication (though OAuth/passkey login remains available)

This defeats the entire purpose of the scope system: tokens intended for read-only integrations can be leveraged for full account takeover.

Recommended Fix

Add a profile:write scope and require it for the PUT /user endpoint:

// internal/model/auth/scope.go — add new scope
const (
    // ... existing scopes ...
    ScopeProfileRead    = "profile:read"
    ScopeProfileWrite   = "profile:write"  // NEW
)

var validScopes = map[string]struct{}{
    // ... existing entries ...
    ScopeProfileWrite:  {},  // NEW
}

// internal/router/user.go:40-44 — require profile:write for PUT
appRouterGroup.AuthRouterGroup.PUT(
    "/user",
    middleware.RequireScopes(authModel.ScopeProfileWrite),  // Changed from ScopeProfileRead
    h.UserHandler.UpdateUser(),
)

Similarly, update other write operations currently gated behind profile:read: - POST /oauth/:provider/bind → require profile:write - POST /passkey/register/begin and /finish → require profile:write - DELETE /passkeys/:id → require profile:write - PUT /passkeys/:id → require profile:write

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/lin-snow/ech0"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T19:49:13Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `PUT /user` endpoint is protected by `RequireScopes(\"profile:read\")`, which is a read-only scope. However, the endpoint performs write operations including password changes. An attacker who obtains an admin\u0027s restricted `profile:read` access token can change the admin\u0027s password, then login to receive an unrestricted session token that bypasses all scope enforcement.\n\n## Details\n\nThe scope enforcement system defines granular scopes (e.g., `echo:read`, `echo:write`, `admin:user`) but has no `profile:write` scope. The `PUT /user` route is protected only by `profile:read`:\n\n```go\n// internal/router/user.go:40-44\nappRouterGroup.AuthRouterGroup.PUT(\n    \"/user\",\n    middleware.RequireScopes(authModel.ScopeProfileRead),\n    h.UserHandler.UpdateUser(),\n)\n```\n\nThe `RequireScopes` middleware bypasses all scope checks for session tokens, and for access tokens only verifies the token contains the listed scopes:\n\n```go\n// internal/middleware/scope.go:14-19\nfunc RequireScopes(scopes ...string) gin.HandlerFunc {\n    return func(ctx *gin.Context) {\n        v := viewer.MustFromContext(ctx.Request.Context())\n        if v.TokenType() == authModel.TokenTypeSession {\n            ctx.Next()\n            return\n        }\n        // ... checks access token has required scopes (line 53)\n```\n\nThe `UpdateUser` service checks `user.IsAdmin` but does not verify the token\u0027s scope is sufficient for write operations:\n\n```go\n// internal/service/user/user.go:271-300\nfunc (userService *UserService) UpdateUser(ctx context.Context, userdto model.UserInfoDto) error {\n    userid := viewer.MustFromContext(ctx).UserID()\n    user, err := userService.userRepository.GetUserByID(ctx, userid)\n    // ...\n    if !user.IsAdmin {\n        return errors.New(commonModel.NO_PERMISSION_DENIED)\n    }\n    // ...\n    if userdto.Password != \"\" \u0026\u0026 cryptoUtil.MD5Encrypt(userdto.Password) != user.Password {\n        user.Password = cryptoUtil.MD5Encrypt(userdto.Password)  // line 299\n    }\n```\n\nAfter the password is changed, the attacker logs in via `POST /login` which calls `issueUserToken` \u2192 `CreateClaims`, producing a session token with `Type: \"session\"` (jwt.go:33). Session tokens bypass `RequireScopes` entirely, granting unrestricted API access.\n\n**Escalation chain:** `profile:read` access token \u2192 password change \u2192 login \u2192 unrestricted session token (bypasses all scope checks) \u2192 full admin access including `admin:settings`, `admin:user`, `admin:token`, `file:write`, etc.\n\n## PoC\n\n```bash\n# Prerequisites: Admin has created a profile:read access token for a read-only integration\n# The attacker has obtained this token (e.g., from compromised integration, log leak, etc.)\n\nACCESS_TOKEN=\"\u003cadmin_profile_read_access_token\u003e\"\nSERVER=\"http://localhost:8080\"\n\n# Step 1: Verify the token only has profile:read scope (can read profile)\ncurl -s -X GET \"$SERVER/api/user\" \\\n  -H \"Authorization: Bearer $ACCESS_TOKEN\"\n# Expected: 200 OK with user profile data\n\n# Step 2: Verify the token CANNOT access admin endpoints (scope enforcement works)\ncurl -s -X GET \"$SERVER/api/allusers\" \\\n  -H \"Authorization: Bearer $ACCESS_TOKEN\"\n# Expected: 403 Forbidden (requires admin:user scope)\n\n# Step 3: Change the admin\u0027s password using the profile:read token\ncurl -s -X PUT \"$SERVER/api/user\" \\\n  -H \"Authorization: Bearer $ACCESS_TOKEN\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"password\":\"attackerpass123\"}\u0027\n# Expected: 200 OK \u2014 password changed despite only having profile:read scope\n\n# Step 4: Login with the new password to get an unrestricted session token\ncurl -s -X POST \"$SERVER/api/login\" \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"username\":\"admin\",\"password\":\"attackerpass123\"}\u0027\n# Expected: 200 OK with session JWT token\n\n# Step 5: Use the session token to access admin-only endpoints\nSESSION_TOKEN=\"\u003csession_token_from_step_4\u003e\"\ncurl -s -X GET \"$SERVER/api/allusers\" \\\n  -H \"Authorization: Bearer $SESSION_TOKEN\"\n# Expected: 200 OK \u2014 full admin access, all scope restrictions bypassed\n```\n\n## Impact\n\nAn attacker who obtains an admin\u0027s `profile:read` access token \u2014 intended to be the most restrictive scope available \u2014 can:\n\n1. **Change the admin\u0027s password** without any write-level scope, violating the principle of least privilege\n2. **Escalate to a full unrestricted session token** by logging in with the new credentials\n3. **Gain complete admin access** including user management (`admin:user`), system settings (`admin:settings`), token management (`admin:token`), file operations (`file:write`), and all content operations\n4. **Lock the original admin out** of password-based authentication (though OAuth/passkey login remains available)\n\nThis defeats the entire purpose of the scope system: tokens intended for read-only integrations can be leveraged for full account takeover.\n\n## Recommended Fix\n\nAdd a `profile:write` scope and require it for the `PUT /user` endpoint:\n\n```go\n// internal/model/auth/scope.go \u2014 add new scope\nconst (\n    // ... existing scopes ...\n    ScopeProfileRead    = \"profile:read\"\n    ScopeProfileWrite   = \"profile:write\"  // NEW\n)\n\nvar validScopes = map[string]struct{}{\n    // ... existing entries ...\n    ScopeProfileWrite:  {},  // NEW\n}\n```\n\n```go\n// internal/router/user.go:40-44 \u2014 require profile:write for PUT\nappRouterGroup.AuthRouterGroup.PUT(\n    \"/user\",\n    middleware.RequireScopes(authModel.ScopeProfileWrite),  // Changed from ScopeProfileRead\n    h.UserHandler.UpdateUser(),\n)\n```\n\nSimilarly, update other write operations currently gated behind `profile:read`:\n- `POST /oauth/:provider/bind` \u2192 require `profile:write`\n- `POST /passkey/register/begin` and `/finish` \u2192 require `profile:write`\n- `DELETE /passkeys/:id` \u2192 require `profile:write`\n- `PUT /passkeys/:id` \u2192 require `profile:write`",
  "id": "GHSA-hm2h-wwwh-g49x",
  "modified": "2026-04-10T19:49:14Z",
  "published": "2026-04-10T19:49:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/security/advisories/GHSA-hm2h-wwwh-g49x"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/lin-snow/Ech0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lin-snow/Ech0/releases/tag/v4.4.3"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Ech0 Scope Bypass: profile:read Access Token Can Change Admin Password and Escalate to Unrestricted Session"
}

GHSA-HM32-9QCF-V83Q

Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2022-07-02 00:00
VLAI
Details

Improper Authorization vulnerability in McAfee Data Loss Prevention (DLP) ePO extension prior to 11.5.3 allows authenticated remote attackers to change the configuration when logged in with view only privileges via carefully constructed HTTP post messages.

Severity
6.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-7300"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-08-12T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper Authorization vulnerability in McAfee Data Loss Prevention (DLP) ePO extension prior to 11.5.3 allows authenticated remote attackers to change the configuration when logged in with view only privileges via carefully constructed HTTP post messages.",
  "id": "GHSA-hm32-9qcf-v83q",
  "modified": "2022-07-02T00:00:22Z",
  "published": "2022-05-24T17:25:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7300"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10326"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HM34-JCHW-P8X7

Vulnerability from github – Published: 2026-04-07 15:30 – Updated: 2026-04-07 15:30
VLAI
Details

An issue that could expose task information outside of the authorized organization scope has been resolved. This is an instance of CWE-863: Incorrect Authorization, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N (2.2 Low). This issue was fixed in version 4.0.260205.0 of the runZero Platform.

Severity
2.2 (Low)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-5381"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T15:17:48Z",
    "severity": "LOW"
  },
  "details": "An issue that could expose task information outside of the authorized organization scope has been resolved. This is an instance of CWE-863: Incorrect Authorization, and has an estimated CVSS score of CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N (2.2 Low). This issue was fixed in version 4.0.260205.0 of the runZero Platform.",
  "id": "GHSA-hm34-jchw-p8x7",
  "modified": "2026-04-07T15:30:52Z",
  "published": "2026-04-07T15:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5381"
    },
    {
      "type": "WEB",
      "url": "https://help.runzero.com/docs/release-notes/#402602050"
    },
    {
      "type": "WEB",
      "url": "https://www.runzero.com/advisories/runzero-platform-task-infoleak-cve-2026-5381"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HM4P-G93X-CRGM

Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-07-13 00:01
VLAI
Details

The unofficial GLSL Linting extension before 1.4.0 for Visual Studio Code allows remote code execution via a crafted glslangValidatorPath in the workspace configuration.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-30503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-04-13T02:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "The unofficial GLSL Linting extension before 1.4.0 for Visual Studio Code allows remote code execution via a crafted glslangValidatorPath in the workspace configuration.",
  "id": "GHSA-hm4p-g93x-crgm",
  "modified": "2022-07-13T00:01:21Z",
  "published": "2022-05-24T17:47:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30503"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hsimpson/vscode-glsllint/commit/3effba525bdff7d4257e66a6815ff956d2bce8ac"
    },
    {
      "type": "WEB",
      "url": "https://marketplace.visualstudio.com/items/CADENAS.vscode-glsllint/changelog#:~:text=1.4.x"
    },
    {
      "type": "WEB",
      "url": "https://vuln.ryotak.me/advisories/27"
    }
  ],
  "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-HM74-P2XF-RQGC

Vulnerability from github – Published: 2026-06-11 12:32 – Updated: 2026-06-11 12:32
VLAI
Details

GitLab has remediated an issue in GitLab EE affecting all versions from 13.9 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 that under certain conditions could have allowed an authenticated user with Security Manager-role permissions to manage project security configuration even when the relevant feature was in a disabled state, due to incorrect authorization enforcement.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-6277"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T12:16:32Z",
    "severity": "MODERATE"
  },
  "details": "GitLab has remediated an issue in GitLab EE affecting all versions from 13.9 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 that under certain conditions could have allowed an authenticated user with Security Manager-role permissions to manage project security configuration even when the relevant feature was in a disabled state, due to incorrect authorization enforcement.",
  "id": "GHSA-hm74-p2xf-rqgc",
  "modified": "2026-06-11T12:32:45Z",
  "published": "2026-06-11T12:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6277"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3662615"
    },
    {
      "type": "WEB",
      "url": "https://about.gitlab.com/releases/2026/06/10/patch-release-gitlab-19-0-2-released"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/596656"
    }
  ],
  "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-HM9R-7F84-25C9

Vulnerability from github – Published: 2023-11-12 15:30 – Updated: 2025-02-13 19:21
VLAI
Summary
Apache Airflow allows authenticated and DAG-view authorized users to modify some DAG run detail values when submitting notes
Details

Apache Airflow, versions before 2.7.3, is affected by a vulnerability that allows authenticated and DAG-view authorized Users to modify some DAG run detail values when submitting notes. This could have them alter details such as configuration parameters, start date, etc.  Users should upgrade to version 2.7.3 or later which has removed the vulnerability.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-47037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-13T20:43:20Z",
    "nvd_published_at": "2023-11-12T14:15:25Z",
    "severity": "MODERATE"
  },
  "details": "Apache Airflow, versions before 2.7.3, is affected by a vulnerability that allows authenticated and DAG-view authorized Users to modify some DAG run detail values when submitting notes. This could have them alter details such as configuration parameters, start date, etc.\u00a0 Users should upgrade to version 2.7.3 or later which has removed the vulnerability.",
  "id": "GHSA-hm9r-7f84-25c9",
  "modified": "2025-02-13T19:21:05Z",
  "published": "2023-11-12T15:30:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47037"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/33413"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/commit/2a0106e4edf67c5905ebfcb82a6008662ae0f7ad"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/commit/b7a46c970d638028a4a7643ad000dcee951fb9ef"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/apache-airflow/PYSEC-2023-232.yaml"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/04y4vrw1t2xl030gswtctc4nt1w90cb0"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/11/12/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Airflow allows authenticated and DAG-view authorized users to modify some DAG run detail values when submitting notes"
}

GHSA-HMFX-3PCX-653P

Vulnerability from github – Published: 2023-02-16 14:11 – Updated: 2024-09-06 21:37
VLAI
Summary
Supplementary groups are not set up properly in github.com/containerd/containerd
Details

Impact

A bug was found in containerd where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.

Downstream applications that use the containerd client library may be affected as well.

Patches

This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd's client library should check that application for a separate advisory and instructions.

Workarounds

Ensure that the "USER $USERNAME" Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to ENTRYPOINT ["su", "-", "user"] to allow su to properly set up supplementary groups.

References

  • https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/
  • Docker/Moby: CVE-2022-36109, fixed in Docker 20.10.18
  • CRI-O: CVE-2022-2995, fixed in CRI-O 1.25.0
  • Podman: CVE-2022-2989, fixed in Podman 3.0.1 and 4.2.0
  • Buildah: CVE-2022-2990, fixed in Buildah 1.27.1

Note that CVE IDs apply to a particular implementation, even if an issue is common.

For more information

If you have any questions or comments about this advisory:

To report a security issue in containerd: * Report a new vulnerability * Email us at security@containerd.io

Severity
5.3 (Medium)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/containerd/containerd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.6.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-25173"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-16T14:11:33Z",
    "nvd_published_at": "2023-02-16T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA bug was found in containerd where supplementary groups are not set up properly inside a container.  If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container.\n\nDownstream applications that use the containerd client library may be affected as well.\n\n### Patches\nThis bug has been fixed in containerd v1.6.18 and v.1.5.18.  Users should update to these versions and recreate containers to resolve this issue.  Users who rely on a downstream application that uses containerd\u0027s client library should check that application for a separate advisory and instructions.\n\n### Workarounds\n\nEnsure that the `\"USER $USERNAME\"` Dockerfile instruction is not used.  Instead, set the container entrypoint to a value similar to `ENTRYPOINT [\"su\", \"-\", \"user\"]` to allow `su` to properly set up supplementary groups.\n\n### References\n\n- https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation/\n- Docker/Moby: CVE-2022-36109, fixed in Docker 20.10.18\n- CRI-O: CVE-2022-2995, fixed in CRI-O 1.25.0\n- Podman: CVE-2022-2989, fixed in Podman 3.0.1 and 4.2.0\n- Buildah: CVE-2022-2990, fixed in Buildah 1.27.1\n\nNote that CVE IDs apply to a particular implementation, even if an issue is common.\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Open an issue in [containerd](https://github.com/containerd/containerd/issues/new/choose)\n* Email us at [security@containerd.io](mailto:security@containerd.io)\n\nTo report a security issue in containerd:\n* [Report a new vulnerability](https://github.com/containerd/containerd/security/advisories/new)\n* Email us at [security@containerd.io](mailto:security@containerd.io)",
  "id": "GHSA-hmfx-3pcx-653p",
  "modified": "2024-09-06T21:37:04Z",
  "published": "2023-02-16T14:11:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/security/advisories/GHSA-hmfx-3pcx-653p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moby/moby/security/advisories/GHSA-rc4r-wh2q-q6c4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25173"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/commit/133f6bb6cd827ce35a5fb279c1ead12b9d21460a"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-4wjj-jwc9-2x96"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-fjm8-m7m6-2fjp"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-phjr-8j92-w5v7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/containerd/containerd"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/releases/tag/v1.5.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/containerd/containerd/releases/tag/v1.6.18"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYZOKMMVX4SIEHPJW3SJUQGMO5YZCPHC"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XNF4OLYZRQE75EB5TW5N42FSXHBXGWFE"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZTE4ITXXPIWZEQ4HYQCB6N6GZIMWXDAI"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-1574"
    },
    {
      "type": "WEB",
      "url": "https://www.benthamsgaze.org/2022/08/22/vulnerability-in-linux-containers-investigation-and-mitigation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Supplementary groups are not set up properly in github.com/containerd/containerd"
}

GHSA-HMGR-67HW-J2CQ

Vulnerability from github – Published: 2026-05-08 20:01 – Updated: 2026-05-15 23:53
VLAI
Summary
Open WebUI: Deactivated Channel Members Retain Full Access to Group/DM Channels
Details

Deactivated Channel Members Retain Full Access to Group/DM Channels

Affected Component

Channel membership authorization check: - backend/open_webui/models/channels.py (lines 663-673, is_user_channel_member) - Used at 15 locations in backend/open_webui/routers/channels.py

Affected Versions

Current main branch (commit 6fdd19bf1) and likely all versions with the group/DM channel feature.

Description

The is_user_channel_member function checks whether a ChannelMember row exists but does not check the is_active field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with is_active=False and status='left'. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.

The channel correctly disappears from the deactivated user's channel list (the listing query at get_channels_by_user_id properly filters on is_active), but all 15 message-level endpoints in the router rely on is_user_channel_member for authorization, which does not filter on is_active.

# models/channels.py:663 — missing is_active check
def is_user_channel_member(self, channel_id, user_id, db=None):
    membership = db.query(ChannelMember).filter(
        ChannelMember.channel_id == channel_id,
        ChannelMember.user_id == user_id,
    ).first()
    return membership is not None  # True even when is_active=False

Compare with get_channel_by_id_and_user_id (line 778) which correctly checks ChannelMember.is_active.is_(True).

CVSS 3.1 Breakdown

Metric Value Rationale
Attack Vector Network (N) Exploited remotely via API calls
Attack Complexity Low (L) No special conditions beyond knowing the channel ID (which the user had as a former member)
Privileges Required Low (L) Requires a valid user account and prior channel membership
User Interaction None (N) No victim interaction required
Scope Unchanged (U) Impact is within the same authorization boundary (the channel)
Confidentiality Low (L) Can read messages in a channel the user should no longer access
Integrity Low (L) Can post, edit, and delete messages in the channel
Availability None (N) No denial of service

Attack Scenario

  1. User A and User B are members of a private group channel.
  2. The channel owner removes User B (or User B leaves). User B's membership is set to is_active=False, status='left'.
  3. The channel disappears from User B's UI — but User B noted the channel ID while they were a member.
  4. User B calls the API directly:
  5. GET /api/v1/channels/{channel_id}/messages — reads all messages, including those posted after deactivation
  6. POST /api/v1/channels/{channel_id}/messages/post — posts new messages
  7. POST /api/v1/channels/{channel_id}/messages/{id}/update — edits messages
  8. DELETE /api/v1/channels/{channel_id}/messages/{id}/delete — deletes messages
  9. All requests succeed because is_user_channel_member returns True.

Impact

  • Deactivated users can continue reading all new messages posted after their removal (confidentiality breach)
  • Deactivated users can post, edit, and delete messages (integrity breach)
  • The deactivation mechanism provides a false sense of security — channel owners believe removed users have lost access

Preconditions

  • Channels feature must be enabled (disabled by default)
  • Attacker must have a valid user account
  • Attacker must have been a member of the channel at some point (and thus knows the channel ID)

Recommended Fix

Add is_active filtering to is_user_channel_member:

def is_user_channel_member(self, channel_id, user_id, db=None):
    membership = db.query(ChannelMember).filter(
        ChannelMember.channel_id == channel_id,
        ChannelMember.user_id == user_id,
        ChannelMember.is_active.is_(True),
    ).first()
    return membership is not None

This aligns it with the existing get_channel_by_id_and_user_id method which already applies this filter correctly.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.12"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44561"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-08T20:01:45Z",
    "nvd_published_at": "2026-05-15T20:16:47Z",
    "severity": "MODERATE"
  },
  "details": "# Deactivated Channel Members Retain Full Access to Group/DM Channels\n\n## Affected Component\n\nChannel membership authorization check:\n- `backend/open_webui/models/channels.py` (lines 663-673, `is_user_channel_member`)\n- Used at 15 locations in `backend/open_webui/routers/channels.py`\n\n## Affected Versions\n\nCurrent main branch (commit `6fdd19bf1`) and likely all versions with the group/DM channel feature.\n\n## Description\n\nThe `is_user_channel_member` function checks whether a `ChannelMember` row exists but does not check the `is_active` field. When a user is deactivated from a group or DM channel (removed by the channel owner, or leaves voluntarily), their membership row persists with `is_active=False` and `status=\u0027left\u0027`. Because the authorization check ignores this field, the deactivated user retains full read and write access to the channel via direct API calls.\n\nThe channel correctly disappears from the deactivated user\u0027s channel list (the listing query at `get_channels_by_user_id` properly filters on `is_active`), but all 15 message-level endpoints in the router rely on `is_user_channel_member` for authorization, which does not filter on `is_active`.\n\n```python\n# models/channels.py:663 \u2014 missing is_active check\ndef is_user_channel_member(self, channel_id, user_id, db=None):\n    membership = db.query(ChannelMember).filter(\n        ChannelMember.channel_id == channel_id,\n        ChannelMember.user_id == user_id,\n    ).first()\n    return membership is not None  # True even when is_active=False\n```\n\nCompare with `get_channel_by_id_and_user_id` (line 778) which correctly checks `ChannelMember.is_active.is_(True)`.\n\n## CVSS 3.1 Breakdown\n\n| Metric | Value | Rationale |\n|--------|-------|-----------|\n| Attack Vector | Network (N) | Exploited remotely via API calls |\n| Attack Complexity | Low (L) | No special conditions beyond knowing the channel ID (which the user had as a former member) |\n| Privileges Required | Low (L) | Requires a valid user account and prior channel membership |\n| User Interaction | None (N) | No victim interaction required |\n| Scope | Unchanged (U) | Impact is within the same authorization boundary (the channel) |\n| Confidentiality | Low (L) | Can read messages in a channel the user should no longer access |\n| Integrity | Low (L) | Can post, edit, and delete messages in the channel |\n| Availability | None (N) | No denial of service |\n\n## Attack Scenario\n\n1. User A and User B are members of a private group channel.\n2. The channel owner removes User B (or User B leaves). User B\u0027s membership is set to `is_active=False, status=\u0027left\u0027`.\n3. The channel disappears from User B\u0027s UI \u2014 but User B noted the channel ID while they were a member.\n4. User B calls the API directly:\n   - `GET /api/v1/channels/{channel_id}/messages` \u2014 reads all messages, including those posted after deactivation\n   - `POST /api/v1/channels/{channel_id}/messages/post` \u2014 posts new messages\n   - `POST /api/v1/channels/{channel_id}/messages/{id}/update` \u2014 edits messages\n   - `DELETE /api/v1/channels/{channel_id}/messages/{id}/delete` \u2014 deletes messages\n5. All requests succeed because `is_user_channel_member` returns `True`.\n\n## Impact\n\n- Deactivated users can continue reading all new messages posted after their removal (confidentiality breach)\n- Deactivated users can post, edit, and delete messages (integrity breach)\n- The deactivation mechanism provides a false sense of security \u2014 channel owners believe removed users have lost access\n\n## Preconditions\n\n- Channels feature must be enabled (disabled by default)\n- Attacker must have a valid user account\n- Attacker must have been a member of the channel at some point (and thus knows the channel ID)\n\n## Recommended Fix\n\nAdd `is_active` filtering to `is_user_channel_member`:\n\n```python\ndef is_user_channel_member(self, channel_id, user_id, db=None):\n    membership = db.query(ChannelMember).filter(\n        ChannelMember.channel_id == channel_id,\n        ChannelMember.user_id == user_id,\n        ChannelMember.is_active.is_(True),\n    ).first()\n    return membership is not None\n```\n\nThis aligns it with the existing `get_channel_by_id_and_user_id` method which already applies this filter correctly.",
  "id": "GHSA-hmgr-67hw-j2cq",
  "modified": "2026-05-15T23:53:24Z",
  "published": "2026-05-08T20:01:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-hmgr-67hw-j2cq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44561"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Deactivated Channel Members Retain Full Access to Group/DM Channels"
}

GHSA-HMGR-RM4X-VVJH

Vulnerability from github – Published: 2024-09-04 06:30 – Updated: 2024-09-04 06:30
VLAI
Details

Improper authorization in One UI Home prior to SMR Sep-2024 Release 1 allows physical attackers to temporarily access sensitive information.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-34642"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-04T06:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in One UI Home prior to SMR Sep-2024 Release 1 allows physical attackers to temporarily access sensitive information.",
  "id": "GHSA-hmgr-rm4x-vvjh",
  "modified": "2024-09-04T06:30:41Z",
  "published": "2024-09-04T06:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34642"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/securityUpdate.smsb?year=2024\u0026month=09"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "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