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.

5517 vulnerabilities reference this CWE, most recent first.

GHSA-X2PQ-6FC2-WH58

Vulnerability from github – Published: 2026-03-21 03:31 – Updated: 2026-03-21 03:31
VLAI
Details

OpenClaw versions prior to 2026.3.1 contain an authorization mismatch vulnerability that allows authenticated callers with operator.write scope to invoke owner-only tool surfaces including gateway and cron through agent runs in scoped-token deployments. Attackers with write-scope access can perform control-plane actions beyond their intended authorization level by exploiting inconsistent owner-only gating during agent execution.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-32051"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-21T01:17:08Z",
    "severity": "HIGH"
  },
  "details": "OpenClaw versions prior to 2026.3.1 contain an authorization mismatch vulnerability that allows authenticated callers with operator.write scope to invoke owner-only tool surfaces including gateway and cron through agent runs in scoped-token deployments. Attackers with write-scope access can perform control-plane actions beyond their intended authorization level by exploiting inconsistent owner-only gating during agent execution.",
  "id": "GHSA-x2pq-6fc2-wh58",
  "modified": "2026-03-21T03:31:13Z",
  "published": "2026-03-21T03:31:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jr6x-2q95-fh2g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32051"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-authorization-bypass-in-agent-runs-via-owner-only-tool-access"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-X35M-3GP4-4FH5

Vulnerability from github – Published: 2026-05-07 03:21 – Updated: 2026-05-14 20:54
VLAI
Summary
etcd RBAC bypass allows unauthorized data access via PrevKv/lease attachment in nested transaction Put requests
Details

Impact

What kind of vulnerability is it? Who is impacted?

A vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled.

Kubernetes does not rely on etcd’s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.

Patches

Has the problem been patched? What versions should users upgrade to?

This vulnerability is patched in the following versions: - etcd 3.6.11 - etcd 3.5.30 - etcd 3.4.44

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

If upgrading is not immediately possible, reduce exposure by treating the affected RPCs as unauthenticated in practice.

  • restrict network access to etcd server ports so only trusted components can connect
  • require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate distribution

Reporters

Samy Ghannad (@SamyGhannad on Github) reported that read access via PrevKv in a Put request within etcd transactions bypassed RBAC authorization checks. Benjamin Wang (@ahrtr ) further analyzed that lease attachment in a Put request within etcd transactions also bypassed RBAC authorization checks

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.10"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.6.0"
            },
            {
              "fixed": "3.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.5.29"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.5.0"
            },
            {
              "fixed": "3.5.30"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.4.43"
      },
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.44"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-44283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T03:21:53Z",
    "nvd_published_at": "2026-05-14T18:16:49Z",
    "severity": "LOW"
  },
  "details": "### Impact\n_What kind of vulnerability is it? Who is impacted?_\n\nA vulnerability in etcd allows read access via PrevKv, or lease attachment in Put requests within transaction operations, to bypass RBAC authorization checks. An authenticated user without sufficient read or lease-related permissions may be able to access unauthorized data or attach leases by invoking transaction operations with these features enabled.\n\nKubernetes does not rely on etcd\u2019s built-in authentication and authorization. Instead, the API server handles authentication and authorization itself, so typical Kubernetes deployments are not affected.\n\n### Patches\n_Has the problem been patched? What versions should users upgrade to?_\n\nThis vulnerability is patched in the following versions:\n- etcd 3.6.11\n- etcd 3.5.30\n- etcd 3.4.44\n\n### Workarounds\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nIf upgrading is not immediately possible, reduce exposure by treating the affected\nRPCs as unauthenticated in practice.\n\n- restrict network access to etcd server ports so only trusted components can connect\n- require strong client identity at the transport layer, such as mTLS with tightly scoped client certificate\ndistribution\n\n### Reporters\n\nSamy Ghannad (@SamyGhannad on Github) reported that read access via PrevKv in a Put request within etcd transactions bypassed RBAC authorization checks. Benjamin Wang (@ahrtr ) further analyzed that lease attachment in a Put request within etcd transactions also bypassed RBAC authorization checks",
  "id": "GHSA-x35m-3gp4-4fh5",
  "modified": "2026-05-14T20:54:29Z",
  "published": "2026-05-07T03:21:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/etcd-io/etcd/security/advisories/GHSA-x35m-3gp4-4fh5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44283"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/etcd-io/etcd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "etcd RBAC bypass allows unauthorized data access via PrevKv/lease attachment in nested transaction Put requests"
}

GHSA-X3F7-3CX7-2CW7

Vulnerability from github – Published: 2026-05-18 09:31 – Updated: 2026-05-18 09:31
VLAI
Details

