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.

5657 vulnerabilities reference this CWE, most recent first.

GHSA-4M6G-RPHV-P56X

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

There is a Permission Control Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may cause certain codes to be executed.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-22389"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-02T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "There is a Permission Control Vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability may cause certain codes to be executed.",
  "id": "GHSA-4m6g-rphv-p56x",
  "modified": "2022-05-24T19:09:33Z",
  "published": "2022-05-24T19:09:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22389"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2021/6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4M8P-XFJ4-439M

Vulnerability from github – Published: 2023-05-18 18:30 – Updated: 2024-04-04 04:14
VLAI
Details

An issue in Zammad v5.4.0 allows attackers to bypass e-mail verification using an arbitrary address and manipulate the data of the generated user. Attackers are also able to gain unauthorized access to existing tickets.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-31597"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-18T18:15:10Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Zammad v5.4.0 allows attackers to bypass e-mail verification using an arbitrary address and manipulate the data of the generated user. Attackers are also able to gain unauthorized access to existing tickets.",
  "id": "GHSA-4m8p-xfj4-439m",
  "modified": "2024-04-04T04:14:24Z",
  "published": "2023-05-18T18:30:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31597"
    },
    {
      "type": "WEB",
      "url": "https://zammad.com/de/advisories/zaa-2023-03"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4M8Q-55QV-9PWP

Vulnerability from github – Published: 2026-07-13 23:55 – Updated: 2026-07-13 23:55
VLAI
Summary
Kimai: Teamlead authorization bypass in GET /api/timesheets allows reading other users' timesheet records without being teamlead of the target
Details

Summary

GET /api/timesheets?user=<id> (and users[]=<id>) returns the targeted user's timesheet records to any caller that has the view_other_timesheet permission, without verifying that the caller is teamlead of any team containing the target user. The per-record endpoint GET /api/timesheets/{id} correctly enforces this check via TimesheetVoter/RolePermissionManager::checkTeamAccessTimesheet → checkTeamLeadAccess, but the list endpoint only filters projects/customers by team membership and never validates t.user. A ROLE_TEAMLEAD user can therefore enumerate any user's records — including the rate field — as long as those records are on a project with no team scoping (Kimai's default) or on any project that shares any team (membership, not lead) with the requester.

Details

Root cause: authorization mismatch between the per-record voter and the list endpoint.

Per-record path (correct)

src/Voter/TimesheetVoter.php:138:

if (!$this->permissionManager->checkTeamAccessTimesheet($subject, $user)) {
    return false;
}
return $this->permissionManager->hasRolePermission($user, $permission . '_other_timesheet');

checkTeamLeadAccess (RolePermissionManager.php:143-160) requires isTeamleadOf (not just member) one of the target user's teams. The unit test testTeamleadDeniedWhenOnlyPlainMemberOfOwnerTeam (tests/Voter/TimesheetVoterTest.php:253-269) codifies this:

"a TEAMLEAD role with view_other_timesheet must not access another user's timesheet by being a plain team member — they must be the team's teamlead."

List path (vulnerable)

src/API/TimesheetController.php:97-119:

public function cgetAction(ParamFetcherInterface $paramFetcher, ..., UserRepository $userRepository): Response
{
    $query = new TimesheetQuery(false);
    $this->prepareQuery($query, $paramFetcher);
    $seeAll = false;

    if ($this->isGranted('view_other_timesheet')) {
        /** @var array<int> $users */
        $users = $paramFetcher->get('users');
        $userId = $paramFetcher->get('user');

        if ('all' === $userId) {
            $seeAll = true;
        } elseif (\is_string($userId) && $userId !== '') {
            $users[] = (int) $userId;
        }

        if (!$seeAll) {
            foreach ($userRepository->findByIds($users) as $user) {
                $query->addUser($user);   // <-- no teamlead-of-target check
            }
        }
    }
    ...

config/packages/kimai.yaml:96,115 grants TIMESHEET_OTHER (which contains view_other_timesheet) to ROLE_TEAMLEAD, so the gate at line 103 passes for any teamlead. The user= / users[]= IDs are pushed straight into the query.

Net effect

For any victim bob who: - has at least one team that the requester alice is not teamlead of (so the voter denies per-record access), AND - has timesheets either on a project with no team (Kimai's default), or on a project that shares any team with alice (membership, not lead)

alice is denied via GET /api/timesheets/{id} but receives bob's records via GET /api/timesheets?user=<bob_id>.

Disclosed fields in the collection response include description, begin, end, duration, billable, exported, tags, rate, internalRate, plus project/activity/user IDs (Default/Collection serializer groups, Timesheet.php:164-173). rate is financial data that the per-record voter is supposed to gate via the separate view_rate_other_timesheet permission.

Why other proposed mitigations don't apply

  • The view_other_timesheet IsGranted on the route is the only authorization layer in the list path; ROLE_TEAMLEAD has it globally.
  • prepareQuery only sets currentUser, not authorization (BaseApiController.php:68-71).
  • The serializer does not filter rate per caller — it is a static Default-group property.
  • Recent commit 20c7b03 "Re-usable ACL checks on teams" hardened the voter side but left the list endpoint unchanged.

A PoC was provided, but removed for security reasons.

Impact

  • Authorization bypass: a ROLE_TEAMLEAD (a non-admin role typically granted to multiple users in a Kimai instance) can read any other user's timesheet records
  • Financial data disclosure: the rate and internalRate fields are returned in the collection serializer group, leaking what gets billed/costed against any user's records.
  • PII / activity disclosure: per-entry description, begin, end, duration, billable, exported, project/activity/customer IDs, and tags are leaked, allowing reconstruction of any user's activity timeline.

Solution

The list of requested user TimesheetController::cgetAction() is now guarded with the access_user permission. The access_user permission verifies that the requesting user is allowed to see each of the requested user. If any of the requested users may not be seen, the entire call will fail.

Find out more at https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp

Severity
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/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= 2.56.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.57.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52819"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-13T23:55:16Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n`GET /api/timesheets?user=\u003cid\u003e` (and `users[]=\u003cid\u003e`) returns the targeted user\u0027s timesheet records to any caller that has the `view_other_timesheet` permission, without verifying that the caller is teamlead of any team containing the target user. The per-record endpoint `GET /api/timesheets/{id}` correctly enforces this check via `TimesheetVoter`/`RolePermissionManager::checkTeamAccessTimesheet` \u2192 `checkTeamLeadAccess`, but the list endpoint only filters projects/customers by team membership and never validates `t.user`. A `ROLE_TEAMLEAD` user can therefore enumerate any user\u0027s records \u2014 including the `rate` field \u2014 as long as those records are on a project with no team scoping (Kimai\u0027s default) or on any project that shares any team (membership, not lead) with the requester.\n\n## Details\n\n**Root cause:** authorization mismatch between the per-record voter and the list endpoint.\n\n### Per-record path (correct)\n\n`src/Voter/TimesheetVoter.php:138`:\n```php\nif (!$this-\u003epermissionManager-\u003echeckTeamAccessTimesheet($subject, $user)) {\n    return false;\n}\nreturn $this-\u003epermissionManager-\u003ehasRolePermission($user, $permission . \u0027_other_timesheet\u0027);\n```\n\n`checkTeamLeadAccess` (RolePermissionManager.php:143-160) requires `isTeamleadOf` (not just member) one of the **target user\u0027s** teams. The unit test `testTeamleadDeniedWhenOnlyPlainMemberOfOwnerTeam` (tests/Voter/TimesheetVoterTest.php:253-269) codifies this:\n\n\u003e *\"a TEAMLEAD role with `view_other_timesheet` must not access another user\u0027s timesheet by being a plain team member \u2014 they must be the team\u0027s teamlead.\"*\n\n### List path (vulnerable)\n\n`src/API/TimesheetController.php:97-119`:\n```php\npublic function cgetAction(ParamFetcherInterface $paramFetcher, ..., UserRepository $userRepository): Response\n{\n    $query = new TimesheetQuery(false);\n    $this-\u003eprepareQuery($query, $paramFetcher);\n    $seeAll = false;\n\n    if ($this-\u003eisGranted(\u0027view_other_timesheet\u0027)) {\n        /** @var array\u003cint\u003e $users */\n        $users = $paramFetcher-\u003eget(\u0027users\u0027);\n        $userId = $paramFetcher-\u003eget(\u0027user\u0027);\n\n        if (\u0027all\u0027 === $userId) {\n            $seeAll = true;\n        } elseif (\\is_string($userId) \u0026\u0026 $userId !== \u0027\u0027) {\n            $users[] = (int) $userId;\n        }\n\n        if (!$seeAll) {\n            foreach ($userRepository-\u003efindByIds($users) as $user) {\n                $query-\u003eaddUser($user);   // \u003c-- no teamlead-of-target check\n            }\n        }\n    }\n    ...\n```\n\n`config/packages/kimai.yaml:96,115` grants `TIMESHEET_OTHER` (which contains `view_other_timesheet`) to `ROLE_TEAMLEAD`, so the gate at line 103 passes for any teamlead. The `user=` / `users[]=` IDs are pushed straight into the query.\n\n### Net effect\n\nFor any victim `bob` who:\n- has at least one team that the requester `alice` is **not** teamlead of (so the voter denies per-record access), AND\n- has timesheets either on a project with no team (Kimai\u0027s default), or on a project that shares any team with `alice` (membership, not lead)\n\n`alice` is denied via `GET /api/timesheets/{id}` but receives `bob`\u0027s records via `GET /api/timesheets?user=\u003cbob_id\u003e`.\n\nDisclosed fields in the collection response include `description`, `begin`, `end`, `duration`, `billable`, `exported`, `tags`, `rate`, `internalRate`, plus project/activity/user IDs (Default/Collection serializer groups, Timesheet.php:164-173). `rate` is financial data that the per-record voter is supposed to gate via the separate `view_rate_other_timesheet` permission.\n\n### Why other proposed mitigations don\u0027t apply\n- The `view_other_timesheet` `IsGranted` on the route is the only authorization layer in the list path; ROLE_TEAMLEAD has it globally.\n- `prepareQuery` only sets `currentUser`, not authorization (BaseApiController.php:68-71).\n- The serializer does not filter `rate` per caller \u2014 it is a static `Default`-group property.\n- Recent commit 20c7b03 \"Re-usable ACL checks on teams\" hardened the voter side but left the list endpoint unchanged.\n\n*A PoC was provided, but removed for security reasons.*\n\n## Impact\n\n- **Authorization bypass**: a `ROLE_TEAMLEAD` (a non-admin role typically granted to multiple users in a Kimai instance) can read any other user\u0027s timesheet records\n- **Financial data disclosure**: the `rate` and `internalRate` fields are returned in the collection serializer group, leaking what gets billed/costed against any user\u0027s records.\n- **PII / activity disclosure**: per-entry `description`, `begin`, `end`, `duration`, `billable`, `exported`, project/activity/customer IDs, and tags are leaked, allowing reconstruction of any user\u0027s activity timeline.\n\n# Solution\n\nThe list of requested user `TimesheetController::cgetAction()` is now guarded with the `access_user` permission.\nThe `access_user` permission verifies that the requesting user is allowed to see each of the requested user.\nIf any of the requested users may not be seen, the entire call will fail.\n\nFind out more at [https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp](https://www.kimai.org/en/security/ghsa-4m8q-55qv-9pwp)",
  "id": "GHSA-4m8q-55qv-9pwp",
  "modified": "2026-07-13T23:55:16Z",
  "published": "2026-07-13T23:55:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-4m8q-55qv-9pwp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai: Teamlead authorization bypass in GET /api/timesheets allows reading other users\u0027 timesheet records without being teamlead of the target"
}

GHSA-4M9P-WH47-W846

Vulnerability from github – Published: 2022-05-24 19:07 – Updated: 2022-07-15 00:00
VLAI
Details

Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause arbitrary webpage loading in webview.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-25439"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-08T14:15:00Z",
    "severity": "LOW"
  },
  "details": "Improper access control vulnerability in Samsung Members prior to versions 2.4.85.11 in Android O(8.1) and below, and 3.9.10.11 in Android P(9.0) and above allows untrusted applications to cause arbitrary webpage loading in webview.",
  "id": "GHSA-4m9p-wh47-w846",
  "modified": "2022-07-15T00:00:17Z",
  "published": "2022-05-24T19:07:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25439"
    },
    {
      "type": "WEB",
      "url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=7"
    }
  ],
  "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-4MH3-H929-W968

