CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2224 vulnerabilities reference this CWE, most recent first.
GHSA-QCR3-HR2F-6557
Vulnerability from github – Published: 2022-03-30 00:00 – Updated: 2024-10-22 14:50An issue was discovered in SaltStack Salt in versions before 3002.8, 3003.4, 3004.1. When configured as a Master-of-Masters, with a publisher_acl, if a user configured in the publisher_acl targets any minion connected to the Syndic, the Salt Master incorrectly interpreted no valid targets as valid, allowing configured users to target any of the minions connected to the syndic with their configured commands. This requires a syndic master combined with publisher_acl configured on the Master-of-Masters, allowing users specified in the publisher_acl to bypass permissions, publishing authorized commands to any configured minion.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "salt"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3002.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "salt"
},
"ranges": [
{
"events": [
{
"introduced": "3003"
},
{
"fixed": "3003.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "salt"
},
"ranges": [
{
"events": [
{
"introduced": "3004"
},
{
"fixed": "3004.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-22941"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-22T21:15:02Z",
"nvd_published_at": "2022-03-29T17:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in SaltStack Salt in versions before 3002.8, 3003.4, 3004.1. When configured as a Master-of-Masters, with a publisher_acl, if a user configured in the publisher_acl targets any minion connected to the Syndic, the Salt Master incorrectly interpreted no valid targets as valid, allowing configured users to target any of the minions connected to the syndic with their configured commands. This requires a syndic master combined with publisher_acl configured on the Master-of-Masters, allowing users specified in the publisher_acl to bypass permissions, publishing authorized commands to any configured minion.",
"id": "GHSA-qcr3-hr2f-6557",
"modified": "2024-10-22T14:50:15Z",
"published": "2022-03-30T00:00:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22941"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/salt/PYSEC-2022-174.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/saltstack/salt"
},
{
"type": "WEB",
"url": "https://github.com/saltstack/salt/blob/8f9405cf8e6f7d7776d5000841c886dec6d96250/doc/topics/releases/3002.8.rst#L31"
},
{
"type": "WEB",
"url": "https://github.com/saltstack/salt/blob/8f9405cf8e6f7d7776d5000841c886dec6d96250/doc/topics/releases/3003.4.rst#L32"
},
{
"type": "WEB",
"url": "https://github.com/saltstack/salt/blob/8f9405cf8e6f7d7776d5000841c886dec6d96250/doc/topics/releases/3004.1.rst#L30"
},
{
"type": "WEB",
"url": "https://repo.saltproject.io"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202310-22"
}
],
"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": "SaltStack Salt Permissions Bypass"
}
GHSA-QF5V-M7P4-95RP
Vulnerability from github – Published: 2026-07-28 20:12 – Updated: 2026-07-28 20:12Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (ValidatePodSpecSafety / ValidateContainerSafety admission webhook + sanitizeContainerSecurityContext executor merge layer), but the
capability check was implemented as a fixed denylist of six Linux capabilities (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted CAP_SYS_TIME, among others. As a result, a tenant
who could create a Function or Environment CRD could request securityContext.capabilities.add: ["SYS_TIME"], pass Fission's admission validation and merge-layer sanitization, and run attacker-controlled code with CAP_SYS_TIME in the
resulting function or runtime container.
Demonstrated consequence: cross-tenant node integrity damage via CAP_SYS_TIME. The Linux real-time clock is not namespaced — time namespaces virtualize only MONOTONIC and BOOTTIME, never REALTIME — so a tenant container holding
CAP_SYS_TIME could call clock_settime(CLOCK_REALTIME) and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on
the node.
The denylist also omitted SYS_RAWIO, BPF, SYS_RESOURCE, and MAC_ADMIN. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not
exercised in this report).
The deeper structural problem: a denylist on capabilities.add cannot constrain capabilities the OCI runtime grants by default — DAC_OVERRIDE is in the OCI default cap set and reaches the container regardless of any add check,
partially mooting the denylist for its own entries. A capability allowlist (with drop:["ALL"] to remove the default set) is the only model that addresses both problems.
Affected
- Project:
github.com/fission/fission - Versions:
<= 1.24.0 - Audited commits: v1.24.0 tag (
ce617120) and current HEAD at audit time - Component:
pkg/apis/core/v1/podspec_safety.go(dangerousCapabilities) andpkg/executor/util/merge.go(dangerousMergeContainerCapabilities) - Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA
restrictedin force the API server's PodSecurity admission rejects the pod at creation and this finding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.
Fix section (paste into the Fix / Patches field)
Fixed in v1.25.0 by:
- PR #3465 (commit
2569b42b) — replace the denylist with a PSA-restricted allowlist (NET_BIND_SERVICEonly) at both enforcement layers: pkg/apis/core/v1/podspec_safety.go—ValidateContainerSafetynow rejects anycapabilities.addentry not inallowedCapabilities. The container check is invoked fromValidatePodSpecSafetyfor every PodSpec container / init-container and fromEnvironment.validateForAdmissionfor the bareRuntime.Container/Builder.Container.pkg/executor/util/merge.go—sanitizeContainerSecurityContextfilterscapabilities.addthrough the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).- The same PR adds 21 bounded CEL
XValidationrules covering the cheap pod-level invariants (hostNetwork/hostPID/hostIPC/serviceAccountName/serviceAccountoverride) onFunctionSpec,Runtime, andBuilder, plus the bare-ContainerSecurityContextchecks (privileged != true,allowPrivilegeEscalation != true,capabilities.add ⊆ {NET_BIND_SERVICE}) onRuntimeandBuilder. The API server now short-circuits those attack vectors per CRD apply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server's CEL cost budget. - The same PR also adds two forward-compat regression guards in
pkg/apis/core/v1/podspec_safety_test.go: TestAllTenantContainerSurfacesAreValidatedwalks every CRD root type via reflection and fails if any reachable*apiv1.PodSpecor*apiv1.Containerfield is missing from the hand-maintained known-covered set.TestTenantContainerSurfaces_RejectSysAdminend-to-end exercises each covered surface and assertsValidateForAdmissionrejects aSYS_ADMINinjection at that exact path.
Not addressed in v1.25.0
The advisory's structural recommendation to force capabilities.drop: ["ALL"] at the merge layer is not part of this fix. Fission's own sidecar containers (fission-fetcher, builder) were authored against the OCI default capability
set and need a per-container cap audit before drop:["ALL"] can be applied uniformly. The allowlist on capabilities.add closes the demonstrated CAP_SYS_TIME impact; the OCI-default-cap concern (which the advisory itself marks as
conditional / not demonstrated) is tracked separately.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.24.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/fission/fission"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.25.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-50570"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-28T20:12:45Z",
"nvd_published_at": "2026-06-10T18:17:13Z",
"severity": "HIGH"
},
"details": "Fission v1.24.0 added PodSpec safety validation for tenant-facing Environment and Function CRDs (`ValidatePodSpecSafety` / `ValidateContainerSafety` admission webhook + `sanitizeContainerSecurityContext` executor merge layer), but the\ncapability check was implemented as a fixed **denylist of six Linux capabilities** (SYS_ADMIN, NET_ADMIN, SYS_PTRACE, SYS_MODULE, DAC_READ_SEARCH, DAC_OVERRIDE). The denylist omitted **CAP_SYS_TIME**, among others. As a result, a tenant\nwho could create a Function or Environment CRD could request `securityContext.capabilities.add: [\"SYS_TIME\"]`, pass Fission\u0027s admission validation and merge-layer sanitization, and run attacker-controlled code with `CAP_SYS_TIME` in the\nresulting function or runtime container.\n\nDemonstrated consequence: cross-tenant node integrity damage via `CAP_SYS_TIME`. The Linux real-time clock is not namespaced \u2014 time namespaces virtualize only `MONOTONIC` and `BOOTTIME`, never `REALTIME` \u2014 so a tenant container holding\n`CAP_SYS_TIME` could call `clock_settime(CLOCK_REALTIME)` and rewrite the shared node wall clock. That corrupts TLS / certificate validity windows, Kubernetes lease renewal, token expiry, scheduling, and time-series for every workload on\nthe node.\n\nThe denylist also omitted `SYS_RAWIO`, `BPF`, `SYS_RESOURCE`, and `MAC_ADMIN`. Those are documented as evidence that the denylist is structurally incomplete (their practical impact is kernel-, LSM-, or device-cgroup-dependent and is not\nexercised in this report).\n\nThe deeper structural problem: a denylist on `capabilities.add` cannot constrain capabilities the OCI runtime grants by default \u2014 `DAC_OVERRIDE` is in the OCI default cap set and reaches the container regardless of any `add` check,\npartially mooting the denylist for its own entries. A capability allowlist (with `drop:[\"ALL\"]` to remove the default set) is the only model that addresses both problems.\n\n### Affected\n\n- Project: `github.com/fission/fission`\n- Versions: `\u003c= 1.24.0`\n- Audited commits: v1.24.0 tag (`ce617120`) and current HEAD at audit time\n- Component: `pkg/apis/core/v1/podspec_safety.go` (`dangerousCapabilities`) and `pkg/executor/util/merge.go` (`dangerousMergeContainerCapabilities`)\n- Pre-condition: cluster does not enforce a restrictive Pod Security Admission (PSA) profile on the function-pod namespace. With PSA `restricted` in force the API server\u0027s PodSecurity admission rejects the pod at creation and this\nfinding does not apply. Fission added its own PodSpec validation precisely because it cannot assume PSA enforcement.\n\n\nFix section (paste into the Fix / Patches field)\n\nFixed in [v1.25.0](https://github.com/fission/fission/releases/tag/v1.25.0) by:\n\n- [PR #3465](https://github.com/fission/fission/pull/3465) (commit [`2569b42b`](https://github.com/fission/fission/commit/2569b42b)) \u2014 replace the denylist with a PSA-restricted allowlist (`NET_BIND_SERVICE` only) at both enforcement\nlayers:\n - `pkg/apis/core/v1/podspec_safety.go` \u2014 `ValidateContainerSafety` now rejects any `capabilities.add` entry not in `allowedCapabilities`. The container check is invoked from `ValidatePodSpecSafety` for every PodSpec container /\ninit-container and from `Environment.validateForAdmission` for the bare `Runtime.Container` / `Builder.Container`.\n - `pkg/executor/util/merge.go` \u2014 `sanitizeContainerSecurityContext` filters `capabilities.add` through the same allowlist at every merge site (poolmgr / newdeploy / container executor / builder).\n- The same PR adds 21 bounded CEL `XValidation` rules covering the cheap pod-level invariants (`hostNetwork` / `hostPID` / `hostIPC` / `serviceAccountName` / `serviceAccount` override) on `FunctionSpec`, `Runtime`, and `Builder`, plus\nthe bare-Container `SecurityContext` checks (`privileged != true`, `allowPrivilegeEscalation != true`, `capabilities.add \u2286 {NET_BIND_SERVICE}`) on `Runtime` and `Builder`. The API server now short-circuits those attack vectors per CRD\napply before the webhook is invoked. Per-container PodSpec iteration stays in the webhook because it exceeds the API server\u0027s CEL cost budget.\n- The same PR also adds two forward-compat regression guards in `pkg/apis/core/v1/podspec_safety_test.go`:\n - `TestAllTenantContainerSurfacesAreValidated` walks every CRD root type via reflection and fails if any reachable `*apiv1.PodSpec` or `*apiv1.Container` field is missing from the hand-maintained known-covered set.\n - `TestTenantContainerSurfaces_RejectSysAdmin` end-to-end exercises each covered surface and asserts `ValidateForAdmission` rejects a `SYS_ADMIN` injection at that exact path.\n\n### Not addressed in v1.25.0\n\nThe advisory\u0027s structural recommendation to force `capabilities.drop: [\"ALL\"]` at the merge layer is **not** part of this fix. Fission\u0027s own sidecar containers (`fission-fetcher`, builder) were authored against the OCI default capability\nset and need a per-container cap audit before `drop:[\"ALL\"]` can be applied uniformly. The allowlist on `capabilities.add` closes the demonstrated `CAP_SYS_TIME` impact; the OCI-default-cap concern (which the advisory itself marks as\nconditional / not demonstrated) is tracked separately.",
"id": "GHSA-qf5v-m7p4-95rp",
"modified": "2026-07-28T20:12:45Z",
"published": "2026-07-28T20:12:45Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fission/fission/security/advisories/GHSA-qf5v-m7p4-95rp"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50570"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/pull/3465"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/commit/2569b42bfadbcb7d78b55a00a60f77937e522699"
},
{
"type": "PACKAGE",
"url": "https://github.com/fission/fission"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/releases/tag/v1.25.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Fission: Incomplete capability denylist in Environment/Function PodSpec validation allows tenant-added CAP_SYS_TIME and cross-tenant node wall-clock corruption"
}
GHSA-QFQP-9J9F-7XQV
Vulnerability from github – Published: 2026-05-04 15:31 – Updated: 2026-05-04 15:31Incorrect Permission Assignment for Critical Resource vulnerability in ILM Informatique OpenConcerto allows Replace Binaries.
This issue affects OpenConcerto: 1.7.5.
{
"affected": [],
"aliases": [
"CVE-2026-6499"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-04T14:16:36Z",
"severity": "LOW"
},
"details": "Incorrect Permission Assignment for Critical Resource vulnerability in ILM Informatique OpenConcerto allows Replace Binaries.\n\nThis issue affects OpenConcerto: 1.7.5.",
"id": "GHSA-qfqp-9j9f-7xqv",
"modified": "2026-05-04T15:31:15Z",
"published": "2026-05-04T15:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6499"
},
{
"type": "WEB",
"url": "https://www.openconcerto.org/fr/version-1.7.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/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-QG2F-Q7G5-25Q6
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10Dell PowerScale OneFS 9.1.0.x contains an improper privilege management vulnerability. It may allow an authenticated user with ISI_PRIV_LOGIN_SSH and/or ISI_PRIV_LOGIN_CONSOLE to elevate privilege.
{
"affected": [],
"aliases": [
"CVE-2021-21567"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-10T19:15:00Z",
"severity": "HIGH"
},
"details": "Dell PowerScale OneFS 9.1.0.x contains an improper privilege management vulnerability. It may allow an authenticated user with ISI_PRIV_LOGIN_SSH and/or ISI_PRIV_LOGIN_CONSOLE to elevate privilege.",
"id": "GHSA-qg2f-q7g5-25q6",
"modified": "2022-05-24T19:10:32Z",
"published": "2022-05-24T19:10:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21567"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/000189495"
}
],
"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-QG6Q-7MWR-M5VQ
Vulnerability from github – Published: 2022-05-24 16:45 – Updated: 2024-04-04 00:41Improper directory permissions in the installer for Intel(R) PROSet/Wireless WiFi Software version 20.100 and earlier may allow an authenticated user to potentially enable escalation of privilege via local access.
{
"affected": [],
"aliases": [
"CVE-2018-3701"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-05-17T16:29:00Z",
"severity": "HIGH"
},
"details": "Improper directory permissions in the installer for Intel(R) PROSet/Wireless WiFi Software version 20.100 and earlier may allow an authenticated user to potentially enable escalation of privilege via local access.",
"id": "GHSA-qg6q-7mwr-m5vq",
"modified": "2024-04-04T00:41:36Z",
"published": "2022-05-24T16:45:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-3701"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K00245734"
},
{
"type": "WEB",
"url": "https://support.lenovo.com/us/en/product_security/LEN-27701"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00204.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/108387"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QGPJ-9W2H-PCV3
Vulnerability from github – Published: 2026-07-03 00:31 – Updated: 2026-08-10 21:31A local privilege escalation vulnerability in the WatchGuard Mobile VPN with SSL client for Windows allows a local attacker to escalate their privileges to NT AUTHORITY\SYSTEM on the machine where the client is installed.
This issue affects the Mobile VPN with SSL client for Windows up to and including 2026.2.
{
"affected": [],
"aliases": [
"CVE-2026-13079"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-03T00:16:50Z",
"severity": "HIGH"
},
"details": "A local privilege escalation vulnerability in the WatchGuard Mobile VPN with SSL client for Windows allows a local attacker to escalate their privileges to NT AUTHORITY\\SYSTEM on the machine where the client is installed.\n\nThis issue affects the Mobile VPN with SSL client for Windows up to and including 2026.2.",
"id": "GHSA-qgpj-9w2h-pcv3",
"modified": "2026-08-10T21:31:56Z",
"published": "2026-07-03T00:31:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13079"
},
{
"type": "WEB",
"url": "https://psirt.watchguard.com/CVE-2026-13079"
},
{
"type": "WEB",
"url": "https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2026-00027"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/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-QGV8-W8CV-37PW
Vulnerability from github – Published: 2023-12-12 03:31 – Updated: 2024-09-29 00:30SAP GUI for Windows and SAP GUI for Java - versions SAP_BASIS 755, SAP_BASIS 756, SAP_BASIS 757, SAP_BASIS 758, allow an unauthenticated attacker to access information which would otherwise be restricted and confidential. In addition, this vulnerability allows the unauthenticated attacker to create Layout configurations of the ABAP List Viewer and with this causing a mild impact on integrity and availability, e.g. also increasing the response times of the AS ABAP.
{
"affected": [],
"aliases": [
"CVE-2023-49580"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-12T02:15:07Z",
"severity": "HIGH"
},
"details": "SAP GUI for Windows\u00a0and\u00a0SAP GUI for Java - versions SAP_BASIS 755, SAP_BASIS 756, SAP_BASIS 757, SAP_BASIS 758, allow an unauthenticated attacker to access information which would otherwise be restricted and confidential. In addition, this vulnerability allows the unauthenticated attacker to create Layout configurations of the ABAP List Viewer and with this causing a mild impact on integrity and availability, e.g. also increasing the response times of the AS ABAP.\n\n",
"id": "GHSA-qgv8-w8cv-37pw",
"modified": "2024-09-29T00:30:57Z",
"published": "2023-12-12T03:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-49580"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3385711"
},
{
"type": "WEB",
"url": "https://www.sap.com/documents/2022/02/fa865ea4-167e-0010-bca6-c68f7e60039b.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-QGVH-G2MH-JWFC
Vulnerability from github – Published: 2023-07-06 19:24 – Updated: 2025-02-10 21:31No access control for the OTP key
on OTP entries
in Devolutions Remote Desktop Manager Windows 2022.3.33.0 and prior versions and Remote Desktop Manager Linux 2022.3.2.0 and prior versions allows non admin users to see OTP keys via the user interface.
{
"affected": [],
"aliases": [
"CVE-2023-1939"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-11T18:15:00Z",
"severity": "MODERATE"
},
"details": "No access control for the OTP key\u00a0\n\n\u00a0on OTP entries\n\n in Devolutions Remote Desktop Manager Windows 2022.3.33.0 and prior versions and Remote Desktop Manager Linux 2022.3.2.0 and prior versions allows non admin users to see OTP keys via the user interface.",
"id": "GHSA-qgvh-g2mh-jwfc",
"modified": "2025-02-10T21:31:25Z",
"published": "2023-07-06T19:24:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1939"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2023-0009"
}
],
"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-QGX5-5H35-JW4R
Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31Foxit PDF Reader Update Service Incorrect Permission Assignment Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PDF Reader. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the handling of the configuration files used by the Foxit Reader Update Service. The issue results from incorrect permissions set on a resource used by the service. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Was ZDI-CAN-23933.
{
"affected": [],
"aliases": [
"CVE-2024-9244"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-22T22:15:20Z",
"severity": "HIGH"
},
"details": "Foxit PDF Reader Update Service Incorrect Permission Assignment Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PDF Reader. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the handling of the configuration files used by the Foxit Reader Update Service. The issue results from incorrect permissions set on a resource used by the service. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Was ZDI-CAN-23933.",
"id": "GHSA-qgx5-5h35-jw4r",
"modified": "2024-11-23T03:31:59Z",
"published": "2024-11-23T03:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9244"
},
{
"type": "WEB",
"url": "https://www.foxit.com/support/security-bulletins.html"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1298"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-QGXW-XQ35-5QCQ
Vulnerability from github – Published: 2022-05-24 17:14 – Updated: 2022-05-24 17:14In Rockwell Automation RSLinx Classic versions 4.1.00 and prior, an authenticated local attacker could modify a registry key, which could lead to the execution of malicious code using system privileges when opening RSLinx Classic.
{
"affected": [],
"aliases": [
"CVE-2020-10642"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-04-13T19:15:00Z",
"severity": "HIGH"
},
"details": "In Rockwell Automation RSLinx Classic versions 4.1.00 and prior, an authenticated local attacker could modify a registry key, which could lead to the execution of malicious code using system privileges when opening RSLinx Classic.",
"id": "GHSA-qgxw-xq35-5qcq",
"modified": "2022-05-24T17:14:03Z",
"published": "2022-05-24T17:14:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-10642"
},
{
"type": "WEB",
"url": "https://www.us-cert.gov/ics/advisories/icsa-20-100-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.