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.
5689 vulnerabilities reference this CWE, most recent first.
GHSA-3PX7-C4J3-576R
Vulnerability from github – Published: 2025-06-02 12:30 – Updated: 2025-06-05 01:04A security vulnerability in the /apis/dashboard.grafana.app/* endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1).
Impact:
-
Viewers can view all dashboards/folders regardless of permissions
-
Editors can view/edit/delete all dashboards/folders regardless of permissions
-
Editors can create dashboards in any folder regardless of permissions
-
Anonymous users with viewer/editor roles are similarly affected
Organization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/grafana/grafana"
},
"ranges": [
{
"events": [
{
"introduced": "0.0.0-20250114093457-36d6fad421fb"
},
{
"fixed": "0.0.0-20250521183405-c7a690348df7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-3260"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-05T01:03:59Z",
"nvd_published_at": "2025-06-02T10:15:21Z",
"severity": "HIGH"
},
"details": "A security vulnerability in the /apis/dashboard.grafana.app/* endpoints allows authenticated users to bypass dashboard and folder permissions. The vulnerability affects all API versions (v0alpha1, v1alpha1, v2alpha1).\n\nImpact:\n\n- Viewers can view all dashboards/folders regardless of permissions\n\n- Editors can view/edit/delete all dashboards/folders regardless of permissions\n\n- Editors can create dashboards in any folder regardless of permissions\n\n- Anonymous users with viewer/editor roles are similarly affected\n\nOrganization isolation boundaries remain intact. The vulnerability only affects dashboard access and does not grant access to datasources.",
"id": "GHSA-3px7-c4j3-576r",
"modified": "2025-06-05T01:04:00Z",
"published": "2025-06-02T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3260"
},
{
"type": "PACKAGE",
"url": "https://github.com/grafana/grafana"
},
{
"type": "WEB",
"url": "https://github.com/grafana/grafana/blob/be8d153dc33734caba4f617ff571d18253e68fa0/CHANGELOG.md#1161-2025-04-23"
},
{
"type": "WEB",
"url": "https://grafana.com/blog/2025/04/22/grafana-security-release-medium-and-high-severity-fixes-for-cve-2025-3260-cve-2025-2703-cve-2025-3454"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/CVE-2025-3260"
}
],
"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:L",
"type": "CVSS_V3"
}
],
"summary": "Grafana vulnerable to authenticated users bypassing dashboard, folder permissions"
}
GHSA-3PX8-7PJ4-M3R5
Vulnerability from github – Published: 2022-05-24 19:05 – Updated: 2022-05-24 19:05Information exposure vulnerability in Gear S Plugin prior to version 2.2.05.20122441 allows unstrusted applications to access connected BT device information.
{
"affected": [],
"aliases": [
"CVE-2021-25406"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-11T15:15:00Z",
"severity": "MODERATE"
},
"details": "Information exposure vulnerability in Gear S Plugin prior to version 2.2.05.20122441 allows unstrusted applications to access connected BT device information.",
"id": "GHSA-3px8-7pj4-m3r5",
"modified": "2022-05-24T19:05:08Z",
"published": "2022-05-24T19:05:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25406"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2021\u0026month=5"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-3Q29-6C6H-84HH
Vulnerability from github – Published: 2022-07-15 00:00 – Updated: 2022-07-26 00:01The Guest account feature in Mattermost version 6.7.0 and earlier fails to properly restrict the permissions, which allows a guest user to fetch a list of all public channels in the team, in spite of not being part of those channels.
{
"affected": [],
"aliases": [
"CVE-2022-2408"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-668",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-07-14T18:15:00Z",
"severity": "MODERATE"
},
"details": "The Guest account feature in Mattermost version 6.7.0 and earlier fails to properly restrict the permissions, which allows a guest user to fetch a list of all public channels in the team, in spite of not being part of those channels.",
"id": "GHSA-3q29-6c6h-84hh",
"modified": "2022-07-26T00:01:03Z",
"published": "2022-07-15T00:00:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-2408"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3Q2P-72CJ-682C
Vulnerability from github – Published: 2026-06-12 21:07 – Updated: 2026-07-21 14:45Summary
This is similar vulnrability of CVE-2026-0035, which was fixed in Android MediaProvider with high severity. In the original Java issue, MediaStore.createWriteRequest() accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.
filebrowser/filebrowser has the analogous issue in Go. POST /api/share/<path> accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through GET /api/public/dl/<hash>.
Details
The vulnerable create path is:
http/share.gosharePostHandler()- route:
POST /api/share/<path>
sharePostHandler() only checks that the caller is authenticated and has share/download permissions. It then builds a share.Link directly from r.URL.Path and saves it:
s = &share.Link{
Path: r.URL.Path,
Hash: str,
Expire: expire,
UserID: d.user.ID,
PasswordHash: string(hash),
Token: token,
}
if err := d.store.Share.Save(s); err != nil {
return http.StatusInternalServerError, err
}
There is no Stat, Exists, or equivalent check before the public share record is committed.
The vulnerable consume path is:
http/public.gowithHashFile()- routes:
GET /api/public/share/<hash>,GET /api/public/dl/<hash>
Each public request loads the saved share by hash and then resolves link.Path against the owner's current filesystem state:
file, err := files.NewFileInfo(&files.FileOptions{
Fs: d.user.Fs,
Path: link.Path,
...
})
This means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.
PoC
The PoC below starts from external HTTP input only.
- Authenticate to File Browser.
- Confirm
/future4.txtdoes not exist. - Create a public share for
/future4.txtanyway. - Confirm the public share returns
404. - Upload a file to
/future4.txt. - Reuse the same public share URL and read the file content.
Reproduction commands:
TOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \
-H 'Content-Type: application/json' \
-d '{"username":"admin","password":"Password123!"}')
curl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \
-H "X-Auth: $TOKEN" \
-H 'Content-Type: application/json' \
-d '{}'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
curl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \
-H "X-Auth: $TOKEN" \
--data-binary 'fourth-secret'
curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO
Impact
An authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.
Reference
Original CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.6"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54096"
],
"database_specific": {
"cwe_ids": [
"CWE-367",
"CWE-668",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T21:07:55Z",
"nvd_published_at": "2026-06-25T19:16:41Z",
"severity": "HIGH"
},
"details": "### Summary\nThis is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.\n\n`filebrowser/filebrowser` has the analogous issue in Go. `POST /api/share/\u003cpath\u003e` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/\u003chash\u003e`.\n\n### Details\nThe vulnerable create path is:\n\n- `http/share.go`\n- `sharePostHandler()`\n- route: `POST /api/share/\u003cpath\u003e`\n\n`sharePostHandler()` only checks that the caller is authenticated and has share/download permissions. It then builds a `share.Link` directly from `r.URL.Path` and saves it:\n\n```go\ns = \u0026share.Link{\n Path: r.URL.Path,\n Hash: str,\n Expire: expire,\n UserID: d.user.ID,\n PasswordHash: string(hash),\n Token: token,\n}\n\nif err := d.store.Share.Save(s); err != nil {\n return http.StatusInternalServerError, err\n}\n```\n\nThere is no `Stat`, `Exists`, or equivalent check before the public share record is committed.\n\nThe vulnerable consume path is:\n\n- `http/public.go`\n- `withHashFile()`\n- routes: `GET /api/public/share/\u003chash\u003e`, `GET /api/public/dl/\u003chash\u003e`\n\nEach public request loads the saved share by hash and then resolves `link.Path` against the owner\u0027s current filesystem state:\n\n```go\nfile, err := files.NewFileInfo(\u0026files.FileOptions{\n Fs: d.user.Fs,\n Path: link.Path,\n ...\n})\n```\n\nThis means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.\n\n\n### PoC\nThe PoC below starts from external HTTP input only.\n\n1. Authenticate to File Browser.\n2. Confirm `/future4.txt` does not exist.\n3. Create a public share for `/future4.txt` anyway.\n4. Confirm the public share returns `404`.\n5. Upload a file to `/future4.txt`.\n6. Reuse the same public share URL and read the file content.\n\nReproduction commands:\n\n```bash\nTOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{\"username\":\"admin\",\"password\":\"Password123!\"}\u0027)\n\ncurl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n -H \u0027Content-Type: application/json\u0027 \\\n -d \u0027{}\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n\ncurl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \\\n -H \"X-Auth: $TOKEN\" \\\n --data-binary \u0027fourth-secret\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n```\n\n\n### Impact\nAn authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.\n\n### Reference\n\nOriginal CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035",
"id": "GHSA-3q2p-72cj-682c",
"modified": "2026-07-21T14:45:00Z",
"published": "2026-06-12T21:07:55Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3q2p-72cj-682c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54096"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/166583db632e088e9f0adce30aec43bb9d9019f4"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.7"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path"
}
GHSA-3Q3M-HFJX-W733
Vulnerability from github – Published: 2024-11-01 06:30 – Updated: 2024-11-01 06:30Sysmac Studio provided by OMRON Corporation contains an incorrect authorization vulnerability. If this vulnerability is exploited, an attacker may access the program which is protected by Data Protection function.
{
"affected": [],
"aliases": [
"CVE-2024-49501"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-01T05:15:06Z",
"severity": "MODERATE"
},
"details": "Sysmac Studio provided by OMRON Corporation contains an incorrect authorization vulnerability. If this vulnerability is exploited, an attacker may access the program which is protected by Data Protection function.",
"id": "GHSA-3q3m-hfjx-w733",
"modified": "2024-11-01T06:30:35Z",
"published": "2024-11-01T06:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49501"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/vu/JVNVU95685374"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/en/OMSR-2024-006_en.pdf"
},
{
"type": "WEB",
"url": "https://www.fa.omron.co.jp/product/security/assets/pdf/ja/OMSR-2024-006_ja.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3Q79-GJF7-RWWF
Vulnerability from github – Published: 2022-05-24 19:11 – Updated: 2022-10-25 19:00ZStack is open source IaaS(infrastructure as a service) software aiming to automate datacenters, managing resources of compute, storage, and networking all by APIs. Affected versions of ZStack REST API are vulnerable to post-authentication Remote Code Execution (RCE) via bypass of the Groovy shell sandbox. The REST API exposes the GET zstack/v1/batch-queries?script endpoint which is backed up by the BatchQueryAction class. Messages are represented by the APIBatchQueryMsg, dispatched to the QueryFacadeImpl facade and handled by the BatchQuery class. The HTTP request parameter script is mapped to the APIBatchQueryMsg.script property and evaluated as a Groovy script in BatchQuery.query the evaluation of the user-controlled Groovy script is sandboxed by SandboxTransformer which will apply the restrictions defined in the registered (sandbox.register()) GroovyInterceptor. Even though the sandbox heavily restricts the receiver types to a small set of allowed types, the sandbox is non effective at controlling any code placed in Java annotations and therefore vulnerable to meta-programming escapes. This issue leads to post-authenticated remote code execution. For more details see the referenced GHSL-2021-065. This issue is patched in versions 3.8.21, 3.10.8, and 4.1.0.
{
"affected": [],
"aliases": [
"CVE-2021-32829"
],
"database_specific": {
"cwe_ids": [
"CWE-863",
"CWE-94"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-17T16:15:00Z",
"severity": "CRITICAL"
},
"details": "ZStack is open source IaaS(infrastructure as a service) software aiming to automate datacenters, managing resources of compute, storage, and networking all by APIs. Affected versions of ZStack REST API are vulnerable to post-authentication Remote Code Execution (RCE) via bypass of the Groovy shell sandbox. The REST API exposes the GET zstack/v1/batch-queries?script endpoint which is backed up by the BatchQueryAction class. Messages are represented by the APIBatchQueryMsg, dispatched to the QueryFacadeImpl facade and handled by the BatchQuery class. The HTTP request parameter script is mapped to the APIBatchQueryMsg.script property and evaluated as a Groovy script in BatchQuery.query the evaluation of the user-controlled Groovy script is sandboxed by SandboxTransformer which will apply the restrictions defined in the registered (sandbox.register()) GroovyInterceptor. Even though the sandbox heavily restricts the receiver types to a small set of allowed types, the sandbox is non effective at controlling any code placed in Java annotations and therefore vulnerable to meta-programming escapes. This issue leads to post-authenticated remote code execution. For more details see the referenced GHSL-2021-065. This issue is patched in versions 3.8.21, 3.10.8, and 4.1.0.",
"id": "GHSA-3q79-gjf7-rwwf",
"modified": "2022-10-25T19:00:31Z",
"published": "2022-05-24T19:11:26Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/zstackio/zstack/security/advisories/GHSA-6xgq-7rqg-x3q5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32829"
},
{
"type": "WEB",
"url": "https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2021-065-zstack"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3Q9F-2CP9-WP8V
Vulnerability from github – Published: 2022-05-24 19:20 – Updated: 2022-07-13 00:00Improper access control in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0151"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-17T20:15:00Z",
"severity": "HIGH"
},
"details": "Improper access control in the installer for some Intel(R) Wireless Bluetooth(R) and Killer(TM) Bluetooth(R) products in Windows 10 may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-3q9f-2cp9-wp8v",
"modified": "2022-07-13T00:00:58Z",
"published": "2022-05-24T19:20:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0151"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00540.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-3QHG-XWPV-HRWG
Vulnerability from github – Published: 2022-03-19 00:00 – Updated: 2022-03-29 00:01This issue was addressed with improved checks. This issue is fixed in watchOS 8.5, iOS 15.4 and iPadOS 15.4. A user may be able to bypass the Emergency SOS passcode prompt.
{
"affected": [],
"aliases": [
"CVE-2022-22618"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-03-18T18:15:00Z",
"severity": "HIGH"
},
"details": "This issue was addressed with improved checks. This issue is fixed in watchOS 8.5, iOS 15.4 and iPadOS 15.4. A user may be able to bypass the Emergency SOS passcode prompt.",
"id": "GHSA-3qhg-xwpv-hrwg",
"modified": "2022-03-29T00:01:33Z",
"published": "2022-03-19T00:00:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22618"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213182"
},
{
"type": "WEB",
"url": "https://support.apple.com/en-us/HT213193"
}
],
"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-3QJ2-76XW-WWH7
Vulnerability from github – Published: 2025-01-21 21:30 – Updated: 2025-01-21 21:30Vulnerability in the Oracle Agile PLM Framework product of Oracle Supply Chain (component: SDK-Software Development Kit). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile PLM Framework. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Agile PLM Framework accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).
{
"affected": [],
"aliases": [
"CVE-2025-21560"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-21T21:15:22Z",
"severity": "MODERATE"
},
"details": "Vulnerability in the Oracle Agile PLM Framework product of Oracle Supply Chain (component: SDK-Software Development Kit). The supported version that is affected is 9.3.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Agile PLM Framework. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Agile PLM Framework accessible data. CVSS 3.1 Base Score 6.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N).",
"id": "GHSA-3qj2-76xw-wwh7",
"modified": "2025-01-21T21:30:56Z",
"published": "2025-01-21T21:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21560"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2025.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-3QJ5-4M44-45XW
Vulnerability from github – Published: 2024-06-18 06:30 – Updated: 2026-04-08 21:32The Tickera – WordPress Event Ticketing plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the tc_dl_delete_tickets AJAX action in all versions up to, and including, 3.5.2.8. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete all tickets associated with events.
{
"affected": [],
"aliases": [
"CVE-2024-5860"
],
"database_specific": {
"cwe_ids": [
"CWE-862",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-18T04:15:11Z",
"severity": "MODERATE"
},
"details": "The Tickera \u2013 WordPress Event Ticketing plugin for WordPress is vulnerable to unauthorized loss of data due to a missing capability check on the tc_dl_delete_tickets AJAX action in all versions up to, and including, 3.5.2.8. This makes it possible for authenticated attackers, with Subscriber-level access and above, to delete all tickets associated with events.",
"id": "GHSA-3qj5-4m44-45xw",
"modified": "2026-04-08T21:32:47Z",
"published": "2024-06-18T06:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5860"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3103413%40tickera-event-ticketing-system\u0026new=3103413%40tickera-event-ticketing-system\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/d86aa41c-24df-49ec-b273-7bb57addddde?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
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.