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.

7172 vulnerabilities reference this CWE, most recent first.

GHSA-9F9G-FJV5-H5G7

Vulnerability from github – Published: 2023-12-21 21:30 – Updated: 2024-12-16 21:30
VLAI
Details

An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed issue comments to be updated with an improperly scoped token. This vulnerability did not allow unauthorized access to any repository content as it also required contents:write and issues:read permissions. This vulnerability affected all versions of GitHub Enterprise Server since 3.7 and was fixed in version 3.17.19, 3.8.12, 3.9.7, 3.10.4, and 3.11.1. 

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-51379"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-21T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "An incorrect authorization vulnerability was identified in GitHub Enterprise Server that allowed issue comments to be updated with an improperly scoped token. This vulnerability did not allow unauthorized access to any repository content as it also required contents:write and issues:read permissions. This vulnerability affected all versions of GitHub Enterprise Server since 3.7 and was fixed in version 3.17.19, 3.8.12, 3.9.7, 3.10.4, and 3.11.1.\u00a0",
  "id": "GHSA-9f9g-fjv5-h5g7",
  "modified": "2024-12-16T21:30:54Z",
  "published": "2023-12-21T21:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51379"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.4"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.1"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.7/admin/release-notes#3.7.19"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.8/admin/release-notes#3.8.12"
    },
    {
      "type": "WEB",
      "url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9FCF-35PP-33Q8

Vulnerability from github – Published: 2026-09-09 03:30 – Updated: 2026-09-09 15:34
VLAI
Details

Incorrect authorization in Loader in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-87476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T01:17:04Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect authorization in Loader in Google Chrome prior to 153.0.8010.36 allowed a remote attacker to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium)",
  "id": "GHSA-9fcf-35pp-33q8",
  "modified": "2026-09-09T15:34:57Z",
  "published": "2026-09-09T03:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87476"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/09/stable-channel-update-for-desktop_0808145027.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/506390077"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9FG6-4JC3-M2X8

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

newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-23449"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-01-26T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "newbee-mall all versions are affected by incorrect access control to remotely gain privileges through NewBeeMallIndexConfigServiceImpl.java. Unauthorized changes can be made to any user information through the userID.",
  "id": "GHSA-9fg6-4jc3-m2x8",
  "modified": "2022-05-24T17:40:06Z",
  "published": "2022-05-24T17:40:06Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-23449"
    },
    {
      "type": "WEB",
      "url": "https://github.com/newbee-ltd/newbee-mall/issues/35"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9FHM-53XW-H9C3

Vulnerability from github – Published: 2026-07-21 21:32 – Updated: 2026-07-21 21:32
VLAI
Details

Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices' configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-56144"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-21T20:17:02Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect Authorization (CWE-863) in Elasticsearch can allow an authenticated user with limited index privileges to exploit insufficient authorization controls in the ingest simulation feature. By targeting indices they are not authorized to access directly, the user can cause those indices\u0027 configured ingest pipelines to execute and return their output, potentially disclosing data processed or enriched by those pipelines. Additionally, the same feature can be used to retrieve index mapping metadata for indices the user are not authorized to access directly.",
  "id": "GHSA-9fhm-53xw-h9c3",
  "modified": "2026-07-21T21:32:40Z",
  "published": "2026-07-21T21:32:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56144"
    },
    {
      "type": "WEB",
      "url": "https://discuss.elastic.co/t/elasticsearch-8-19-18-9-3-7-9-4-4-security-update-esa-2026-56/388555"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G2Q-W3W2-VF7Q

Vulnerability from github – Published: 2026-05-06 18:28 – Updated: 2026-05-06 18:28
VLAI
Summary
Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation
Details

Summary

Any ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system — regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.

Details

TimesheetVoter::voteOnAttribute() maps permissions to own_timesheet or other_timesheet without checking team membership. The voter's own comment confirms this is a known gap:

// extend me for "team" support later on
if ($subject->getUser()?->getId() === $user->getId()) {
    $permission .= 'own';
} else {
    $permission .= 'other';
}

PoC

Tested against Kimai 2.52.0 Docker instance.

Setup: - User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description "Private timesheet - UserA only" - User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A

User B reads User A's timesheet data:

GET /api/timesheets/2 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 200 — returns full timesheet record including description "Private timesheet - UserA only".

User B deletes User A's timesheet:

DELETE /api/timesheets/3 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>

Response: HTTP 204 No Content — timesheet permanently deleted.

User B tampers User A's timesheet:

PATCH /api/timesheets/6 HTTP/1.1
X-AUTH-USER: userb
X-AUTH-TOKEN: <userb_api_token>
Content-Type: application/json

{"begin":"2026-03-24T08:00:00","end":"2026-03-24T18:00:00","project":1,"activity":1,"description":"TAMPERED","exported":false,"billable":false}

Response: HTTP 200 OK — duration inflated from 3600s to 36000s, description overwritten.

Note: ROLE_USER (userc) is correctly blocked — DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.

Impact

Any authenticated user with ROLE_TEAMLEAD or above can:

  1. Permanently delete timesheets belonging to any user system-wide — destroying billable hours, payroll data, and project billing history
  2. Silently alter timesheet descriptions, hours, and billing flags — forging hours up or down, directly affecting invoicing and payroll
  3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records

No user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.

Maintainers answer: why this is not eligible for a CVE

The behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to ROLE_TEAMLEAD are:

  • edit_other_timesheet — Edit existing records of other users
  • delete_other_timesheet — Delete existing records of other users

These permissions were global by design, not team-scoped. The UI surfaces only the teamlead's own team timesheets, but the API has historically honored these permissions as documented: a role holding *_other_timesheet can act on any other user's timesheet. The inline comment // extend me for "team" support later on reflects this accurately — team-scoped enforcement was a planned enhancement, not a security control that existed and failed.

The report frames this as authorization bypass, but no authorization boundary is being crossed: ROLE_TEAMLEAD is operating within its documented permissions.

Kimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.

Solution

Team-scoped timesheet permission checks were added in 2.56.0.

Operators of Kimai <= 2.55 who need stricter isolation between teamleads should not grant ROLE_TEAMLEAD to users who must not act on other teams' timesheets.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.55.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.56.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:28:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nAny ROLE_TEAMLEAD user can enumerate, read, modify, and permanently delete timesheets belonging to any other user in the system \u2014 regardless of team membership. This enables data destruction (deleted billable hours), data tampering (forged timesheet durations), and full authorization bypass on timesheet resources. Verified against Kimai 2.52.0.\n\n### Details\n\n`TimesheetVoter::voteOnAttribute()` maps permissions to `own_timesheet` or `other_timesheet` without checking team membership. The voter\u0027s own comment confirms this is a known gap:\n\n```php\n// extend me for \"team\" support later on\nif ($subject-\u003egetUser()?-\u003egetId() === $user-\u003egetId()) {\n    $permission .= \u0027own\u0027;\n} else {\n    $permission .= \u0027other\u0027;\n}\n```\n\n### PoC\n\nTested against Kimai 2.52.0 Docker instance.\n\nSetup:\n- User A (usera, ROLE_TEAMLEAD) owns timesheet ID 2 with description \"Private timesheet - UserA only\"\n- User B (userb, ROLE_TEAMLEAD) is NOT on any team with User A\n\n**User B reads User A\u0027s timesheet data:**\n\n```\nGET /api/timesheets/2 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 200 \u2014 returns full timesheet record including description \"Private timesheet - UserA only\".\n\n**User B deletes User A\u0027s timesheet:**\n\n```\nDELETE /api/timesheets/3 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\n```\n\nResponse: HTTP 204 No Content \u2014 timesheet permanently deleted.\n\n**User B tampers User A\u0027s timesheet:**\n\n```\nPATCH /api/timesheets/6 HTTP/1.1\nX-AUTH-USER: userb\nX-AUTH-TOKEN: \u003cuserb_api_token\u003e\nContent-Type: application/json\n\n{\"begin\":\"2026-03-24T08:00:00\",\"end\":\"2026-03-24T18:00:00\",\"project\":1,\"activity\":1,\"description\":\"TAMPERED\",\"exported\":false,\"billable\":false}\n```\n\nResponse: HTTP 200 OK \u2014 duration inflated from 3600s to 36000s, description overwritten.\n\n**Note:** ROLE_USER (userc) is correctly blocked \u2014 DELETE returns 403 and the actions endpoint returns an empty array. The vulnerability only affects ROLE_TEAMLEAD and above. Timesheet IDs are sequential integers, trivially enumerable.\n\n### Impact\n\nAny authenticated user with ROLE_TEAMLEAD or above can:\n\n1. Permanently delete timesheets belonging to any user system-wide \u2014 destroying billable hours, payroll data, and project billing history\n2. Silently alter timesheet descriptions, hours, and billing flags \u2014 forging hours up or down, directly affecting invoicing and payroll\n3. Enumerate all timesheet IDs (sequential integers) and access action metadata for arbitrary records\n\nNo user interaction required. ROLE_USER accounts are correctly restricted; the vulnerability is specific to ROLE_TEAMLEAD receiving global scope instead of team-scoped access.\n\n### Maintainers answer: why this is not eligible for a CVE\n\nThe behavior described matches the documented permission model. Per the Kimai documentation, the relevant permissions granted to `ROLE_TEAMLEAD` are:\n\n- `edit_other_timesheet` \u2014 Edit existing records of other users\n- `delete_other_timesheet` \u2014 Delete existing records of other users\n\nThese permissions were global by design, not team-scoped. The UI surfaces only the teamlead\u0027s own team timesheets, but the API has historically honored these permissions as documented: a role holding `*_other_timesheet` can act on any other user\u0027s timesheet. The inline comment `// extend me for \"team\" support later on` reflects this accurately \u2014 team-scoped enforcement was a planned enhancement, not a security control that existed and failed.\n\nThe report frames this as authorization bypass, but no authorization boundary is being crossed: `ROLE_TEAMLEAD` is operating within its documented permissions.\n\nKimai acknowledges that this behavior might not be expected, so while it will be treated as a feature request for team-scoped permission enforcement and not a vulnerability, it still track it as having security implications.\n\n### Solution\n\nTeam-scoped timesheet permission checks were added in 2.56.0.\n\nOperators of Kimai \u003c= 2.55 who need stricter isolation between teamleads should not grant `ROLE_TEAMLEAD` to users who must not act on other teams\u0027 timesheets.",
  "id": "GHSA-9g2q-w3w2-vf7q",
  "modified": "2026-05-06T18:28:46Z",
  "published": "2026-05-06T18:28:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-9g2q-w3w2-vf7q"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai has Missing Voter Check that Allows Cross-Team Timesheet Manipulation"
}

