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.
5659 vulnerabilities reference this CWE, most recent first.
GHSA-7G9X-CP9G-92MR
Vulnerability from github – Published: 2026-02-19 15:16 – Updated: 2026-02-23 22:21Summary
The batch resource creation endpoints of both Kargo's legacy gRPC API and newer REST API accept multi-document YAML payloads. When either endpoint creates a Project resource, creation of subsequent resources from that same payload belonging in that Project's underlying Kubernetes namespace, by design, proceeds using the API server's own permissions. The creator of a new Project automatically becomes its administrator, but those permissions are granted asynchronously by the management controller. The design choice to create the affected resources using the API server's own permissions averts a race and is contextually appropriate.
Specially crafted payloads can manifest a bug present in the logic of both endpoints to inject arbitrary resources (of specific types only) into the underlying namespace of an existing Project using the API server's own permissions when that behavior was not intended. Critically, an attacker may exploit this as a vector for elevating their own permissions, which can then be leveraged to achieve remote code execution or secret exfiltration. Exfiltrated artifact repository credentials can be leveraged, in turn, to execute further attacks.
In some configurations of the Kargo control plane's underlying Kubernetes cluster, elevated permissions may additionally be leveraged to achieve remote code execution or secret exfiltration using kubectl. This can reduce the complexity of the attack, however, worst case scenarios remain entirely achievable even without this.
Base Metrics
The following sections provide the rationale for the values selected for each of CVSS v4's base metrics.
Attack Vector (AV): Network
The affected endpoints are served by the Kargo API server over HTTP/HTTPS. No local or physical access is required.
Attack Complexity (AC): Low
Exploitation requires only a specially crafted YAML payload sent to an affected API endpoint.
Attack Requirements (AT): None
No specific environmental conditions are required beyond those that are typical for any Kargo instance.
Privileges Required (PR): Low
The attack relies only on the ability to authenticate to the Kargo API server along with basic permissions that are typically granted to all Kargo users.
User Interaction (UI): None
The attack is fully automated via API calls. No other user needs to take any action.
Confidentiality Impact to Vulnerable System (VC): High
Elevated permissions enable secret exfiltration from any Kargo Project.
Integrity Impact to Vulnerable System (VI): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of the vulnerable system, including Kargo Projects, Kargo control plane components, and the Kargo control plane's underlying Kubernetes cluster.
Note: Because it is an integral component of Kargo's control plane, the underlying Kubernetes cluster has been counted as a component of the vulnerable system instead of a subsequent system.
Availability Impact to Vulnerable System (VA): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of the vulnerable system, including Kargo control plane components and the Kargo control plane's underlying Kubernetes cluster.
Confidentiality Impact to Subsequent Systems (SC): High
Secrets exfiltrated from Project namespaces typically contain credentials for external systems. These may enable exfiltration of further confidential information from those systems.
Integrity Impact to Subsequent Systems (SI): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of subsequent systems.
Availability Impact to Subsequent Systems (SA): High
Elevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of subsequent systems.
Mitigating Factors
-
Exploitation requires authentication to the Kargo API server. Anonymous access is not sufficient.
-
The most severe consequences of this vulnerability depend on a privilege escalation path (via
RoleBindinginjection) that was not identified by the original reporter, suggesting it is not immediately obvious from the bug alone. -
There is no evidence of exploitation in the wild.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/akuity/kargo"
},
"ranges": [
{
"events": [
{
"introduced": "1.9.0-rc.1"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/akuity/kargo"
},
"ranges": [
{
"events": [
{
"introduced": "1.8.0-rc.1"
},
{
"fixed": "1.8.11"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/akuity/kargo"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.7.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27112"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T15:16:46Z",
"nvd_published_at": "2026-02-20T22:16:29Z",
"severity": "CRITICAL"
},
"details": "## Summary\n\nThe batch resource creation endpoints of both Kargo\u0027s legacy gRPC API and newer REST API accept multi-document YAML payloads. When either endpoint creates a `Project` resource, creation of subsequent resources from that same payload belonging in that Project\u0027s underlying Kubernetes namespace, by design, proceeds using the API server\u0027s own permissions. The creator of a new Project automatically becomes its administrator, but those permissions are granted asynchronously by the management controller. The design choice to create the affected resources using the API server\u0027s own permissions averts a race and is contextually appropriate.\n\nSpecially crafted payloads can manifest a bug present in the logic of both endpoints to inject arbitrary resources (of specific types only) into the underlying namespace of an _existing_ Project using the API server\u0027s own permissions when that behavior was _not_ intended. Critically, an attacker may exploit this as a vector for elevating their own permissions, which can then be leveraged to achieve remote code execution or secret exfiltration. Exfiltrated artifact repository credentials can be leveraged, in turn, to execute further attacks.\n\nIn some configurations of the Kargo control plane\u0027s underlying Kubernetes cluster, elevated permissions may additionally be leveraged to achieve remote code execution or secret exfiltration using `kubectl`. This can reduce the complexity of the attack, however, worst case scenarios remain entirely achievable even without this.\n\n## Base Metrics\n\nThe following sections provide the rationale for the values selected for each of CVSS v4\u0027s base metrics.\n\n### Attack Vector (AV): Network\n\nThe affected endpoints are served by the Kargo API server over HTTP/HTTPS. No local or physical access is required.\n\n### Attack Complexity (AC): Low\n\nExploitation requires only a specially crafted YAML payload sent to an affected API endpoint.\n\n### Attack Requirements (AT): None\n\nNo specific environmental conditions are required beyond those that are typical for any Kargo instance.\n\n### Privileges Required (PR): Low\n\nThe attack relies only on the ability to authenticate to the Kargo API server along with basic permissions that are typically granted to all Kargo users.\n\n### User Interaction (UI): None\n\nThe attack is fully automated via API calls. No other user needs to take any action.\n\n### Confidentiality Impact to Vulnerable System (VC): High\n\nElevated permissions enable secret exfiltration from any Kargo Project.\n\n### Integrity Impact to Vulnerable System (VI): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of the vulnerable system, including Kargo Projects, Kargo control plane components, and the Kargo control plane\u0027s underlying Kubernetes cluster.\n\nNote: Because it is an integral component of Kargo\u0027s control plane, the underlying Kubernetes cluster has been counted as a component of the vulnerable system instead of a subsequent system.\n\n### Availability Impact to Vulnerable System (VA): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of the vulnerable system, including Kargo control plane components and the Kargo control plane\u0027s underlying Kubernetes cluster.\n\n### Confidentiality Impact to Subsequent Systems (SC): High\n\nSecrets exfiltrated from Project namespaces typically contain credentials for external systems. These may enable exfiltration of further confidential information from those systems.\n\n### Integrity Impact to Subsequent Systems (SI): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the integrity of subsequent systems.\n\n### Availability Impact to Subsequent Systems (SA): High\n\nElevated permissions enable tampering, up to and including remote code execution, as well as secret exfiltration from any Kargo Project. Project secrets often include credentials having write permissions to GitOps repositories. Such secrets may enable pushing configurations that impact the availability of subsequent systems.\n\n## Mitigating Factors\n\n- Exploitation requires authentication to the Kargo API server. Anonymous access is not sufficient.\n\n- The most severe consequences of this vulnerability depend on a privilege escalation path (via `RoleBinding` injection) that was not identified by the original reporter, suggesting it is not immediately obvious from the bug alone.\n\n- There is no evidence of exploitation in the wild.",
"id": "GHSA-7g9x-cp9g-92mr",
"modified": "2026-02-23T22:21:26Z",
"published": "2026-02-19T15:16:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/akuity/kargo/security/advisories/GHSA-7g9x-cp9g-92mr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27112"
},
{
"type": "WEB",
"url": "https://github.com/akuity/kargo/commit/155c6852ffbffa2902f18e6c7add91a846e8d344"
},
{
"type": "PACKAGE",
"url": "https://github.com/akuity/kargo"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
"type": "CVSS_V4"
}
],
"summary": "Kargo has an Authorization Bypass Vulnerability in Batch Resource Creation API Endpoints"
}
GHSA-7GC6-QH9X-W6H8
Vulnerability from github – Published: 2022-04-17 00:00 – Updated: 2025-10-08 19:22Withdrawn Advisory
This advisory has been withdrawn because the vulnerability originates from a dependency. For more information, see the Maintainer comments in https://huntr.com/bounties/ab55dfdd-2a60-437a-a832-e3efe3d264ac.
Original Description
When fetching a remote url with Cookie if it get Location response header then it will follow that url and try to fetch that url with provided cookie . So cookie is leaked here to thirdparty. Ex: you try to fetch example.com with cookie and if it get redirect url to attacker.com then it fetch that redirect url with provided cookie .
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "cross-fetch"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "cross-fetch"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-1365"
],
"database_specific": {
"cwe_ids": [
"CWE-359",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-28T20:45:25Z",
"nvd_published_at": "2022-04-15T23:15:00Z",
"severity": "MODERATE"
},
"details": "## Withdrawn Advisory\nThis advisory has been withdrawn because the vulnerability originates from a dependency. For more information, see the `Maintainer` comments in https://huntr.com/bounties/ab55dfdd-2a60-437a-a832-e3efe3d264ac.\n\n## Original Description\nWhen fetching a remote url with Cookie if it get Location response header then it will follow that url and try to fetch that url with provided cookie . So cookie is leaked here to thirdparty.\nEx: you try to fetch example.com with cookie and if it get redirect url to attacker.com then it fetch that redirect url with provided cookie .",
"id": "GHSA-7gc6-qh9x-w6h8",
"modified": "2025-10-08T19:22:14Z",
"published": "2022-04-17T00:00:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-1365"
},
{
"type": "WEB",
"url": "https://github.com/lquixada/cross-fetch/pull/135"
},
{
"type": "WEB",
"url": "https://github.com/lquixada/cross-fetch/commit/a3b3a9481091ddd06b8f83784ba9c4e034dc912a"
},
{
"type": "PACKAGE",
"url": "https://github.com/lquixada/cross-fetch"
},
{
"type": "WEB",
"url": "https://huntr.dev/bounties/ab55dfdd-2a60-437a-a832-e3efe3d264ac"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Withdrawn Advisory: Incorrect Authorization in cross-fetch",
"withdrawn": "2025-10-08T19:22:14Z"
}
GHSA-7GFC-8CQ8-JH5F
Vulnerability from github – Published: 2024-12-17 15:09 – Updated: 2025-09-10 21:12Impact
If a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.
Patches
This issue was patched in Next.js 14.2.15 and later.
If your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.
Workarounds
There are no official workarounds for this vulnerability.
Credits
We'd like to thank tyage (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "9.5.5"
},
{
"fixed": "14.2.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-51479"
],
"database_specific": {
"cwe_ids": [
"CWE-285",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2024-12-17T15:09:06Z",
"nvd_published_at": "2024-12-17T19:15:06Z",
"severity": "HIGH"
},
"details": "### Impact\nIf a Next.js application is performing authorization in middleware based on pathname, it was possible for this authorization to be bypassed.\n\n### Patches\nThis issue was patched in Next.js `14.2.15` and later.\n\nIf your Next.js application is hosted on Vercel, this vulnerability has been automatically mitigated, regardless of Next.js version.\n\n### Workarounds\nThere are no official workarounds for this vulnerability.\n\n#### Credits\nWe\u0027d like to thank [tyage](http://github.com/tyage) (GMO CyberSecurity by IERAE) for responsible disclosure of this issue.",
"id": "GHSA-7gfc-8cq8-jh5f",
"modified": "2025-09-10T21:12:24Z",
"published": "2024-12-17T15:09:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-7gfc-8cq8-jh5f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51479"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/commit/1c8234eb20bc8afd396b89999a00f06b61d72d7b"
},
{
"type": "PACKAGE",
"url": "https://github.com/vercel/next.js"
},
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/releases/tag/v14.2.15"
}
],
"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"
}
],
"summary": "Next.js authorization bypass vulnerability"
}
GHSA-7GGC-8FV3-QJPJ
Vulnerability from github – Published: 2025-08-06 18:31 – Updated: 2025-08-06 18:31A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to modify parts of the configuration on an affected device.
This vulnerability is due to the lack of server-side validation of Administrator permissions. An attacker could exploit this vulnerability by submitting a crafted HTTP request to an affected system. A successful exploit could allow the attacker to modify descriptions of files on a specific page. To exploit this vulnerability, an attacker would need valid read-only Administrator credentials.
{
"affected": [],
"aliases": [
"CVE-2025-20332"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T17:15:38Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the web-based management interface of Cisco ISE could allow an authenticated, remote attacker to modify parts of the configuration on an affected device.\n\nThis vulnerability is due to the lack of server-side validation of Administrator permissions. An attacker could exploit this vulnerability by submitting a crafted HTTP request to an affected system. A successful exploit could allow the attacker to modify descriptions of files on a specific page. To exploit this vulnerability, an attacker would need valid read-only Administrator\u0026nbsp;credentials.",
"id": "GHSA-7ggc-8fv3-qjpj",
"modified": "2025-08-06T18:31:21Z",
"published": "2025-08-06T18:31:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20332"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ise_xss_acc_cont-YsR4uT4U"
}
],
"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-7GPQ-38WJ-HV97
Vulnerability from github – Published: 2022-04-12 00:00 – Updated: 2022-04-20 00:00Improper access control vulnerability in Samsung Security Supporter prior to version 1.2.40.0 allows attacker to set the arbitrary folder as Secret Folder without Samsung Security Supporter permission
{
"affected": [],
"aliases": [
"CVE-2022-28778"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-04-11T20:15:00Z",
"severity": "LOW"
},
"details": "Improper access control vulnerability in Samsung Security Supporter prior to version 1.2.40.0 allows attacker to set the arbitrary folder as Secret Folder without Samsung Security Supporter permission",
"id": "GHSA-7gpq-38wj-hv97",
"modified": "2022-04-20T00:00:57Z",
"published": "2022-04-12T00:00:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28778"
},
{
"type": "WEB",
"url": "https://security.samsungmobile.com/serviceWeb.smsb?year=2022\u0026month=4"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-7GVM-PRWV-W6HM
Vulnerability from github – Published: 2026-03-26 21:31 – Updated: 2026-03-27 21:31Incorrect Authorization vulnerability in Drupal File Access Fix (deprecated) allows Forceful Browsing.This issue affects File Access Fix (deprecated): from 0.0.0 before 1.2.0.
{
"affected": [],
"aliases": [
"CVE-2026-3525"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-26T21:17:08Z",
"severity": "MODERATE"
},
"details": "Incorrect Authorization vulnerability in Drupal File Access Fix (deprecated) allows Forceful Browsing.This issue affects File Access Fix (deprecated): from 0.0.0 before 1.2.0.",
"id": "GHSA-7gvm-prwv-w6hm",
"modified": "2026-03-27T21:31:34Z",
"published": "2026-03-26T21:31:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3525"
},
{
"type": "WEB",
"url": "https://www.drupal.org/sa-contrib-2026-020"
}
],
"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-7GXG-937V-GFC4
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14An unauthorized user was able to insert metadata when creating new issue on GitLab CE/EE 14.0 and later.
{
"affected": [],
"aliases": [
"CVE-2021-22239"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "An unauthorized user was able to insert metadata when creating new issue on GitLab CE/EE 14.0 and later.",
"id": "GHSA-7gxg-937v-gfc4",
"modified": "2022-05-24T19:14:00Z",
"published": "2022-05-24T19:14:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22239"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22239.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/336301"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-7H94-344F-429F
Vulnerability from github – Published: 2026-07-23 09:32 – Updated: 2026-07-23 09:32An Incorrect Authorization vulnerability in Linux-Gaming PortProtonQt allows any users to mount and unmount arbitrary file systems and modify the network configuration via NetworkManager.
This issue affects PortProtonQt before 0d0f0950ebd948cdf82e8c3e1ebd2bcb9b8bafbe.
{
"affected": [],
"aliases": [
"CVE-2026-59678"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-23T08:16:25Z",
"severity": "HIGH"
},
"details": "An Incorrect Authorization vulnerability in Linux-Gaming PortProtonQt allows any users to mount and unmount arbitrary file systems and modify the network configuration via NetworkManager.\n\n\n\n\n\n\nThis issue affects PortProtonQt before 0d0f0950ebd948cdf82e8c3e1ebd2bcb9b8bafbe.",
"id": "GHSA-7h94-344f-429f",
"modified": "2026-07-23T09:32:00Z",
"published": "2026-07-23T09:32:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59678"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-59678"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7HC9-W8Q3-PJPJ
Vulnerability from github – Published: 2025-08-12 03:31 – Updated: 2025-08-12 03:31Due to broken authorization, SAP Business One (SLD) allows an authenticated attacker to gain administrator privileges of a database by invoking the corresponding API.�As a result , it has a high impact on the confidentiality, integrity, and availability of the application.
{
"affected": [],
"aliases": [
"CVE-2025-42951"
],
"database_specific": {
"cwe_ids": [
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-12T03:15:27Z",
"severity": "HIGH"
},
"details": "Due to broken authorization, SAP Business One (SLD) allows an authenticated attacker to gain administrator privileges of a database by invoking the corresponding API.\ufffdAs a result , it has a high impact on the confidentiality, integrity, and availability of the application.",
"id": "GHSA-7hc9-w8q3-pjpj",
"modified": "2025-08-12T03:31:52Z",
"published": "2025-08-12T03:31:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-42951"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3625403"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"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-7HGC-PHP5-77QQ
Vulnerability from github – Published: 2022-09-16 17:21 – Updated: 2022-09-19 20:23Impact
Talos worker nodes use a join token to get accepted into the Talos cluster. A misconfigured Kubernetes environment may allow workloads to access the join token of the worker node. A malicious workload could then use the join token to construct a Talos CSR (certificate signing request). Due to improper validation while signing a worker node CSR, a Talos control plane node might issue a Talos certificate which allows full access to the Talos API to a worker node that presented a maliciously constructed CSR. Accessing the Talos API with full access on a control plane node might reveal sensitive information, which could allow full-level access to the cluster (Kubernetes and Talos PKI, etc.)
In order to exploit the weakness, a Kubernetes workload would need to access the join token, and then construct a specific kind of Talos CSR in order to obtain a privileged certificate. The Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads do not have access to the machine configuration, and thus cannot access the token, nor acquire elevated privileges.
It is possible that users have misconfigured Kubernetes in such a way as to allow a workload to access the machine configuration and reveal the join token. Misconfigurations that may allow the machine configuration to be accessed on a worker node by the Kubernetes workload are:
- allowing a
hostPathmount to mount the machine config directly from the host filesystem (hostPathmounts should not be allowed for untrusted workloads, and are disabled by default in recent versions of Talos.) - reading machine configuration from a cloud metadata server from Kubernetes pods with host networking (on cloud platforms, when machine config is stored in the cloud metadata server, and the cloud metadata server doesn't provide enough protection to prevent access from non-host workloads)
Patches
The problem was fixed in Talos 1.2.2.
Workarounds
Enabling the Pod Security Standards mitigates the vulnerability by denying hostPath mounts and host networking by default in the baseline policy. Talos enables Pod Security Admission plugin by default since Talos v1.1.0.
Clusters that don't run untrusted workloads are not affected.
Clusters with correct Pod Security configurations which don't allow hostPath mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.
References
For more information
If you have any questions or comments about this advisory:
- Email us at security@siderolabs.com
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/talos-systems/talos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-36103"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-16T17:21:09Z",
"nvd_published_at": "2022-09-13T17:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\n\nTalos worker nodes use a join token to get accepted into the Talos cluster. A misconfigured Kubernetes environment may allow workloads to access the join token of the worker node. A malicious workload could then use the join token to construct a Talos CSR (certificate signing request). Due to improper validation while signing a worker node CSR, a Talos control plane node might issue a Talos certificate which allows full access to the Talos API to a worker node that presented a maliciously constructed CSR. Accessing the Talos API with full access on a control plane node might reveal sensitive information, which could allow full-level access to the cluster (Kubernetes and Talos PKI, etc.)\n\nIn order to exploit the weakness, a Kubernetes workload would need to access the join token, and then construct a specific kind of Talos CSR in order to obtain a privileged certificate. The Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads do not have access to the machine configuration, and thus cannot access the token, nor acquire elevated privileges.\n\nIt is possible that users have misconfigured Kubernetes in such a way as to allow a workload to access the machine configuration and reveal the join token. Misconfigurations that may allow the machine configuration to be accessed on a worker node by the Kubernetes workload are:\n\n* allowing a `hostPath` mount to mount the machine config directly from the host filesystem (`hostPath` mounts should not be allowed for untrusted workloads, and are disabled by default in recent versions of Talos.)\n* reading machine configuration from a cloud metadata server from Kubernetes pods with host networking (on cloud platforms, when machine config is stored in the cloud metadata server, and the cloud metadata server doesn\u0027t provide enough protection to prevent access from non-host workloads)\n\n### Patches\n\nThe problem was fixed in Talos 1.2.2.\n\n### Workarounds\n\nEnabling the [Pod Security Standards](https://www.talos.dev/v1.2/kubernetes-guides/configuration/pod-security/) mitigates the vulnerability by denying `hostPath` mounts and host networking by default in the [baseline](https://kubernetes.io/docs/concepts/security/pod-security-standards/#baseline) policy. Talos enables Pod Security Admission plugin by default since [Talos v1.1.0](https://www.talos.dev/v1.1/introduction/what-is-new/#pod-security-admission).\n\nClusters that don\u0027t run untrusted workloads are not affected.\nClusters with correct Pod Security configurations which don\u0027t allow `hostPath` mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.\n\n### References\n\n* [Talos v1.2.2 release](https://github.com/siderolabs/talos/releases/tag/v1.2.2)\n* [Fixing commit](https://github.com/siderolabs/talos/commit/9eaf33f3f274e746ca1b442c0a1a0dae0cec088f)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n\n* Email us at [security@siderolabs.com](mailto:security@siderolabs.com)\n",
"id": "GHSA-7hgc-php5-77qq",
"modified": "2022-09-19T20:23:28Z",
"published": "2022-09-16T17:21:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/security/advisories/GHSA-7hgc-php5-77qq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36103"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/commit/9eaf33f3f274e746ca1b442c0a1a0dae0cec088f"
},
{
"type": "PACKAGE",
"url": "https://github.com/siderolabs/talos"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/releases/tag/v1.2.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Talos worker join token can be used to get elevated access level to the Talos API"
}
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.