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.

5678 vulnerabilities reference this CWE, most recent first.

GHSA-JR83-M233-GG6P

Vulnerability from github – Published: 2024-03-04 20:45 – Updated: 2024-03-06 21:37
VLAI
Summary
Sulu grants access to pages regardless of role permissions
Details

Impact

What kind of vulnerability is it? Who is impacted?

Access to pages is granted regardless of role permissions for webspaces which have a security system configured and permission check enabled. Webspaces without do not have this issue.

Patches

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

The problem is patched with Version 2.4.17 and 2.5.13.

Workarounds

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

Remove following lines from vendor/symfony/security-http/HttpUtils.php:

-            // Shortcut if request has already been matched before
-            if ($request->attributes->has('_route')) {
-                return $path === $request->attributes->get('_route');
 -           }

Or do not install symfony/security-http versions greater equal than v5.4.30 or v6.3.6.

References

Are there any links users can visit to find out more?

Currently no references.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sulu/sulu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.4.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "sulu/sulu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0-alpha1"
            },
            {
              "fixed": "2.5.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-27915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-03-04T20:45:08Z",
    "nvd_published_at": "2024-03-06T20:15:47Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\n_What kind of vulnerability is it? Who is impacted?_\n\nAccess to pages is granted regardless of role permissions for webspaces which have a security system configured and permission check enabled. Webspaces without do not have this issue.\n\n### Patches\n\nHas the problem been patched? What versions should users upgrade to?\n\nThe problem is patched with Version `2.4.17` and `2.5.13`.\n\n### Workarounds\n\n_Is there a way for users to fix or remediate the vulnerability without upgrading?_\n\nRemove  following lines from `vendor/symfony/security-http/HttpUtils.php`:\n\n```\n-            // Shortcut if request has already been matched before\n-            if ($request-\u003eattributes-\u003ehas(\u0027_route\u0027)) {\n-                return $path === $request-\u003eattributes-\u003eget(\u0027_route\u0027);\n -           }\n```\n\nOr do not install `symfony/security-http` versions greater equal than `v5.4.30` or `v6.3.6`.\n\n### References\n\n_Are there any links users can visit to find out more?_\n\nCurrently no references.\n",
  "id": "GHSA-jr83-m233-gg6p",
  "modified": "2024-03-06T21:37:49Z",
  "published": "2024-03-04T20:45:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sulu/sulu/security/advisories/GHSA-jr83-m233-gg6p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27915"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sulu/sulu/commit/ec9c3f99e15336dc4f6877f512300f231c17c6da"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sulu/sulu"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Sulu grants access to pages regardless of role permissions"
}

GHSA-JR8X-R7FP-7RP4

Vulnerability from github – Published: 2024-10-19 00:31 – Updated: 2024-10-19 00:31
VLAI
Details