Vulnerability from github – Published: 2026-02-10 00:25 – Updated: 2026-02-10 02:56
VLAI
Summary
File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL
Details

Summary

An authenticated user can bypass the application's "Disallow" file path rules by modifying the request URL. By adding multiple slashes (e.g., //private/) to the path, the authorization check fails to match the rule, while the underlying filesystem resolves the path correctly, granting unauthorized access to restricted files.

Details

The vulnerability allows users to bypass "Disallow" rules defined by administrators.

The issue stems from how the application handles URL path normalization and rule matching:

  1. Router Configuration: The router in http/http.go is configured with r.SkipClean(true). This prevents the automatic collapse of multiple slashes (e.g., // becoming /) before the request reaches the handler.
  2. Insecure Rule Matching: The rule enforcement logic in rules/rules.go relies on a simple string prefix match: strings.HasPrefix(path, r.Path). If a rule disallows /private, a request for //private fails this check because //private does not strictly start with /private.
  3. Filesystem Resolution: After bypassing the rule check, the non-normalized path is passed to the filesystem. The filesystem treats the multiple slashes as a single separator, successfully resolving //private/secret.txt and serving the file.

PoC

Python minimal PoC

The following steps demonstrate the vulnerability: 1. Setup: - Admin user creates a folder /private and adds a file /private/secret.txt. Screenshot_20260123_151608 Screenshot_20260123_151551 - Admin adds a Disallow rule for user bob on the path /private. Screenshot_20260123_151502

  1. Verification:
  2. User bob requests GET /api/resources/private/secret.txt.
  3. Server responds: 403 Forbidden. Screenshot_20260123_154446
  4. Exploit:
  5. User bob requests GET /api/resources//private/secret.txt.
  6. Server responds: 200 OK (Bypass successful). Screenshot_20260123_154544 Screenshot_20260123_154618

Impact

This vulnerability impacts the confidentiality and integrity of data stored in filebrowser. - Confidentiality: Users can read files they are explicitly forbidden from accessing. - Integrity: If the user has general write permissions but is restricted from specific directories via rules, they can bypass these restrictions to rename, delete, or modify files.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.57.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.57.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25890"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-10T00:25:17Z",
    "nvd_published_at": "2026-02-09T22:16:03Z",
    "severity": "HIGH"
  },
  "details": "### Summary\nAn authenticated user can bypass the application\u0027s \"Disallow\" file path rules by modifying the request URL. By adding multiple slashes (e.g., //private/) to the path, the authorization check fails to match the rule, while the underlying filesystem resolves the path correctly, granting unauthorized access to restricted files.\n\n### Details\nThe vulnerability allows users to bypass \"Disallow\" rules defined by administrators.\n\nThe issue stems from how the application handles URL path normalization and rule matching:\n\n1. Router Configuration: The router in `http/http.go` is configured with `r.SkipClean(true)`. This prevents the automatic collapse of multiple slashes (e.g., // becoming /) before the request reaches the handler.\n2. Insecure Rule Matching: The rule enforcement logic in `rules/rules.go` relies on a simple string prefix match: `strings.HasPrefix(path, r.Path)`. If a rule disallows /private, a request for //private fails this check because //private does not strictly start with /private.\n3. Filesystem Resolution: After bypassing the rule check, the non-normalized path is passed to the filesystem. The filesystem treats the multiple slashes as a single separator, successfully resolving //private/secret.txt and serving the file.\n\n### PoC\n[Python minimal PoC](https://github.com/user-attachments/files/24823114/poc.py)\n\nThe following steps demonstrate the vulnerability:\n1. Setup:\n  - Admin user creates a folder /private and adds a file /private/secret.txt.\n\u003cimg width=\"971\" height=\"719\" alt=\"Screenshot_20260123_151608\" src=\"https://github.com/user-attachments/assets/2071c92e-2bbe-46f8-a338-05b0f53d381a\" /\u003e\n\u003cimg width=\"890\" height=\"386\" alt=\"Screenshot_20260123_151551\" src=\"https://github.com/user-attachments/assets/1def540a-de26-4666-a6ab-058d5927bfbe\" /\u003e\n  - Admin adds a Disallow rule for user bob on the path /private.\n\u003cimg width=\"1005\" height=\"1126\" alt=\"Screenshot_20260123_151502\" src=\"https://github.com/user-attachments/assets/e9b57d59-f4ab-41d8-b056-8ffdaa219963\" /\u003e\n\n2. Verification:\n  - User bob requests GET /api/resources/private/secret.txt.\n  - Server responds: 403 Forbidden.\n\u003cimg width=\"1193\" height=\"721\" alt=\"Screenshot_20260123_154446\" src=\"https://github.com/user-attachments/assets/dd092a10-2f8c-4a3c-b48f-d540c483bb5a\" /\u003e\n3. Exploit:\n  - User bob requests GET /api/resources//private/secret.txt.\n  - Server responds: 200 OK (Bypass successful).\n\u003cimg width=\"1193\" height=\"721\" alt=\"Screenshot_20260123_154544\" src=\"https://github.com/user-attachments/assets/27ebb82c-f7c2-467d-ae82-f495ae3aa2d4\" /\u003e\n\u003cimg width=\"1196\" height=\"818\" alt=\"Screenshot_20260123_154618\" src=\"https://github.com/user-attachments/assets/82035884-9a24-490d-b928-7bdd2dbe3193\" /\u003e\n\n\n### Impact\nThis vulnerability impacts the confidentiality and integrity of data stored in filebrowser.\n- Confidentiality: Users can read files they are explicitly forbidden from accessing.\n- Integrity: If the user has general write permissions but is restricted from specific directories via rules, they can bypass these restrictions to rename, delete, or modify files.",
  "id": "GHSA-4mh3-h929-w968",
  "modified": "2026-02-10T02:56:37Z",
  "published": "2026-02-10T00:25:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-4mh3-h929-w968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25890"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/489af403a19057f6b6b4b1dc0e48cbb26a202ef9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.57.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "File Browser has a Path-Based Access Control Bypass via Multiple Leading Slashes in URL"
}