Mattermost Plugins versions <=11.5 11.1.5 10.13.11 11.3.4.0 fail to appropriately check for valid namespaces which allows plugin users to create subscriptions to groups that were not whitelisted via creating groups that share the same prefix as a whitelisted group. Mattermost Advisory ID: MMSA-2026-00601

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-6342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-18T08:16:14Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost Plugins versions \u003c=11.5 11.1.5 10.13.11 11.3.4.0 fail to appropriately check for valid namespaces which allows plugin users to create subscriptions to groups that were not whitelisted via creating groups that share the same prefix as a whitelisted group. Mattermost Advisory ID: MMSA-2026-00601",
  "id": "GHSA-x3f7-3cx7-2cw7",
  "modified": "2026-05-18T09:31:48Z",
  "published": "2026-05-18T09:31:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6342"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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-X3HX-CH7P-8XGG

Vulnerability from github – Published: 2025-11-14 09:30 – Updated: 2025-11-17 17:50
VLAI
Summary
Mattermost allows regular users to access archived channel content and files
Details

Mattermost versions < 11.0 fail to properly enforce the "Allow users to view archived channels" setting which allows regular users to access archived channel content and files via the "Open in Channel" functionality from followed threads

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.0-alpha.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250815165020-c8d66301415d"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-41436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-17T17:50:34Z",
    "nvd_published_at": "2025-11-14T08:15:45Z",
    "severity": "LOW"
  },
  "details": "Mattermost versions \u003c 11.0 fail to properly enforce the \"Allow users to view archived channels\" setting which allows regular users to access archived channel content and files via the \"Open in Channel\" functionality from followed threads",
  "id": "GHSA-x3hx-ch7p-8xgg",
  "modified": "2025-11-17T17:50:34Z",
  "published": "2025-11-14T09:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-41436"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/c8d66301415d5b447df0e829bdbaa92e8a83ecf8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost allows regular users to access archived channel content and files"
}

GHSA-X3M5-8XJ2-GWPG

Vulnerability from github – Published: 2025-03-18 21:32 – Updated: 2025-03-18 21:32
VLAI
Details

A vulnerability has been identified in the port ACL functionality of AOS-CX software running on the HPE Aruba Networking CX 9300 Switch Series only and affects:

 - AOS-CX 10.14.xxxx : All patches
 - AOS-CX 10.15.xxxx : 10.15.1000 and below

The vulnerability is specific to traffic originated by the CX 9300 switch platform and could allow an attacker to bypass ACL rules applied to routed ports on egress. As a result, port ACLs are not correctly enforced, which could lead to unauthorized traffic flow and violations of security policies. Egress VLAN ACLs and Routed VLAN ACLs are not affected by this vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-25040"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-18T19:15:49Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been identified in the port ACL functionality of AOS-CX software running on the HPE Aruba Networking CX 9300 Switch Series only and affects: \n\n     - AOS-CX 10.14.xxxx : All patches\n     - AOS-CX 10.15.xxxx : 10.15.1000 and below \nThe vulnerability is specific to traffic originated by the CX 9300 switch platform and could allow an attacker to bypass ACL rules applied to routed ports on egress. As a result, port ACLs are not correctly enforced, which could lead to unauthorized traffic flow and violations of security policies. Egress VLAN ACLs and Routed VLAN ACLs are not affected by this vulnerability.",
  "id": "GHSA-x3m5-8xj2-gwpg",
  "modified": "2025-03-18T21:32:01Z",
  "published": "2025-03-18T21:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-25040"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpesc/public/docDisplay?docId=hpesbnw04818en_us\u0026docLocale=en_US"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-X3R8-2HMH-89F5

Vulnerability from github – Published: 2025-12-17 21:30 – Updated: 2025-12-26 15:17
VLAI
Summary
Mattermost has an Invite Token Replay Vulnerability via Channel Membership Manipulation
Details