GHSA-9G39-JGF9-9MXX

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

A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-9004"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-306",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-04-14T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "A remote authenticated authorization-bypass vulnerability in Wowza Streaming Engine 4.7.8 (build 20191105123929) allows any read-only user to issue requests to the administration panel in order to change functionality. For example, a read-only user may activate the Java JMX port in unauthenticated mode and execute OS commands under root privileges.",
  "id": "GHSA-9g39-jgf9-9mxx",
  "modified": "2022-05-24T17:14:18Z",
  "published": "2022-05-24T17:14:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9004"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DrunkenShells/Disclosures/tree/master/CVE-2020-9004-Authenticated%20Remote%20Authorization%20Bypass%20Leading%20to%20RCE-Wowza"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/main/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://raw.githubusercontent.com/WowzaMediaSystems/public_cve/master/wowza-streaming-engine/CVE-2020-9004.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.wowza.com/docs/wowza-streaming-engine-4-8-5-release-notes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G52-R87C-973Q

Vulnerability from github – Published: 2024-12-04 03:31 – Updated: 2024-12-04 03:31
VLAI
Details

A vulnerability in Veeam Backup & Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-04T02:15:04Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in Veeam Backup \u0026 Replication allows a low-privileged user to start an agent remotely in server mode and obtain credentials, effectively escalating privileges to system-level access. This allows the attacker to upload files to the server with elevated privileges. The vulnerability exists because remote calls bypass permission checks, leading to full system compromise.",
  "id": "GHSA-9g52-r87c-973q",
  "modified": "2024-12-04T03:31:15Z",
  "published": "2024-12-04T03:31:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42452"
    },
    {
      "type": "WEB",
      "url": "https://www.veeam.com/kb4693"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9G7M-MW8W-MQC5

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

OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-16244"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-22T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "OMERO.server before 5.6.1 allows attackers to bypass the security filters and access hidden objects via a crafted query.",
  "id": "GHSA-9g7m-mw8w-mqc5",
  "modified": "2022-05-24T17:24:01Z",
  "published": "2022-05-24T17:24:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16244"
    },
    {
      "type": "WEB",
      "url": "https://www.openmicroscopy.org/security/advisories/2019-SV5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9G87-32V6-3C2R

Vulnerability from github – Published: 2026-10-06 15:38 – Updated: 2026-10-06 15:38
VLAI
Summary
Payload: Sort queries could expose protected field information
Details

Impact

Under certain conditions, sorting readable records could reveal limited information about fields the requester was not permitted to read.

You are affected if untrusted users can query a collection, control its sorting, and sort by protected fields.

Patches

Payload now applies field-level access checks to sort fields before executing queries.

Users should upgrade to >= 3.88.0 or >= 4.0.0-canary.27.

Workarounds

Upgrading is recommended. Until then, prevent untrusted users from controlling sort parameters or restrict their access to affected collections.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "payload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.88.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "payload"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-canary.0"
            },
            {
              "fixed": "4.0.0-canary.27"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-105805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-06T15:38:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nUnder certain conditions, sorting readable records could reveal limited information about fields the requester was not permitted to read.\n\nYou are affected if untrusted users can query a collection, control its sorting, and sort by protected fields.\n\n### Patches\nPayload now applies field-level access checks to sort fields before executing queries.\n\nUsers should upgrade to `\u003e= 3.88.0` or `\u003e= 4.0.0-canary.27`.\n\n### Workarounds\nUpgrading is recommended. Until then, prevent untrusted users from controlling sort parameters or restrict their access to affected collections.",
  "id": "GHSA-9g87-32v6-3c2r",
  "modified": "2026-10-06T15:38:32Z",
  "published": "2026-10-06T15:38:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/payloadcms/payload/security/advisories/GHSA-9g87-32v6-3c2r"
    },
    {
      "type": "WEB",
      "url": "https://github.com/payloadcms/payload/commit/a742140ab4fca3160f7f83e9e7d996552ffc3b5a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/payloadcms/payload"
    },
    {
      "type": "WEB",
      "url": "https://github.com/payloadcms/payload/releases/tag/v3.88.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Payload: Sort queries could expose protected field information"
}

GHSA-9GF3-6WPF-HGPX

Vulnerability from github – Published: 2023-02-14 21:30 – Updated: 2025-10-22 00:32
VLAI
Details

Microsoft Publisher Security Features Bypass Vulnerability

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-21715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-14T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Publisher Security Features Bypass Vulnerability",
  "id": "GHSA-9gf3-6wpf-hgpx",
  "modified": "2025-10-22T00:32:41Z",
  "published": "2023-02-14T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21715"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-21715"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "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.