GHSA-4MMH-FCMV-Q64R

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

The NuPoint Messenger of Mitel MiCollab before 9.2 could allow an attacker with escalated privilege to access user files due to insufficient access control. Successful exploit could potentially allow an attacker to gain access to sensitive information.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-25612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-12-18T08:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The NuPoint Messenger of Mitel MiCollab before 9.2 could allow an attacker with escalated privilege to access user files due to insufficient access control. Successful exploit could potentially allow an attacker to gain access to sensitive information.",
  "id": "GHSA-4mmh-fcmv-q64r",
  "modified": "2022-05-24T17:36:53Z",
  "published": "2022-05-24T17:36:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25612"
    },
    {
      "type": "WEB",
      "url": "https://www.mitel.com/support/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-4MMR-2W8P-WHCR

Vulnerability from github – Published: 2025-05-29 18:31 – Updated: 2025-05-29 22:37
VLAI
Summary
Mattermost improperly allows team administrators to modify team invites
Details

Mattermost versions 10.7.x <= 10.7.0, 10.6.x <= 10.6.2, 10.5.x <= 10.5.3, 9.11.x <= 9.11.12 fail to properly validate permissions when changing team privacy settings, allowing team administrators without the 'invite user' permission to access and modify team invite IDs via the /api/v4/teams/:teamId/privacy endpoint.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.7.0-rc1"
            },
            {
              "fixed": "10.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.6.0-rc1"
            },
            {
              "fixed": "10.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.5.0-rc1"
            },
            {
              "fixed": "10.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0-rc1"
            },
            {
              "fixed": "9.11.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/mattermost/mattermost/server/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.0.0-20250412152950-02c76784380a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3913"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-05-29T22:37:07Z",
    "nvd_published_at": "2025-05-29T16:15:39Z",
    "severity": "MODERATE"
  },
  "details": "Mattermost versions 10.7.x \u003c= 10.7.0, 10.6.x \u003c= 10.6.2, 10.5.x \u003c= 10.5.3, 9.11.x \u003c= 9.11.12 fail to properly validate permissions when changing team privacy settings, allowing team administrators without the \u0027invite user\u0027 permission to access and modify team invite IDs via the /api/v4/teams/:teamId/privacy endpoint.",
  "id": "GHSA-4mmr-2w8p-whcr",
  "modified": "2025-05-29T22:37:07Z",
  "published": "2025-05-29T18:31:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3913"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mattermost/mattermost/commit/02c76784380acb6802601bd24c205553b9a5a1be"
    },
    {
      "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:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Mattermost improperly allows team administrators to modify team invites"
}

