CWE-269
DiscouragedImproper Privilege Management
Abstraction: Class · Status: Draft
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
5584 vulnerabilities reference this CWE, most recent first.
GHSA-85CP-839G-XMMQ
Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2023-12-28 21:30Azure CycleCloud Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-33762.
{
"affected": [],
"aliases": [
"CVE-2021-36943"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-12T18:15:00Z",
"severity": "HIGH"
},
"details": "Azure CycleCloud Elevation of Privilege Vulnerability This CVE ID is unique from CVE-2021-33762.",
"id": "GHSA-85cp-839g-xmmq",
"modified": "2023-12-28T21:30:29Z",
"published": "2022-05-24T19:10:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36943"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2021-36943"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-85G2-PMRX-R49Q
Vulnerability from github – Published: 2026-05-21 20:16 – Updated: 2026-07-21 13:54Summary
Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests.
Affected component
pkg/executor/executortype/poolmgr/gp_deployment.go:154-156— pool-manager runtime podServiceAccountName.pkg/executor/executortype/newdeploy/newdeploy.go:225-227— new-deploy runtime podServiceAccountName.pkg/utils/serviceaccount.go:51-64—fission-fetcherRBAC: namespace-widegetonsecrets/configmaps.
Impact
A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:
- Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
- Read every configmap in that namespace.
- Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.
This violates the principle that Function.spec.secrets is the authoritative declaration of which secrets a function can read.
Root cause
The fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting ServiceAccountName: fission-fetcher on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.
Fix
Released in v1.23.0:
- PR #3366 (commit
fe1842ef): - The user function container now sets
AutomountServiceAccountToken: falseat the container level (via projected-volume token suppression), so the user container no longer sees the pod's SA token even though the fetcher sidecar still does. - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.
- For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via
Function.spec.podspecwith the minimum necessary RBAC (documented separately).
Mitigation (until upgrade)
- Restrict who can create / update
FunctionandPackageCRDs in your cluster — treat the ability to ship function code as equivalent to namespace-wide secret read. - Reduce the
fission-fetcherClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings). - Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.22.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/fission/fission"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.23.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-46617"
],
"database_specific": {
"cwe_ids": [
"CWE-250",
"CWE-269",
"CWE-538"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-21T20:16:12Z",
"nvd_published_at": "2026-06-10T18:17:05Z",
"severity": "HIGH"
},
"details": "### Summary\n\nFission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod\u0027s automounted token was reachable from inside the user\u0027s function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function\u0027s namespace \u2014 far beyond the `Function.spec.secrets` allowlist that the function specification suggests.\n\n### Affected component\n\n- `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` \u2014 pool-manager runtime pod `ServiceAccountName`.\n- `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` \u2014 new-deploy runtime pod `ServiceAccountName`.\n- `pkg/utils/serviceaccount.go:51-64` \u2014 `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`.\n\n### Impact\n\nA user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:\n\n1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).\n2. Read every configmap in that namespace.\n3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.\n\nThis violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets a function can read.\n\n### Root cause\n\nThe fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting `ServiceAccountName: fission-fetcher` on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.\n\n### Fix\n\nReleased in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0):\n\n- **PR #3366** (commit `fe1842ef`):\n - The user function container now sets `AutomountServiceAccountToken: false` at the container level (via projected-volume token suppression), so the user container no longer sees the pod\u0027s SA token even though the fetcher sidecar still does.\n - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.\n - For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via `Function.spec.podspec` with the minimum necessary RBAC (documented separately).\n\n### Mitigation (until upgrade)\n\n1. Restrict who can create / update `Function` and `Package` CRDs in your cluster \u2014 treat the ability to ship function code as equivalent to namespace-wide secret read.\n2. Reduce the `fission-fetcher` ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings).\n3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).",
"id": "GHSA-85g2-pmrx-r49q",
"modified": "2026-07-21T13:54:09Z",
"published": "2026-05-21T20:16:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/fission/fission/security/advisories/GHSA-85g2-pmrx-r49q"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46617"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/pull/3366"
},
{
"type": "PACKAGE",
"url": "https://github.com/fission/fission"
},
{
"type": "WEB",
"url": "https://github.com/fission/fission/releases/tag/v1.23.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Fission runtime pods automount the fission-fetcher service-account token into the user function container, granting function code namespace-wide secret / configmap read"
}
GHSA-85JC-QVVJ-Q8JW
Vulnerability from github – Published: 2022-05-24 17:23 – Updated: 2022-05-24 17:23An elevation of privilege vulnerability exists in the way that the Windows Network Connections Service handles objects in memory, aka 'Windows Network Connections Service Elevation of Privilege Vulnerability'. This CVE ID is unique from CVE-2020-1390, CVE-2020-1427, CVE-2020-1428, CVE-2020-1438.
{
"affected": [],
"aliases": [
"CVE-2020-1373"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-07-14T23:15:00Z",
"severity": "MODERATE"
},
"details": "An elevation of privilege vulnerability exists in the way that the Windows Network Connections Service handles objects in memory, aka \u0027Windows Network Connections Service Elevation of Privilege Vulnerability\u0027. This CVE ID is unique from CVE-2020-1390, CVE-2020-1427, CVE-2020-1428, CVE-2020-1438.",
"id": "GHSA-85jc-qvvj-q8jw",
"modified": "2022-05-24T17:23:01Z",
"published": "2022-05-24T17:23:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1373"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1373"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-85MQ-QV5G-3VF2
Vulnerability from github – Published: 2022-05-24 19:09 – Updated: 2022-05-24 19:09An issue was discovered in Comelit "App lejos de casa (web)" 2.8.0. It allows privilege escalation via modified domus and logged fields, related to js/bridge.min.js and login.json. For example, an attacker can achieve high privileges (installer or administrator) for the graphical interface via a 1C000000000S value for domus, in conjunction with a zero value for logged.
{
"affected": [],
"aliases": [
"CVE-2019-14453"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-08-03T18:15:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Comelit \"App lejos de casa (web)\" 2.8.0. It allows privilege escalation via modified domus and logged fields, related to js/bridge.min.js and login.json. For example, an attacker can achieve high privileges (installer or administrator) for the graphical interface via a 1C000000000S value for domus, in conjunction with a zero value for logged.",
"id": "GHSA-85mq-qv5g-3vf2",
"modified": "2022-05-24T19:09:49Z",
"published": "2022-05-24T19:09:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-14453"
},
{
"type": "WEB",
"url": "https://www.blogx86.net/2021/07/26/cve-2019-14453"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-864V-6QJ7-62QJ
Vulnerability from github – Published: 2023-01-24 20:47 – Updated: 2025-01-16 14:07Advisory title: Issue with whitespace in JWT roles
Affected versions:
OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1
Patched versions:
OpenSearch 1.3.8 and 2.5.0
Impact:
OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of.
This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names.
Patches:
OpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue.
For more information:
If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.plugin:opensearch-security"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.opensearch.plugin:opensearch-security"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-23612"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2023-01-24T20:47:19Z",
"nvd_published_at": "2023-01-26T21:18:00Z",
"severity": "MODERATE"
},
"details": "### Advisory title: Issue with whitespace in JWT roles\n\n### Affected versions:\nOpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1\n\n### Patched versions:\nOpenSearch 1.3.8 and 2.5.0\n\n### Impact:\nOpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of.\n\nThis issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names.\n\n### Patches:\nOpenSearch versions 1.3.8 and 2.5.0 contain a fix for this issue.\n\n### For more information:\nIf you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.",
"id": "GHSA-864v-6qj7-62qj",
"modified": "2025-01-16T14:07:22Z",
"published": "2023-01-24T20:47:19Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opensearch-project/security/security/advisories/GHSA-864v-6qj7-62qj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23612"
},
{
"type": "WEB",
"url": "https://github.com/opensearch-project/OpenSearch/releases/tag/2.5.0"
},
{
"type": "PACKAGE",
"url": "https://github.com/opensearch-project/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Issue with whitespace in JWT roles in OpenSearch"
}
GHSA-8674-26JC-WH98
Vulnerability from github – Published: 2022-02-09 22:56 – Updated: 2022-02-09 22:56A flaw was found in infinispan 10 REST API, where authorization permissions are not checked while performing some server management operations. When authz is enabled, any user with authentication can perform operations like shutting down the server without the ADMIN role.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 11.0.5.Final"
},
"package": {
"ecosystem": "Maven",
"name": "org.infinispan:infinispan-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "11.0.6.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-25711"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2021-04-09T22:40:14Z",
"nvd_published_at": "2020-12-03T17:15:00Z",
"severity": "MODERATE"
},
"details": "A flaw was found in infinispan 10 REST API, where authorization permissions are not checked while performing some server management operations. When authz is enabled, any user with authentication can perform operations like shutting down the server without the ADMIN role.",
"id": "GHSA-8674-26jc-wh98",
"modified": "2022-02-09T22:56:32Z",
"published": "2022-02-09T22:56:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-25711"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=1897618"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Access Control in infinispan-server-runtime"
}
GHSA-86G9-P235-R7FF
Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36A Permissions, Privileges, and Access Controls issue was discovered in ABB VSN300 WiFi Logger Card versions 1.8.15 and prior, and VSN300 WiFi Logger Card for React versions 2.1.3 and prior. The web application does not properly restrict privileges of the Guest account. A malicious user may be able to gain access to configuration information that should be restricted.
{
"affected": [],
"aliases": [
"CVE-2017-7916"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-08-07T08:29:00Z",
"severity": "MODERATE"
},
"details": "A Permissions, Privileges, and Access Controls issue was discovered in ABB VSN300 WiFi Logger Card versions 1.8.15 and prior, and VSN300 WiFi Logger Card for React versions 2.1.3 and prior. The web application does not properly restrict privileges of the Guest account. A malicious user may be able to gain access to configuration information that should be restricted.",
"id": "GHSA-86g9-p235-r7ff",
"modified": "2022-05-13T01:36:14Z",
"published": "2022-05-13T01:36:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-7916"
},
{
"type": "WEB",
"url": "https://ics-cert.us-cert.gov/advisories/ICSA-17-192-03"
},
{
"type": "WEB",
"url": "http://search.abb.com/library/Download.aspx?DocumentID=9AKK107045A1977\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/99558"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-86PJ-HRWX-9VHG
Vulnerability from github – Published: 2023-08-14 21:30 – Updated: 2024-04-04 06:56In startActivityInner of ActivityStarter.java, there is a possible way to launch an activity into PiP mode from the background due to BAL bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2023-21269"
],
"database_specific": {
"cwe_ids": [
"CWE-266",
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-14T21:15:12Z",
"severity": "HIGH"
},
"details": "In startActivityInner of ActivityStarter.java, there is a possible way to launch an activity into PiP mode from the background due to BAL bypass. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.\n\n",
"id": "GHSA-86pj-hrwx-9vhg",
"modified": "2024-04-04T06:56:08Z",
"published": "2023-08-14T21:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-21269"
},
{
"type": "WEB",
"url": "https://android.googlesource.com/platform/frameworks/base/+/70ec64dc5a2a816d6aa324190a726a85fd749b30"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2023-08-01"
}
],
"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-86QF-5646-CHG9
Vulnerability from github – Published: 2022-05-24 17:25 – Updated: 2022-05-24 17:25In SpecializeCommon of com_android_internal_os_Zygote.cpp, there is a permissions bypass due to an incomplete cleanup. This could lead to local escalation of privilege in isolated processes with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-156741968
{
"affected": [],
"aliases": [
"CVE-2020-0257"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-08-11T20:15:00Z",
"severity": "HIGH"
},
"details": "In SpecializeCommon of com_android_internal_os_Zygote.cpp, there is a permissions bypass due to an incomplete cleanup. This could lead to local escalation of privilege in isolated processes with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10Android ID: A-156741968",
"id": "GHSA-86qf-5646-chg9",
"modified": "2022-05-24T17:25:16Z",
"published": "2022-05-24T17:25:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-0257"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2020-08-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-86QM-VVW6-R9XJ
Vulnerability from github – Published: 2022-05-24 17:38 – Updated: 2022-07-13 00:01Mubu 2.2.1 allows local users to gain privileges to execute commands, aka CNVD-2020-68878.
{
"affected": [],
"aliases": [
"CVE-2021-3134"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-12T20:15:00Z",
"severity": "HIGH"
},
"details": "Mubu 2.2.1 allows local users to gain privileges to execute commands, aka CNVD-2020-68878.",
"id": "GHSA-86qm-vvw6-r9xj",
"modified": "2022-07-13T00:01:24Z",
"published": "2022-05-24T17:38:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-3134"
},
{
"type": "WEB",
"url": "https://www.cnvd.org.cn/flaw/show/2638444"
},
{
"type": "WEB",
"url": "http://mubu.com/doc/d5501245199"
}
],
"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"
}
]
}
Mitigation MIT-1
Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
Mitigation MIT-48
Strategy: Separation of Privilege
Follow the principle of least privilege when assigning access rights to entities in a software system.
Mitigation MIT-49
Strategy: Separation of Privilege
Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
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-233: Privilege Escalation
An adversary exploits a weakness enabling them to elevate their privilege and perform an action that they are not supposed to be authorized to perform.
CAPEC-58: Restful Privilege Elevation
An adversary identifies a Rest HTTP (Get, Put, Delete) style permission method allowing them to perform various malicious actions upon server data due to lack of access control mechanisms implemented within the application service accepting HTTP messages.