Ivanti DSM < version 2024.2 allows authenticated users on the local machine to run code with elevated privileges due to insecure ACL via unspecified attack vector.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-29213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-18T23:15:03Z",
    "severity": "HIGH"
  },
  "details": "Ivanti DSM \u003c version 2024.2 allows authenticated users on the local machine to run code with elevated privileges due to insecure ACL via unspecified attack vector.",
  "id": "GHSA-jr8x-r7fp-7rp4",
  "modified": "2024-10-19T00:31:54Z",
  "published": "2024-10-19T00:31:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29213"
    },
    {
      "type": "WEB",
      "url": "https://forums.ivanti.com/s/article/SA-2024-07-12-CVE-2024-29213"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JRC5-W569-H7H5

Vulnerability from github – Published: 2026-05-06 20:37 – Updated: 2026-06-09 00:01
VLAI
Summary
phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check in phpMyFAQ
Details

Summary

A review of phpMyFAQ-main uncovered an authorization issue in the admin-api routes.

Several backend endpoints only check whether the caller is logged in. They do not verify that the caller actually has backend or administrative privileges. As a result, a normal frontend user can access API endpoints that are clearly intended for administrative use.

During local reproduction, a regular user account was able to request /admin/api/index.php/dashboard/versions and receive a successful response from the backend management API.

This issue does not appear to give direct write access in the affected paths that were confirmed, so it should be treated as a backend information disclosure and privilege boundary failure rather than full admin compromise.

Details

The access control split is visible in the controller base class:

public function userIsAuthenticated(): void
{
    if (!$this->currentUser->isLoggedIn()) {
        throw new UnauthorizedHttpException('Unauthorized access.');
    }
}

protected function userHasPermission(PermissionType $permissionType): void
{
    // permission-based check
}

The problem is that several Administration\Api controllers use the weaker check even though the routes sit under the backend API namespace.

For example, phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/DashboardController.php exposes:

#[Route(path: 'dashboard/versions', name: 'admin.api.dashboard.versions', methods: ['GET'])]
public function versions(): JsonResponse
{
    $this->userIsAuthenticated();
    ...
}

The same pattern appears in other backend-facing controllers, including:

  • LdapController
  • ElasticsearchController
  • OpenSearchController
  • UpdateController

That matters because these endpoints are not part of the normal frontend feature set. They expose backend operational data such as version checks, upgrade state, LDAP configuration, health checks, and search backend status.

Three examples that stand out from an impact perspective are:

  1. GET /admin/api/index.php/ldap/configuration

This can expose LDAP server configuration, mapping settings, group settings, and general authentication-related options. Even with secrets masked, this is still useful internal infrastructure information.

  1. GET /admin/api/index.php/elasticsearch/statistics

If Elasticsearch is enabled, this can expose index names and search backend statistics that should normally stay in the admin area.

  1. GET /admin/api/index.php/health-check

This is part of the update and maintenance workflow and can reveal operational state that ordinary users should not be able to inspect.

In other words, the issue is not that guests can reach the backend. The issue is that any ordinary authenticated user can cross the frontend/backend privilege boundary.

PoC

I reproduced this against a local Docker deployment of the project.

First, an unauthenticated request to the backend API is rejected:

GET /admin/api/index.php/dashboard/versions HTTP/1.1
Host: 127.0.0.1
Accept: application/json

Response:

HTTP/1.0 401 Unauthorized
Content-Type: application/problem+json

{
  "type": "http://127.0.0.1/problems/unauthorized",
  "title": "Unauthorized",
  "status": 401,
  "detail": "Unauthorized access.",
  "instance": "/dashboard/versions"
}

Logged in with a normal frontend account:

  • username: user1
  • password: User12345!

After login, the same request was sent with the user session cookie:

GET /admin/api/index.php/dashboard/versions HTTP/1.1
Host: 127.0.0.1
Cookie: PHPSESSID=<regular-user-session>
Accept: application/json

Response:

HTTP/1.0 200 OK
Content-Type: application/json

{"success":"Latest version available: phpMyFAQ 4.1.1"}

That is enough to show that a non-admin account can call at least one backend management endpoint successfully.

Impact

The main impact is unauthorized access to backend-only operational information.

Depending on which optional features are enabled in a real deployment, this may let a normal user learn:

  • upgrade and version status
  • maintenance or health-check information
  • LDAP environment details
  • Elasticsearch or OpenSearch backend status and statistics
  • internal administrative diagnostics

This was rated as Medium severity.

It was not categorized as High severity because the testing done did not confirm a direct administrative state change through the affected read-oriented endpoints. Still, this is a real privilege separation failure. A frontend account should not be able to query backend admin APIs simply because it has a valid session.

Remediation

The suggested approach should fix this in two layers.

  1. Replace userIsAuthenticated() with explicit permission checks on backend endpoints that are intended for administrators only.
  2. Review all Administration\Api controllers for similar cases and make the access model consistent.
  3. Keep backend operational endpoints separated from ordinary user sessions unless there is a strong business reason to expose them.
  4. Add regression tests that log in as a low-privileged user and verify that backend routes return 403 or 401 where appropriate.
Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "thorsten/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.1"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.1.1"
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyfaq/phpmyfaq"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.1.1"
            },
            {
              "fixed": "4.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "4.1.1"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T20:37:42Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA review of `phpMyFAQ-main` uncovered an authorization issue in the `admin-api` routes.\n\nSeveral backend endpoints only check whether the caller is logged in. They do not verify that the caller actually has backend or administrative privileges. As a result, a normal frontend user can access API endpoints that are clearly intended for administrative use.\n\nDuring local reproduction, a regular user account was able to request `/admin/api/index.php/dashboard/versions` and receive a successful response from the backend management API.\n\nThis issue does not appear to give direct write access in the affected paths that were confirmed, so it should be treated as a backend information disclosure and privilege boundary failure rather than full admin compromise.\n\n### Details\n\nThe access control split is visible in the controller base class:\n\n```php\npublic function userIsAuthenticated(): void\n{\n    if (!$this-\u003ecurrentUser-\u003eisLoggedIn()) {\n        throw new UnauthorizedHttpException(\u0027Unauthorized access.\u0027);\n    }\n}\n\nprotected function userHasPermission(PermissionType $permissionType): void\n{\n    // permission-based check\n}\n```\n\nThe problem is that several `Administration\\Api` controllers use the weaker check even though the routes sit under the backend API namespace.\n\nFor example, `phpmyfaq/src/phpMyFAQ/Controller/Administration/Api/DashboardController.php` exposes:\n\n```php\n#[Route(path: \u0027dashboard/versions\u0027, name: \u0027admin.api.dashboard.versions\u0027, methods: [\u0027GET\u0027])]\npublic function versions(): JsonResponse\n{\n    $this-\u003euserIsAuthenticated();\n    ...\n}\n```\n\nThe same pattern appears in other backend-facing controllers, including:\n\n- `LdapController`\n- `ElasticsearchController`\n- `OpenSearchController`\n- `UpdateController`\n\nThat matters because these endpoints are not part of the normal frontend feature set. They expose backend operational data such as version checks, upgrade state, LDAP configuration, health checks, and search backend status.\n\nThree examples that stand out from an impact perspective are:\n\n1. `GET /admin/api/index.php/ldap/configuration`\n\n   This can expose LDAP server configuration, mapping settings, group settings, and general authentication-related options. Even with secrets masked, this is still useful internal infrastructure information.\n\n2. `GET /admin/api/index.php/elasticsearch/statistics`\n\n   If Elasticsearch is enabled, this can expose index names and search backend statistics that should normally stay in the admin area.\n\n3. `GET /admin/api/index.php/health-check`\n\n   This is part of the update and maintenance workflow and can reveal operational state that ordinary users should not be able to inspect.\n\nIn other words, the issue is not that guests can reach the backend. The issue is that any ordinary authenticated user can cross the frontend/backend privilege boundary.\n\n### PoC\n\nI reproduced this against a local Docker deployment of the project.\n\nFirst, an unauthenticated request to the backend API is rejected:\n\n```http\nGET /admin/api/index.php/dashboard/versions HTTP/1.1\nHost: 127.0.0.1\nAccept: application/json\n```\n\nResponse:\n\n```http\nHTTP/1.0 401 Unauthorized\nContent-Type: application/problem+json\n\n{\n  \"type\": \"http://127.0.0.1/problems/unauthorized\",\n  \"title\": \"Unauthorized\",\n  \"status\": 401,\n  \"detail\": \"Unauthorized access.\",\n  \"instance\": \"/dashboard/versions\"\n}\n```\n\nLogged in with a normal frontend account:\n\n- username: `user1`\n- password: `User12345!`\n\nAfter login, the same request was sent with the user session cookie:\n\n```http\nGET /admin/api/index.php/dashboard/versions HTTP/1.1\nHost: 127.0.0.1\nCookie: PHPSESSID=\u003cregular-user-session\u003e\nAccept: application/json\n```\n\nResponse:\n\n```http\nHTTP/1.0 200 OK\nContent-Type: application/json\n\n{\"success\":\"Latest version available: phpMyFAQ 4.1.1\"}\n```\n\nThat is enough to show that a non-admin account can call at least one backend management endpoint successfully.\n\n### Impact\n\nThe main impact is unauthorized access to backend-only operational information.\n\nDepending on which optional features are enabled in a real deployment, this may let a normal user learn:\n\n- upgrade and version status\n- maintenance or health-check information\n- LDAP environment details\n- Elasticsearch or OpenSearch backend status and statistics\n- internal administrative diagnostics\n\nThis was rated as **Medium** severity.\n\nIt was not categorized as **High** severity because the testing done did not confirm a direct administrative state change through the affected read-oriented endpoints. Still, this is a real privilege separation failure. A frontend account should not be able to query backend admin APIs simply because it has a valid session.\n\n### Remediation\n\nThe suggested approach should fix this in two layers.\n\n1. Replace `userIsAuthenticated()` with explicit permission checks on backend endpoints that are intended for administrators only.\n2. Review all `Administration\\Api` controllers for similar cases and make the access model consistent.\n3. Keep backend operational endpoints separated from ordinary user sessions unless there is a strong business reason to expose them.\n4. Add regression tests that log in as a low-privileged user and verify that backend routes return `403` or `401` where appropriate.",
  "id": "GHSA-jrc5-w569-h7h5",
  "modified": "2026-06-09T00:01:48Z",
  "published": "2026-05-06T20:37:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/thorsten/phpMyFAQ/security/advisories/GHSA-jrc5-w569-h7h5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45009"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/thorsten/phpMyFAQ"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/phpmyfaq-insufficient-authorization-check-in-admin-api-endpoints"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpMyFAQ: Ordinary Authenticated User Can Access Admin-Only API Endpoints Due to Insufficient Authorization Check in phpMyFAQ"
}