GHSA-4MRW-M8GP-8HGX

Vulnerability from github – Published: 2022-05-13 01:05 – Updated: 2022-05-13 01:05
VLAI
Details

A vulnerability in the Graphite interface of Cisco HyperFlex software could allow an authenticated, local attacker to write arbitrary data to the Graphite interface. The vulnerability is due to insufficient authorization controls. An attacker could exploit this vulnerability by connecting to the Graphite service and sending arbitrary data. A successful exploit could allow the attacker to write arbitrary data to Graphite, which could result in invalid statistics being presented in the interface. Versions prior to 3.5(2a) are affected.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-1667"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-02-21T19:29:00Z",
    "severity": "LOW"
  },
  "details": "A vulnerability in the Graphite interface of Cisco HyperFlex software could allow an authenticated, local attacker to write arbitrary data to the Graphite interface. The vulnerability is due to insufficient authorization controls. An attacker could exploit this vulnerability by connecting to the Graphite service and sending arbitrary data. A successful exploit could allow the attacker to write arbitrary data to Graphite, which could result in invalid statistics being presented in the interface. Versions prior to 3.5(2a) are affected.",
  "id": "GHSA-4mrw-m8gp-8hgx",
  "modified": "2022-05-13T01:05:24Z",
  "published": "2022-05-13T01:05:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1667"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190220-hyper-write"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/107100"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4MX8-3M5Q-284R