Mattermost versions 10.11.x < 10.11.5, 11.0.x < 11.0.4, 10.12.x < 10.12.2 fail to invalidate remote cluster invite tokens when using the legacy (version 1) protocol or when the confirming party does not provide a refreshed token, which allows an attacker who has obtained an invite token to authenticate as the remote cluster and perform limited actions on shared channels even after the invitation has been legitimately confirmed.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.12.0"
            },
            {
              "fixed": "10.12.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.11.0-rc1"
            },
            {
              "fixed": "10.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-alpha.1"
            },
            {
              "fixed": "11.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20251031095924-e7e23b94e006"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 5.3.2-0.20251028000919-d3ed703dc833"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "11.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-13324"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-20T17:27:10Z",
    "nvd_published_at": "2025-12-17T19:16:01Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.11.x \u003c 10.11.5, 11.0.x \u003c 11.0.4, 10.12.x \u003c 10.12.2 fail to invalidate remote cluster invite tokens when using the legacy (version 1) protocol or when the confirming party does not provide a refreshed token, which allows an attacker who has obtained an invite token to authenticate as the remote cluster and perform limited actions on shared channels even after the invitation has been legitimately confirmed.",
  "id": "GHSA-x3r8-2hmh-89f5",
  "modified": "2025-12-26T15:17:57Z",
  "published": "2025-12-17T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13324"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/364c2203de00fe0d8424b6b46d6f0eeb02a2539a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/7ccb62db7958abd6a4b21a06c5a4f5367a8f8b1f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/9f54e5cdc3aef412945ff0e6a58338f7b549bdda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mattermost/mattermost"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "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"
    }
  ],
  "summary": "Mattermost has an Invite Token Replay Vulnerability via Channel Membership Manipulation"
}

GHSA-X3VF-FCQ8-6CPG

Vulnerability from github – Published: 2022-05-24 19:13 – Updated: 2025-10-22 00:32
VLAI
Details

A permissions issue was addressed with improved validation. This issue is fixed in macOS Big Sur 11.4. A malicious application may be able to bypass Privacy preferences. Apple is aware of a report that this issue may have been actively exploited..

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-30713"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-862",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-09-08T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A permissions issue was addressed with improved validation. This issue is fixed in macOS Big Sur 11.4. A malicious application may be able to bypass Privacy preferences. Apple is aware of a report that this issue may have been actively exploited..",
  "id": "GHSA-x3vf-fcq8-6cpg",
  "modified": "2025-10-22T00:32:19Z",
  "published": "2022-05-24T19:13:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-30713"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT212529"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT212805"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-30713"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2021/Sep/40"
    }
  ],
  "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-X3VF-MGXJ-7785

Vulnerability from github – Published: 2026-06-25 22:01 – Updated: 2026-06-25 22:01
VLAI
Summary
Lemur Privilege Escalation: Non-admin role members can rewrite role membership via PUT /api/1/roles/<id>
Details

Summary

The PUT /api/1/roles/<id> handler in lemur/roles/views.py gates only on RoleMemberPermission(role_id).can(), which is satisfied for any user who is already a member of the target role. The handler then passes data["users"] and data["name"] directly to service.update(), permitting any role member to rewrite that role's membership list and name. The companion DELETE handler on the same resource is correctly gated by @admin_permission.require; the asymmetry between PUT and DELETE on identical resources indicates an authorization oversight rather than a deliberate design choice.

Root Cause

lemur/roles/views.py:298:

permission = RoleMemberPermission(role_id)
if permission.can():
    return service.update(
        role_id, data["name"], data.get("description"), data.get("users")
    )
return dict(message="You are not authorized to modify this role."), 403

@admin_permission.require(http_exception=403)
def delete(self, role_id):
    ...

lemur/auth/permissions.py:56:

class RoleMemberPermission(Permission):
    def __init__(self, role_id):
        needs = [RoleNeed("admin"), RoleMemberNeed(role_id)]
        super().__init__(*needs)

flask_principal.Permission.allows() is OR-semantic across needs, so RoleMemberPermission(role_id).can() returns True if the caller is either an admin or a member of role_id. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not.

Affected Endpoints

Method Path Source
PUT /api/1/roles/<id> lemur/roles/views.py:298

Impact

A user who is a member of role X can:

  • Add other users to role X, granting them whatever certificate/authority access role X confers. In installs that delegate certificate or authority ownership to non-admin roles, this promotes arbitrary users to peer of every other role member.
  • Remove other users from role X, denying their access (availability / governance impact).
  • Rename role X to an arbitrary string. The "rename to admin" path is blocked by the unique=True constraint on Role.name and by strict equality in User.is_admin, so direct self-promotion to admin via rename is not possible on default installs. The principal exploitation surface is membership rewriting and lateral promotion of colluders within roles the attacker already belongs to.

Remediation

Add @admin_permission.require(http_exception=403) to Roles.put, mirroring the existing decorator on Roles.delete:

@admin_permission.require(http_exception=403)
def put(self, role_id, data=None):
    ...

If selective delegation is intended (role owners managing their own roles), that capability should be modeled with a dedicated permission class whose Needs reflect role ownership rather than membership, and the name field should be excluded from the mutable schema on that delegated path.