GHSA-JRRV-JM33-8JRV

Vulnerability from github – Published: 2022-05-24 19:12 – Updated: 2022-05-24 19:12
VLAI
Details

Improper authorization in the vulnerability report feature in GitLab EE affecting all versions since 13.1 allowed a reporter to access vulnerability data

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-22244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-25T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper authorization in the vulnerability report feature in GitLab EE affecting all versions since 13.1 allowed a reporter to access vulnerability data",
  "id": "GHSA-jrrv-jm33-8jrv",
  "modified": "2022-05-24T19:12:10Z",
  "published": "2022-05-24T19:12:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22244"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/1047140"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22244.json"
    },
    {
      "type": "WEB",
      "url": "https://gitlab.com/gitlab-org/gitlab/-/issues/299039"
    }
  ],
  "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"
    }
  ]
}

GHSA-JRX5-RPF5-27W3

Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2022-05-24 17:21
VLAI
Details

An issue was discovered in Mattermost Plugins before 5.13.0. The GitHub plugin allows an attacker to attach his Mattermost account to a different person's GitHub account.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-20864"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-06-19T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Mattermost Plugins before 5.13.0. The GitHub plugin allows an attacker to attach his Mattermost account to a different person\u0027s GitHub account.",
  "id": "GHSA-jrx5-rpf5-27w3",
  "modified": "2022-05-24T17:21:12Z",
  "published": "2022-05-24T17:21:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20864"
    },
    {
      "type": "WEB",
      "url": "https://mattermost.com/security-updates"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-JV3C-WR43-XGX8

Vulnerability from github – Published: 2023-05-12 12:30 – Updated: 2024-04-04 04:03
VLAI
Details

An issue found in Webroot SecureAnywhere Endpoint Protection CE 23.1 v.9.0.33.39 and before allows a local attacker to bypass protections via the default allowlist feature being stored as non-admin.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-29818"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-12T11:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue found in Webroot SecureAnywhere Endpoint Protection CE 23.1 v.9.0.33.39 and before allows a local attacker to bypass protections via the default allowlist feature being stored as non-admin.",
  "id": "GHSA-jv3c-wr43-xgx8",
  "modified": "2024-04-04T04:03:40Z",
  "published": "2023-05-12T12:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29818"
    },
    {
      "type": "WEB",
      "url": "https://www.spenceralessi.com/CVEs/2023-05-10-Webroot-SecureAnywhere"
    },
    {
      "type": "WEB",
      "url": "http://secureanywhere.com"
    },
    {
      "type": "WEB",
      "url": "http://webroot.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV3H-VGC4-3286

Vulnerability from github – Published: 2023-03-29 21:30 – Updated: 2023-04-06 18:30
VLAI
Details

This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within readycloud_control.cgi. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-15762.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-27645"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-697",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-03-29T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability allows network-adjacent attackers to bypass authentication on affected installations of NETGEAR R6700v3 1.0.4.120_10.0.91 routers. Authentication is not required to exploit this vulnerability. The specific flaw exists within readycloud_control.cgi. The issue results from incorrect string matching logic when accessing protected pages. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-15762.",
  "id": "GHSA-jv3h-vgc4-3286",
  "modified": "2023-04-06T18:30:18Z",
  "published": "2023-03-29T21:30:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-27645"
    },
    {
      "type": "WEB",
      "url": "https://kb.netgear.com/000064722/Security-Advisory-for-Sensitive-Information-Disclosure-on-Some-Routers-and-Fixed-Wireless-Products-PSV-2021-0325"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-22-522"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV46-GR4P-7XP9

Vulnerability from github – Published: 2025-02-18 18:33 – Updated: 2025-02-18 18:33
VLAI
Details

Insecure Permissions in Atos Eviden IDRA and IDCA before 2.7.0. A highly trusted role (Config Admin) could exceed their configuration privileges in a multi-partition environment and access some confidential data. Data integrity and availability is not at risk.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-39328"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-18T18:15:20Z",
    "severity": "MODERATE"
  },
  "details": "Insecure Permissions in Atos Eviden IDRA and IDCA before 2.7.0. A highly trusted role (Config Admin) could exceed their configuration privileges in a multi-partition environment and access some confidential data. Data integrity and availability is not at risk.",
  "id": "GHSA-jv46-gr4p-7xp9",
  "modified": "2025-02-18T18:33:21Z",
  "published": "2025-02-18T18:33:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39328"
    },
    {
      "type": "WEB",
      "url": "https://eviden.com/solutions/digital-security/digital-identity"
    },
    {
      "type": "WEB",
      "url": "https://support.bull.com/ols/product/security/psirt/security-bulletins/potential-privilege-escalation-in-idpki-psirt-1335-tlp-clear-version-2-10-cve-2024-39327-cve-2024-39328-cve-2024-51505/view"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JV6R-27WW-4GW4

Vulnerability from github – Published: 2026-03-03 19:17 – Updated: 2026-03-25 18:42
VLAI
Summary
OpenClaw DM pairing-store identities could satisfy group allowlist authorization
Details

Summary

DM pairing-store identities were incorrectly eligible for group allowlist authorization checks, enabling cross-context authorization in group message paths.

Details

In affected versions, group allowlist evaluation could inherit identities from the DM pairing store. A sender approved via DM pairing could satisfy group sender allowlist checks without being explicitly present in groupAllowFrom.

This is an authorization-policy boundary issue between DM pairing and group allowlists.

Affected Packages / Versions

  • openclaw (npm): affected <= 2026.2.25 (latest published npm version at triage time)
  • openclaw (npm): patched >= 2026.2.26 (planned next release)

Fix Commit(s)

  • openclaw/openclaw@8bdda7a651c21e98faccdbbd73081e79cffe8be0
  • openclaw/openclaw@051fdcc428129446e7c084260f837b7284279ce9

Release Process Note

patched_versions is pre-set to the planned next release (2026.2.26) so once npm release is published, maintainers can publish the advisory without additional metadata edits.

Maintainer Timeline Note

Maintainers landed the initial fix before this report was filed; this report still provided useful independent confirmation of the issue class and exploit path.

OpenClaw thanks @tdjackey for reporting.

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
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.2.25"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.26"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32027"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T19:17:22Z",
    "nvd_published_at": "2026-03-19T22:16:37Z",
    "severity": "HIGH"
  },
  "details": "## Summary\nDM pairing-store identities were incorrectly eligible for group allowlist authorization checks, enabling cross-context authorization in group message paths.\n\n## Details\nIn affected versions, group allowlist evaluation could inherit identities from the DM pairing store. A sender approved via DM pairing could satisfy group sender allowlist checks without being explicitly present in `groupAllowFrom`.\n\nThis is an authorization-policy boundary issue between DM pairing and group allowlists.\n\n## Affected Packages / Versions\n- `openclaw` (npm): affected `\u003c= 2026.2.25` (latest published npm version at triage time)\n- `openclaw` (npm): patched `\u003e= 2026.2.26` (planned next release)\n\n## Fix Commit(s)\n- `openclaw/openclaw@8bdda7a651c21e98faccdbbd73081e79cffe8be0`\n- `openclaw/openclaw@051fdcc428129446e7c084260f837b7284279ce9`\n\n## Release Process Note\n`patched_versions` is pre-set to the planned next release (`2026.2.26`) so once npm release is published, maintainers can publish the advisory without additional metadata edits.\n\n## Maintainer Timeline Note\nMaintainers landed the initial fix before this report was filed; this report still provided useful independent confirmation of the issue class and exploit path.\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-jv6r-27ww-4gw4",
  "modified": "2026-03-25T18:42:22Z",
  "published": "2026-03-03T19:17:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jv6r-27ww-4gw4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32027"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/051fdcc428129446e7c084260f837b7284279ce9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/8bdda7a651c21e98faccdbbd73081e79cffe8be0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-improper-authorization-via-dm-pairing-store-identity-inheritance-in-group-allowlist"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw DM pairing-store identities could satisfy group allowlist authorization"
}

GHSA-JVM4-4J77-39P6

Vulnerability from github – Published: 2026-07-02 16:34 – Updated: 2026-07-02 16:34
VLAI
Summary
OpenClaw: QQBot streaming command could mutate config without explicit allowFrom
Details

Summary

QQBot streaming command could mutate config without explicit allowFrom. In affected versions, a QQBot sender reaching the affected command could change configuration without requiring an explicit non-wildcard allowlist entry.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could modify QQBot streaming configuration outside the intended admin policy. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.4.29.

Mitigations

disable the command or restrict it to explicit trusted QQBot senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.27"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T16:34:39Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nQQBot streaming command could mutate config without explicit allowFrom. In affected versions, a QQBot sender reaching the affected command could change configuration without requiring an explicit non-wildcard allowlist entry.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could modify QQBot streaming configuration outside the intended admin policy. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.29`.\n\n### Mitigations\n\ndisable the command or restrict it to explicit trusted QQBot senders until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-jvm4-4j77-39p6",
  "modified": "2026-07-02T16:34:39Z",
  "published": "2026-07-02T16:34:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jvm4-4j77-39p6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: QQBot streaming command could mutate config without explicit allowFrom"
}
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