Vulnerability from github – Published: 2022-05-24 17:45 – Updated: 2026-07-05 03:30
VLAI
Details

The Acexy Wireless-N WiFi Repeater REV 1.0 (28.08.06.1) Web management administrator password can be changed by sending a specially crafted HTTP GET request. The administrator username has to be known (default:admin) whereas no previous authentication is required.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-28936"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-03-29T13:15:00Z",
    "severity": "HIGH"
  },
  "details": "The Acexy Wireless-N WiFi Repeater REV 1.0 (28.08.06.1) Web management administrator password can be changed by sending a specially crafted HTTP GET request. The administrator username has to be known (default:admin) whereas no previous authentication is required.",
  "id": "GHSA-4mx8-3m5q-284r",
  "modified": "2026-07-05T03:30:39Z",
  "published": "2022-05-24T17:45:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28936"
    },
    {
      "type": "WEB",
      "url": "https://blog-ssh3ll.medium.com/acexy-wireless-n-wifi-repeater-vulnerabilities-8bd5d14a2990"
    },
    {
      "type": "WEB",
      "url": "http://acexy.com"
    },
    {
      "type": "WEB",
      "url": "http://wireless-n.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4P43-388J-FFHJ

Vulnerability from github – Published: 2022-07-13 00:01 – Updated: 2022-07-16 00:00
VLAI
Details

Improper permission control vulnerability in the Bluetooth module.Successful exploitation of this vulnerability will affect confidentiality.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-40016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-12T14:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper permission control vulnerability in the Bluetooth module.Successful exploitation of this vulnerability will affect confidentiality.",
  "id": "GHSA-4p43-388j-ffhj",
  "modified": "2022-07-16T00:00:21Z",
  "published": "2022-07-13T00:01:53Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-40016"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2022/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/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