Steps to Reproduce

  1. Set up Lemur with default configuration. Create an admin user admin, and two non-admin users alice and bob. Add alice to the built-in operator role; leave bob with no roles or with read-only only.
  2. Authenticate as alice and capture the JWT: curl -X POST https://lemur.local/api/1/auth/login \ -H "Content-Type: application/json" \ -d '{"username":"alice","password":"<alice_pw>"}'

  3. Confirm the initial state - bob is not a member of operator: curl https://lemur.local/api/1/roles?filter=name;operator \ -H "Authorization: Bearer <admin_jwt>" # observe: alice present in users list, bob absent

  4. As alice, send a PUT that injects bob into the operator role: curl -X PUT https://lemur.local/api/1/roles/<operator_role_id> \ -H "Authorization: Bearer <alice_jwt>" \ -H "Content-Type: application/json" \ -d '{ "name": "operator", "description": "modified by alice", "users": [{"id": <alice_id>}, {"id": <bob_id>}] }' # observe: HTTP 200

  5. Confirm bob is now a member of operator: curl https://lemur.local/api/1/roles?filter=name;operator \ -H "Authorization: Bearer <admin_jwt>" # observe: bob now present in users list

Step 4 succeeds despite alice not being an admin. The same handler also accepts a name field; substituting "name": "operator_v2" in step 4 renames the role, demonstrating the second variant of the bug.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.9.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "lemur"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55163"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-25T22:01:18Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n \nThe `PUT /api/1/roles/\u003cid\u003e` handler in `lemur/roles/views.py` gates only on `RoleMemberPermission(role_id).can()`, which is satisfied for any user who is already a member of the target role. The handler then passes `data[\"users\"]` and `data[\"name\"]` directly to `service.update()`, permitting any role member to rewrite that role\u0027s membership list and name. The companion `DELETE` handler on the same resource is correctly gated by `@admin_permission.require`; the asymmetry between PUT and DELETE on identical resources indicates an authorization oversight rather than a deliberate design choice.\n \n## Root Cause\n \n`lemur/roles/views.py:298`:\n \n```python\npermission = RoleMemberPermission(role_id)\nif permission.can():\n    return service.update(\n        role_id, data[\"name\"], data.get(\"description\"), data.get(\"users\")\n    )\nreturn dict(message=\"You are not authorized to modify this role.\"), 403\n \n@admin_permission.require(http_exception=403)\ndef delete(self, role_id):\n    ...\n```\n \n`lemur/auth/permissions.py:56`:\n \n```python\nclass RoleMemberPermission(Permission):\n    def __init__(self, role_id):\n        needs = [RoleNeed(\"admin\"), RoleMemberNeed(role_id)]\n        super().__init__(*needs)\n```\n \n`flask_principal.Permission.allows()` is OR-semantic across needs, so `RoleMemberPermission(role_id).can()` returns `True` if the caller is either an admin **or** a member of `role_id`. The PUT handler treats membership-of-self as sufficient to mutate the role; DELETE does not.\n \n## Affected Endpoints\n \n| Method | Path | Source |\n|---|---|---|\n| PUT | /api/1/roles/`\u003cid\u003e` | lemur/roles/views.py:298 |\n \n## Impact\n \nA user who is a member of role X can:\n \n- **Add other users to role X**, granting them whatever certificate/authority access role X confers. In installs that delegate certificate or authority ownership to non-admin roles, this promotes arbitrary users to peer of every other role member.\n- **Remove other users from role X**, denying their access (availability / governance impact).\n- **Rename role X** to an arbitrary string.\nThe \"rename to admin\" path is blocked by the `unique=True` constraint on `Role.name` and by strict equality in `User.is_admin`, so direct self-promotion to admin via rename is not possible on default installs. The principal exploitation surface is membership rewriting and lateral promotion of colluders within roles the attacker already belongs to.\n \n## Remediation\n \nAdd `@admin_permission.require(http_exception=403)` to `Roles.put`, mirroring the existing decorator on `Roles.delete`:\n \n```python\n@admin_permission.require(http_exception=403)\ndef put(self, role_id, data=None):\n    ...\n```\n \nIf selective delegation is intended (role owners managing their own roles), that capability should be modeled with a dedicated permission class whose Needs reflect role *ownership* rather than membership, and the `name` field should be excluded from the mutable schema on that delegated path.\n \n## Steps to Reproduce\n \n1. Set up Lemur with default configuration. Create an admin user `admin`, and two non-admin users `alice` and `bob`. Add `alice` to the built-in `operator` role; leave `bob` with no roles or with `read-only` only.\n2. Authenticate as `alice` and capture the JWT:\n   ```\n   curl -X POST https://lemur.local/api/1/auth/login \\\n        -H \"Content-Type: application/json\" \\\n        -d \u0027{\"username\":\"alice\",\"password\":\"\u003calice_pw\u003e\"}\u0027\n   ```\n \n3. Confirm the initial state - `bob` is not a member of `operator`:\n   ```\n   curl https://lemur.local/api/1/roles?filter=name;operator \\\n        -H \"Authorization: Bearer \u003cadmin_jwt\u003e\"\n   # observe: alice present in users list, bob absent\n   ```\n \n4. As `alice`, send a PUT that injects `bob` into the `operator` role:\n   ```\n   curl -X PUT https://lemur.local/api/1/roles/\u003coperator_role_id\u003e \\\n        -H \"Authorization: Bearer \u003calice_jwt\u003e\" \\\n        -H \"Content-Type: application/json\" \\\n        -d \u0027{\n              \"name\": \"operator\",\n              \"description\": \"modified by alice\",\n              \"users\": [{\"id\": \u003calice_id\u003e}, {\"id\": \u003cbob_id\u003e}]\n            }\u0027\n   # observe: HTTP 200\n   ```\n \n5. Confirm `bob` is now a member of `operator`:\n   ```\n   curl https://lemur.local/api/1/roles?filter=name;operator \\\n        -H \"Authorization: Bearer \u003cadmin_jwt\u003e\"\n   # observe: bob now present in users list\n   ```\n \nStep 4 succeeds despite `alice` not being an admin. The same handler also accepts a `name` field; substituting `\"name\": \"operator_v2\"` in step 4 renames the role, demonstrating the second variant of the bug.",
  "id": "GHSA-x3vf-mgxj-7785",
  "modified": "2026-06-25T22:01:18Z",
  "published": "2026-06-25T22:01:18Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/security/advisories/GHSA-x3vf-mgxj-7785"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Netflix/lemur"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/lemur/releases/tag/v1.9.2"
    }
  ],
  "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"
    }
  ],
  "summary": "Lemur Privilege Escalation: Non-admin role members can rewrite role membership via PUT /api/1/roles/\u003cid\u003e"
}

