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.

5678 vulnerabilities reference this CWE, most recent first.

GHSA-4JG3-767H-M23Q

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

Necessary authorization checks for an authenticated user, resulting in escalation of privileges, have been fixed in SAP Basis AS ABAP of SAP NetWeaver 700 to 750, from 750 onwards delivered as ABAP Platform.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-2494"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-12-11T22:29:00Z",
    "severity": "HIGH"
  },
  "details": "Necessary authorization checks for an authenticated user, resulting in escalation of privileges, have been fixed in SAP Basis AS ABAP of SAP NetWeaver 700 to 750, from 750 onwards delivered as ABAP Platform.",
  "id": "GHSA-4jg3-767h-m23q",
  "modified": "2022-05-13T01:51:20Z",
  "published": "2022-05-13T01:51:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-2494"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/2698996"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=508559699"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4JH4-MWQ8-WX24

Vulnerability from github – Published: 2023-10-20 09:30 – Updated: 2024-04-04 08:50
VLAI
Details

The Brizy plugin for WordPress is vulnerable to authorization bypass due to a incorrect capability check on the is_administrator() function in versions up to, and including, 1.0.125. This makes it possible for authenticated attackers to access and interact with available AJAX functions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-36714"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-20T08:15:11Z",
    "severity": "HIGH"
  },
  "details": "The Brizy plugin for WordPress is vulnerable to authorization bypass due to a incorrect capability check on the is_administrator() function in versions up to, and including, 1.0.125. This makes it possible for authenticated attackers to access and interact with available AJAX functions.",
  "id": "GHSA-4jh4-mwq8-wx24",
  "modified": "2024-04-04T08:50:16Z",
  "published": "2023-10-20T09:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36714"
    },
    {
      "type": "WEB",
      "url": "https://blog.nintechnet.com/wordpress-brizy-page-builder-plugin-fixed-critical-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/9495e25d-a5a6-4f25-9363-783626e58a4a?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4JHJ-RW84-72PF

Vulnerability from github – Published: 2025-10-14 21:30 – Updated: 2025-10-14 21:30
VLAI
Details

Adobe Commerce versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Incorrect Authorization vulnerability. An attacker could leverage this vulnerability to bypass security measures and gain limited unauthorized read access. Exploitation of this issue does not require user interaction.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-54277"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T21:15:35Z",
    "severity": "MODERATE"
  },
  "details": "Adobe Commerce versions 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 and earlier are affected by an Incorrect Authorization vulnerability. An attacker could leverage this vulnerability to bypass security measures and gain limited unauthorized read access. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-4jhj-rw84-72pf",
  "modified": "2025-10-14T21:30:48Z",
  "published": "2025-10-14T21:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-54277"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/magento/apsb25-94.html"
    }
  ],
  "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"
    }
  ]
}

GHSA-4JQR-H7HR-V5MG

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2023-06-19 15:30
VLAI
Details

Improper serialization of internal state in the authorization subsystem in MongoDB Server's authorization subsystem permits a user with valid credentials to bypass IP whitelisting protection mechanisms following administrative action. This issue affects: MongoDB Inc. MongoDB Server 4.2 versions prior to 4.2.3; 4.0 versions prior to 4.0.15; 4.3 versions prior to 4.3.3; 3.6 versions prior to 3.6.18.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-7921"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-182",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-06T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper serialization of internal state in the authorization subsystem in MongoDB Server\u0027s authorization subsystem permits a user with valid credentials to bypass IP whitelisting protection mechanisms following administrative action. This issue affects: MongoDB Inc. MongoDB Server 4.2 versions prior to 4.2.3; 4.0 versions prior to 4.0.15; 4.3 versions prior to 4.3.3; 3.6 versions prior to 3.6.18.",
  "id": "GHSA-4jqr-h7hr-v5mg",
  "modified": "2023-06-19T15:30:48Z",
  "published": "2022-05-24T17:17:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7921"
    },
    {
      "type": "WEB",
      "url": "https://jira.mongodb.org/browse/SERVER-45472"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4JR8-64GC-WQQX

Vulnerability from github – Published: 2025-03-20 12:32 – Updated: 2025-10-15 15:30
VLAI
Details

In version 1.5.5 of lunary-ai/lunary, a vulnerability exists where admins, who do not have direct permissions to access billing resources, can change the permissions of existing users to include billing permissions. This can lead to a privilege escalation scenario where an administrator can manage billing, effectively bypassing the intended role-based access control. Only users with the 'owner' role should be allowed to invite members with billing permissions. This flaw allows admins to circumvent those restrictions, gaining unauthorized access and control over billing information, posing a risk to the organization’s financial resources.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-10275"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-284",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-20T10:15:16Z",
    "severity": "HIGH"
  },
  "details": "In version 1.5.5 of lunary-ai/lunary, a vulnerability exists where admins, who do not have direct permissions to access billing resources, can change the permissions of existing users to include billing permissions. This can lead to a privilege escalation scenario where an administrator can manage billing, effectively bypassing the intended role-based access control. Only users with the \u0027owner\u0027 role should be allowed to invite members with billing permissions. This flaw allows admins to circumvent those restrictions, gaining unauthorized access and control over billing information, posing a risk to the organization\u2019s financial resources.",
  "id": "GHSA-4jr8-64gc-wqqx",
  "modified": "2025-10-15T15:30:22Z",
  "published": "2025-03-20T12:32:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10275"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lunary-ai/lunary/commit/8ba1b8ba2c2c30b1cec30eb5777c1fda670cbbfc"
    },
    {
      "type": "WEB",
      "url": "https://huntr.com/bounties/863ee34b-c4c6-4325-bf7a-82a7feebf88f"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4M5G-5J75-MFX2

Vulnerability from github – Published: 2022-04-22 00:24 – Updated: 2024-04-03 23:05
VLAI
Details

Tahoe-LAFS v1.3.0 through v1.8.2 could allow unauthorized users to delete immutable files in some cases.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2011-3617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-26T03:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tahoe-LAFS v1.3.0 through v1.8.2 could allow unauthorized users to delete immutable files in some cases.",
  "id": "GHSA-4m5g-5j75-mfx2",
  "modified": "2024-04-03T23:05:35Z",
  "published": "2022-04-22T00:24:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3617"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/cve-2011-3617"
    },
    {
      "type": "WEB",
      "url": "https://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-3617.html"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2011-3617"
    }
  ],
  "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"
    }
  ]
}

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

{
  "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.

Show details on source website

{
  "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::checkTeamAccessTimesheetcheckTeamLeadAccess, 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

Show details on source website

{
  "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.

Show details on source website

{
  "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"
    }
  ]
}

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.