CWE-863
Allowed-with-ReviewIncorrect 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.
5539 vulnerabilities reference this CWE, most recent first.
GHSA-W2R3-453H-7V25
Vulnerability from github – Published: 2025-06-23 21:31 – Updated: 2025-06-23 21:31An incorrect authorization vulnerability exists in multiple WSO2 products that allows unauthorized access to versioned files stored in the registry. Due to flawed authorization logic, a malicious actor with access to the management console can exploit a specific bypass method to retrieve versioned files without proper authorization.
Successful exploitation of this vulnerability could lead to unauthorized disclosure of configuration or resource files that may be stored as registry versions, potentially aiding further attacks or system reconnaissance.
{
"affected": [],
"aliases": [
"CVE-2024-3511"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-23T09:15:21Z",
"severity": "MODERATE"
},
"details": "An incorrect authorization vulnerability exists in multiple WSO2 products that allows unauthorized access to versioned files stored in the registry. Due to flawed authorization logic, a malicious actor with access to the management console can exploit a specific bypass method to retrieve versioned files without proper authorization.\n\nSuccessful exploitation of this vulnerability could lead to unauthorized disclosure of configuration or resource files that may be stored as registry versions, potentially aiding further attacks or system reconnaissance.",
"id": "GHSA-w2r3-453h-7v25",
"modified": "2025-06-23T21:31:55Z",
"published": "2025-06-23T21:31:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-3511"
},
{
"type": "WEB",
"url": "https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2025/WSO2-2024-2702"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2RM-X498-V7F9
Vulnerability from github – Published: 2024-05-23 12:31 – Updated: 2024-05-23 12:31An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.
{
"affected": [],
"aliases": [
"CVE-2024-5258"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-23T11:15:24Z",
"severity": "MODERATE"
},
"details": "An authorization vulnerability exists within GitLab from versions 16.10 before 16.10.6, 16.11 before 16.11.3, and 17.0 before 17.0.1 where an authenticated attacker could utilize a crafted naming convention to bypass pipeline authorization logic.",
"id": "GHSA-w2rm-x498-v7f9",
"modified": "2024-05-23T12:31:02Z",
"published": "2024-05-23T12:31:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5258"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/443254"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2WM-CCWH-3737
Vulnerability from github – Published: 2023-07-17 18:31 – Updated: 2024-04-04 06:10Mattermost fails to properly check the authorization of POST /api/v4/teams when passing a team override scheme ID in the request, allowing an authenticated attacker with knowledge of a Team Override Scheme ID to create a new team with said team override scheme.
{
"affected": [],
"aliases": [
"CVE-2023-3584"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-07-17T16:15:10Z",
"severity": "LOW"
},
"details": "Mattermost fails to properly check the authorization of\u00a0POST /api/v4/teams when passing a team override scheme ID in the request,\u00a0allowing an authenticated attacker with knowledge of a Team Override Scheme ID to create a new team with said team override scheme.\n\n",
"id": "GHSA-w2wm-ccwh-3737",
"modified": "2024-04-04T06:10:42Z",
"published": "2023-07-17T18:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-3584"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2X2-G32P-V8FP
Vulnerability from github – Published: 2023-06-06 09:30 – Updated: 2024-04-04 04:34Memory Corruption in GPU Subsystem due to arbitrary command execution from GPU in privileged mode.
{
"affected": [],
"aliases": [
"CVE-2023-21670"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T08:15:12Z",
"severity": "HIGH"
},
"details": "Memory Corruption in GPU Subsystem due to arbitrary command execution from GPU in privileged mode.",
"id": "GHSA-w2x2-g32p-v8fp",
"modified": "2024-04-04T04:34:57Z",
"published": "2023-06-06T09:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21670"
},
{
"type": "WEB",
"url": "https://www.qualcomm.com/company/product-security/bulletins/june-2023-bulletin"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/173296/Qualcomm-Adreno-KGSL-Insecure-Execution.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W326-RF25-93CQ
Vulnerability from github – Published: 2024-10-15 21:30 – Updated: 2024-10-15 21:30Vulnerability in the PeopleSoft Enterprise HCM Global Payroll Core product of Oracle PeopleSoft (component: Global Payroll for Core). Supported versions that are affected are 9.2.48-9.2.50. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Global Payroll Core. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Global Payroll Core accessible data as well as unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Global Payroll Core accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).
{
"affected": [],
"aliases": [
"CVE-2024-21283"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-15T20:15:21Z",
"severity": "HIGH"
},
"details": "Vulnerability in the PeopleSoft Enterprise HCM Global Payroll Core product of Oracle PeopleSoft (component: Global Payroll for Core). Supported versions that are affected are 9.2.48-9.2.50. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise PeopleSoft Enterprise HCM Global Payroll Core. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all PeopleSoft Enterprise HCM Global Payroll Core accessible data as well as unauthorized access to critical data or complete access to all PeopleSoft Enterprise HCM Global Payroll Core accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).",
"id": "GHSA-w326-rf25-93cq",
"modified": "2024-10-15T21:30:39Z",
"published": "2024-10-15T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21283"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2024.html"
}
],
"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"
}
]
}
GHSA-W33F-JR3X-9VJF
Vulnerability from github – Published: 2024-10-24 18:30 – Updated: 2024-10-25 18:30Incorrect access control in XIAO HE Smart 4.3.1 allows attackers to access sensitive information by analyzing the code and data within the APK file.
{
"affected": [],
"aliases": [
"CVE-2024-48540"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-24T17:15:16Z",
"severity": "MODERATE"
},
"details": "Incorrect access control in XIAO HE Smart 4.3.1 allows attackers to access sensitive information by analyzing the code and data within the APK file.",
"id": "GHSA-w33f-jr3x-9vjf",
"modified": "2024-10-25T18:30:48Z",
"published": "2024-10-24T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48540"
},
{
"type": "WEB",
"url": "https://github.com/HankJames/Vul-Reports/blob/main/FirmwareLeakage/com.hle.china.smarthome.xiaohe/com.hle.china.smarthome.xiaohe.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W37F-8CWF-64G5
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-05-24 19:11Improper authorization on the pipelines page in GitLab CE/EE affecting all versions since 13.12 allowed unauthorized users to view some pipeline information for public projects that have access to pipelines restricted to members only
{
"affected": [],
"aliases": [
"CVE-2021-22248"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-23T20:15:00Z",
"severity": "MODERATE"
},
"details": "Improper authorization on the pipelines page in GitLab CE/EE affecting all versions since 13.12 allowed unauthorized users to view some pipeline information for public projects that have access to pipelines restricted to members only",
"id": "GHSA-w37f-8cwf-64g5",
"modified": "2022-05-24T19:11:53Z",
"published": "2022-05-24T19:11:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22248"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22248.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/336074"
}
],
"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-W39P-VH2G-G8G5
Vulnerability from github – Published: 2026-06-25 18:32 – Updated: 2026-06-25 18:32Summary
langgraph-sdk constructs HTTP request paths for resource operations by interpolating caller-supplied identifier values into URL templates. Without sanitization of those values, identifiers that contain characters with special meaning in URL paths could cause the resulting request to address a different resource (and potentially a different resource type) than the SDK method's call site indicates. In deployments where the SDK receives identifier values that originate from untrusted sources, this could result in unintended access, modification, or deletion of resources beyond the calling user's authorization scope.
This issue is most consequential in deployments that:
- forward end-user-supplied values directly into SDK identifier parameters without first validating them against an expected format (such as a UUID), and
- rely on URL-prefix-based authorization at an upstream layer (reverse proxy, edge gateway, WAF), where the authorization decision is made on the SDK call's intended path rather than on the final delivered request path.
There have no evidence of this behavior being triggered in the wild. This change is intended to reduce the surface available when caller-supplied identifier values originate from untrusted sources.
Affected users / systems
You may be affected if you:
- use
langgraph-sdk(Python) to address resources by identifier, and - pass identifier values into SDK methods that originate from end-user input, untrusted third-party callers, or any source that does not validate identifier format before the SDK call.
Applications that validate identifier values (for example, by parsing them as UUIDs and rejecting anything that does not parse) before passing them to SDK methods are not affected. Validated UUIDs round-trip through the SDK request path unchanged.
Impact
- Potential unintended access, modification, or deletion of resources via SDK methods called for a different resource type, when caller-supplied identifier values are not validated.
- In deployments with prefix-based authorization at an upstream layer, the authorization decision and the final delivered request path may diverge.
- Confidentiality: disclosure of resource content beyond the authorization scope of the calling user.
- Integrity: modification or deletion of resources beyond the authorization scope of the calling user.
Patches / mitigation
The SDK now applies path-segment encoding to identifier values before they are interpolated into request URL templates. After this change, identifier values that contain characters with special meaning in URL paths are transmitted as encoded byte sequences and routed to the resource the SDK method's call site indicates.
Compatibility
Identifier values that match the standard UUID format, or any other format that contains only characters safe to transmit unencoded in URL path segments, round-trip through the SDK request path unchanged. Applications that already validate identifier inputs see no behavioral change.
Operational guidance
- Validate identifier values (typically as UUIDs) at the boundary where untrusted input enters the application, before passing them to SDK methods.
- For deployments relying on URL-prefix-based authorization upstream of LangGraph, prefer authorization at the LangGraph server layer or on parsed-and-validated request paths rather than on raw URL prefixes.
LangSmith / hosted deployments note
This issue affects the SDK that runs in caller applications. The LangGraph server runtime, including LangSmith-hosted deployments, receives ordinary HTTP requests on documented routes and is not itself affected by this issue. Applications that consume LangSmith-hosted services via langgraph-sdk and pass untrusted identifier values to SDK methods should upgrade.
First reported by: pucagit (CyStack).
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.3.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48776"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T18:32:35Z",
"nvd_published_at": "2026-06-17T10:55:15Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`langgraph-sdk` constructs HTTP request paths for resource operations by interpolating caller-supplied identifier values into URL templates. Without sanitization of those values, identifiers that contain characters with special meaning in URL paths could cause the resulting request to address a different resource (and potentially a different resource type) than the SDK method\u0027s call site indicates. In deployments where the SDK receives identifier values that originate from untrusted sources, this could result in unintended access, modification, or deletion of resources beyond the calling user\u0027s authorization scope.\n\nThis issue is most consequential in deployments that:\n\n- forward end-user-supplied values directly into SDK identifier parameters without first validating them against an expected format (such as a UUID), and\n- rely on URL-prefix-based authorization at an upstream layer (reverse proxy, edge gateway, WAF), where the authorization decision is made on the SDK call\u0027s intended path rather than on the final delivered request path.\n\nThere have no evidence of this behavior being triggered in the wild. This change is intended to reduce the surface available when caller-supplied identifier values originate from untrusted sources.\n\n## Affected users / systems\n\nYou may be affected if you:\n\n- use `langgraph-sdk` (Python) to address resources by identifier, and\n- pass identifier values into SDK methods that originate from end-user input, untrusted third-party callers, or any source that does not validate identifier format before the SDK call.\n\nApplications that validate identifier values (for example, by parsing them as UUIDs and rejecting anything that does not parse) before passing them to SDK methods are not affected. Validated UUIDs round-trip through the SDK request path unchanged.\n\n## Impact\n\n- Potential **unintended access, modification, or deletion** of resources via SDK methods called for a different resource type, when caller-supplied identifier values are not validated.\n- In deployments with prefix-based authorization at an upstream layer, the authorization decision and the final delivered request path may diverge.\n- Confidentiality: disclosure of resource content beyond the authorization scope of the calling user.\n- Integrity: modification or deletion of resources beyond the authorization scope of the calling user.\n\n## Patches / mitigation\n\nThe SDK now applies path-segment encoding to identifier values before they are interpolated into request URL templates. After this change, identifier values that contain characters with special meaning in URL paths are transmitted as encoded byte sequences and routed to the resource the SDK method\u0027s call site indicates.\n\n## Compatibility\n\nIdentifier values that match the standard UUID format, or any other format that contains only characters safe to transmit unencoded in URL path segments, round-trip through the SDK request path unchanged. Applications that already validate identifier inputs see no behavioral change.\n\n## Operational guidance\n\n- Validate identifier values (typically as UUIDs) at the boundary where untrusted input enters the application, before passing them to SDK methods.\n- For deployments relying on URL-prefix-based authorization upstream of LangGraph, prefer authorization at the LangGraph server layer or on parsed-and-validated request paths rather than on raw URL prefixes.\n\n## LangSmith / hosted deployments note\n\nThis issue affects the SDK that runs in caller applications. The LangGraph server runtime, including LangSmith-hosted deployments, receives ordinary HTTP requests on documented routes and is not itself affected by this issue. Applications that consume LangSmith-hosted services via `langgraph-sdk` and pass untrusted identifier values to SDK methods should upgrade.\n\nFirst reported by: pucagit (CyStack).",
"id": "GHSA-w39p-vh2g-g8g5",
"modified": "2026-06-25T18:32:35Z",
"published": "2026-06-25T18:32:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/security/advisories/GHSA-w39p-vh2g-g8g5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48776"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langgraph"
},
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langgraph/releases/tag/sdk%3D%3D0.3.15"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "LangGraph SDK has unsafe URL path construction"
}
GHSA-W3CW-FH5G-GHVR
Vulnerability from github – Published: 2022-01-12 00:00 – Updated: 2024-11-14 21:31Local Security Authority (Domain Policy) Remote Protocol Security Feature Bypass.
{
"affected": [],
"aliases": [
"CVE-2022-21913"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-11T21:15:00Z",
"severity": "MODERATE"
},
"details": "Local Security Authority (Domain Policy) Remote Protocol Security Feature Bypass.",
"id": "GHSA-w3cw-fh5g-ghvr",
"modified": "2024-11-14T21:31:54Z",
"published": "2022-01-12T00:00:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-21913"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21913"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2022-21913"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W3F7-2QFW-348X
Vulnerability from github – Published: 2022-05-13 01:18 – Updated: 2022-11-22 19:47An improper authorization vulnerability exists in Jenkins HipChat Plugin 2.2.0 and earlier in HipChatNotifier.java that allows attackers with Overall/Read access to send test notifications to an attacker-specified HipChat server with attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. As of version 2.2.1, this form validation method requires POST requests and Overall/Administer permissions.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jvnet.hudson.plugins:hipchat"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000418"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-22T19:47:07Z",
"nvd_published_at": "2019-01-09T23:29:00Z",
"severity": "HIGH"
},
"details": "An improper authorization vulnerability exists in Jenkins HipChat Plugin 2.2.0 and earlier in HipChatNotifier.java that allows attackers with Overall/Read access to send test notifications to an attacker-specified HipChat server with attacker-specified credentials IDs obtained through another method, capturing credentials stored in Jenkins. As of version 2.2.1, this form validation method requires POST requests and Overall/Administer permissions.\n\n",
"id": "GHSA-w3f7-2qfw-348x",
"modified": "2022-11-22T19:47:07Z",
"published": "2022-05-13T01:18:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000418"
},
{
"type": "WEB",
"url": "https://jenkins.io/security/advisory/2018-09-25/#SECURITY-984%20(1)"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/106532"
}
],
"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"
}
],
"summary": "Jenkins HipChat Plugin allows credential capture due to incorrect authorization"
}
Mitigation
- 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
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
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
- 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
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.