GHSA-X3X9-349X-2485

Vulnerability from github – Published: 2024-11-18 12:30 – Updated: 2024-11-20 18:25
VLAI
Summary
moodle: IDOR in edit/delete RSS feed
Details

A vulnerability was found in Moodle. Additional checks are required to ensure users can only edit or delete RSS feeds that they have permission to modify.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.2.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3.0"
            },
            {
              "fixed": "4.3.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4.0"
            },
            {
              "fixed": "4.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48897"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-11-18T23:46:24Z",
    "nvd_published_at": "2024-11-18T12:15:18Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Moodle. Additional checks are required to ensure users can only edit or delete RSS feeds that they have permission to modify.",
  "id": "GHSA-x3x9-349x-2485",
  "modified": "2024-11-20T18:25:07Z",
  "published": "2024-11-18T12:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48897"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2318821"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "moodle: IDOR in edit/delete RSS feed"
}

GHSA-X44P-GG67-52FC

Vulnerability from github – Published: 2026-06-19 00:31 – Updated: 2026-06-19 21:32
VLAI
Summary
Duplicate Advisory: PraisonAI: Coarse-Grained Tool Approval Cache Bypasses Per-Invocation Consent for Shell Commands
Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ffp3-3562-8cv3. This link is maintained to preserve external references.

Original Description

PraisonAI before 1.5.128 caches tool approval decisions by tool name only, not by invocation arguments, allowing subsequent execute_command calls to bypass approval prompts. Attackers can exploit this by obtaining initial approval for a benign command, then silently exfiltrate API keys and credentials via subsequent shell commands without user consent.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 4.5.128"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:32:50Z",
    "nvd_published_at": "2026-06-18T23:16:19Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-ffp3-3562-8cv3. This link is maintained to preserve external references.\n\n## Original Description\nPraisonAI before 1.5.128 caches tool approval decisions by tool name only, not by invocation arguments, allowing subsequent execute_command calls to bypass approval prompts. Attackers can exploit this by obtaining initial approval for a benign command, then silently exfiltrate API keys and credentials via subsequent shell commands without user consent.",
  "id": "GHSA-x44p-gg67-52fc",
  "modified": "2026-06-19T21:32:50Z",
  "published": "2026-06-19T00:31:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-ffp3-3562-8cv3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56074"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-tool-approval-cache-bypass-via-coarse-grained-caching"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/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"
    }
  ],
  "summary": "Duplicate Advisory: PraisonAI: Coarse-Grained Tool Approval Cache Bypasses Per-Invocation Consent for Shell Commands",
  "withdrawn": "2026-06-19T21:32:50Z"
}

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.