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.
5632 vulnerabilities reference this CWE, most recent first.
GHSA-5M4M-582Q-GP6P
Vulnerability from github – Published: 2022-12-13 15:30 – Updated: 2022-12-15 21:30EXEMSI MSI Wrapper Versions prior to 10.0.50 and at least since version 6.0.91 will introduce a local privilege escalation vulnerability in installers it creates.
{
"affected": [],
"aliases": [
"CVE-2021-32415"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T15:15:00Z",
"severity": "HIGH"
},
"details": "EXEMSI MSI Wrapper Versions prior to 10.0.50 and at least since version 6.0.91 will introduce a local privilege escalation vulnerability in installers it creates.",
"id": "GHSA-5m4m-582q-gp6p",
"modified": "2022-12-15T21:30:31Z",
"published": "2022-12-13T15:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-32415"
},
{
"type": "WEB",
"url": "https://improsec.com/tech-blog/privilege-escalation-vulnerability-in-ninjarmm"
},
{
"type": "WEB",
"url": "http://exemsi.com"
},
{
"type": "WEB",
"url": "http://msi.com"
}
],
"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-5M4X-QF9V-Q755
Vulnerability from github – Published: 2025-08-20 15:31 – Updated: 2025-08-20 15:31CWE-269: Improper Privilege Management vulnerability exists that could cause privilege escalation and arbitrary code execution when a privileged engineer user with console access modifies a configuration file used by a root-level daemon to execute custom scripts.
{
"affected": [],
"aliases": [
"CVE-2025-8453"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-20T13:15:29Z",
"severity": "HIGH"
},
"details": "CWE-269: Improper Privilege Management vulnerability exists that could cause privilege escalation and\narbitrary code execution when a privileged engineer user with console access modifies a configuration file\nused by a root-level daemon to execute custom scripts.",
"id": "GHSA-5m4x-qf9v-q755",
"modified": "2025-08-20T15:31:41Z",
"published": "2025-08-20T15:31:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8453"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2025-224-01\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2025-224-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/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-5M5G-R44M-96R4
Vulnerability from github – Published: 2024-07-17 00:32 – Updated: 2024-07-17 00:32An improper privilege management vulnerability allowed users to migrate private repositories without having appropriate scopes defined on the related Personal Access Token. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.14 and was fixed in version 3.13.1, 3.12.6, 3.11.12, 3.10.14, and 3.9.17.
{
"affected": [],
"aliases": [
"CVE-2024-5566"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-16T22:15:04Z",
"severity": "MODERATE"
},
"details": "An improper privilege management vulnerability allowed users to migrate private repositories without having appropriate scopes defined on the related Personal Access Token. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.14 and was fixed in version 3.13.1, 3.12.6, 3.11.12, 3.10.14, and 3.9.17.",
"id": "GHSA-5m5g-r44m-96r4",
"modified": "2024-07-17T00:32:53Z",
"published": "2024-07-17T00:32:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5566"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.10/admin/release-notes#3.10.14"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.11/admin/release-notes#3.11.10"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.12/admin/release-notes#3.12.6"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.13/admin/release-notes#3.13.1"
},
{
"type": "WEB",
"url": "https://docs.github.com/en/enterprise-server@3.9/admin/release-notes#3.9.17"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5M7G-PJ8W-7593
Vulnerability from github – Published: 2022-11-09 19:17 – Updated: 2024-09-06 21:33Impact
Some current default configurations for Vela allow exploitation and container breakouts.
Default Privileged Images
Running Vela plugins as privileged Docker containers allows a malicious user to easily break out of the container and gain access to the worker host operating system. On a fresh install of Vela without any additional configuration, the target/vela-docker plugin will run as a privileged container, even if the Vela administrators did not intend to allow for any privileged plugins, and even if the vela.yml configuration file does not use the privileged = True flag.
Privileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running.
Default Allowed Repositories
On a fresh install of Vela, anyone with a GitHub account (or other enabled source control management solution) is allowed to enable a repository within Vela and run builds. This means that, if a Vela instance is accessible to the public, a third party could add their own malicious repos to the Vela instance and run arbitrary code.
An example of a publicly accessible Vela instance would be one not protected behind a VPN. Whether Vela is publicly accessible depends on how Vela is set up, NOT how it is connected to GitHub.
Default Enabled Events allows Pull Requests
By default, Vela currently enables pull request events when a repository is Vela-enabled. Unless this default was changed when enabling each repository, anyone who can issue a pull request against a repository can trigger a Vela job.
This not only permits a third party to run arbitrary code in a Vela environment, but also poses an additional risk when secrets within Vela are configured to be available in pull requests, permitting anyone with access to create pull requests to access these secrets.
Patches
Upgrade to 0.16.0 or later. After upgrading, Vela administrators will need to explicitly change the default settings to configure Vela as desired.
Some of the fixes will interrupt existing workflows and will require Vela administrators to modify default settings (see release notes for more information). However, not applying the patch (or workarounds) will continue existing risk exposure.
Workarounds
Default Privileged Images
Instead of upgrading, the Vela administrators can adjust the worker's VELA_RUNTIME_PRIVILEGED_IMAGES setting to be explicitly empty:
VELA_RUNTIME_PRIVILEGED_IMAGES=""
By assigning VELA_RUNTIME_PRIVILEGED_IMAGES to an empty value it disallows any images from running as privileged containers in Vela.
Default Allowed Repositories
Instead of upgrading, the Vela administrators can leverage the VELA_REPO_ALLOWLIST setting on the server component to restrict access to a list of repositories that are allowed to be enabled.
By changing it from the default empty list (currently interpreted by Vela as "all repositories") to a list explicitly allowing specific repositories, Vela administrators can control what repositories are allowed to be enabled in Vela.
Vela's current default list of approved repositories that can be added to a Vela instance is an empty list. However this is currently interpreted as allowing all repositories.
In the updated version, a null value (the empty list) will be interpreted as permitting no repositories to be added to a Vela instance.
Default Enabled Events allows Pull Requests
Audit enabled repositories and disable pull_requests if they are not needed.
Instead of upgrading, the pull request trigger can be disabled on a per-repository basis.
Additional protection can be provided by preventing unauthorized users from submitting pull requests in GitHub (or other source control management solution).
Residual Risk
Default Privileged Images
After applying the update, any repos that Vela administrators manually define as "trusted repos" will be able to run the manually-specified images that are allowed to run as privileged. Those repos will continue to be vulnerable to breakout, but applying the update will help protect against the risk of trivial breakout arising from an image running as a privileged container.
The recommendation is to utilize plugins that do not require privileged capabilities.
For example, utilize target/vela-kaniko instead of target/vela-docker as the Kaniko plugin does not require privileged access.
Default Allowed Repositories
Applying this update (or workaround) will protect against the risk of Vela interpreting the default empty list of approved repositories as "all repositories" rather than "no repositories" (the current default).
Default Enabled Events allows Pull Requests
Since this change only impacts newly enabled repositories, the update will not address the risk to existing enabled repositories resulting from Vela enabling pull request events when a repository is Vela-enabled.
Additionally, this change only impacts defaults; users can still configure their repositories to allow pull requests as triggering events.
In order to monitor risk going forward, refer to the Workaround section with the heading Default Enabled Events allows Pull Requests.
For more information
If you have any questions or comments about this advisory: * Email us at vela@target.com
Affected products: go-vela/worker, go-vela/server, go-vela/ui, go-vela/documentation
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-vela/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/go-vela/worker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-39395"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": true,
"github_reviewed_at": "2022-11-09T19:17:21Z",
"nvd_published_at": "2022-11-10T18:15:00Z",
"severity": "CRITICAL"
},
"details": "### Impact\nSome current default configurations for Vela allow exploitation and container breakouts.\n\n#### Default Privileged Images\n\nRunning Vela plugins as privileged Docker containers allows a malicious user to easily break out of the container and gain access to the worker host operating system. On a fresh install of Vela without any additional configuration, the `target/vela-docker` plugin will run as a privileged container, even if the Vela administrators did not intend to allow for any privileged plugins, and even if the `vela.yml` configuration file does not use the `privileged = True` flag.\n\nPrivileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running.\n\n#### Default Allowed Repositories\n\nOn a fresh install of Vela, anyone with a GitHub account (or other enabled source control management solution) is allowed to enable a repository within Vela and run builds. This means that, if a Vela instance is accessible to the public, a third party could add their own malicious repos to the Vela instance and run arbitrary code.\n\nAn example of a publicly accessible Vela instance would be one not protected behind a VPN. Whether Vela is publicly accessible depends on how Vela is set up, NOT how it is connected to GitHub.\n\n#### Default Enabled Events allows Pull Requests\n\nBy default, Vela currently enables pull request events when a repository is Vela-enabled. Unless this default was changed when enabling each repository, anyone who can issue a pull request against a repository can trigger a Vela job.\n\nThis not only permits a third party to run arbitrary code in a Vela environment, but also poses an additional risk when secrets within Vela are configured to be available in pull requests, permitting anyone with access to create pull requests to access these secrets.\n\n### Patches\n\nUpgrade to 0.16.0 or later. After upgrading, Vela administrators will need to explicitly change the default settings to configure Vela as desired.\n\nSome of the fixes will interrupt existing workflows and will require Vela administrators to modify default settings (see release notes for more information). However, not applying the patch (or workarounds) will continue existing risk exposure.\n\n### Workarounds\n\n#### Default Privileged Images\n\nInstead of upgrading, the Vela administrators can adjust the worker\u0027s `VELA_RUNTIME_PRIVILEGED_IMAGES` setting to be explicitly empty:\n\n`VELA_RUNTIME_PRIVILEGED_IMAGES=\"\"`\n\nBy assigning `VELA_RUNTIME_PRIVILEGED_IMAGES` to an empty value it disallows any images from running as privileged containers in Vela.\n\n#### Default Allowed Repositories\n\nInstead of upgrading, the Vela administrators can leverage the `VELA_REPO_ALLOWLIST` setting on the server component to restrict access to a list of repositories that are allowed to be enabled.\n\nBy changing it from the default empty list (currently interpreted by Vela as \"all repositories\") to a list explicitly allowing specific repositories, Vela administrators can control what repositories are allowed to be enabled in Vela.\n\nVela\u0027s current default list of approved repositories that can be added to a Vela instance is an empty list. However this is currently interpreted as allowing all repositories.\n\nIn the updated version, a null value (the empty list) will be interpreted as permitting no repositories to be added to a Vela instance.\n\n#### Default Enabled Events allows Pull Requests\n\nAudit enabled repositories and disable `pull_requests` if they are not needed.\n\nInstead of upgrading, the pull request trigger can be disabled on a per-repository basis.\n\nAdditional protection can be provided by preventing unauthorized users from submitting pull requests in GitHub (or other source control management solution).\n\n### Residual Risk\n\n#### Default Privileged Images\n\nAfter applying the update, any repos that Vela administrators manually define as \"trusted repos\" will be able to run the manually-specified images that are allowed to run as privileged. Those repos will continue to be vulnerable to breakout, but applying the update will help protect against the risk of trivial breakout arising from an image running as a privileged container.\n\nThe recommendation is to utilize plugins that do not require privileged capabilities.\n\nFor example, utilize `target/vela-kaniko` instead of `target/vela-docker` as the Kaniko plugin does not require privileged access.\n\n#### Default Allowed Repositories\n\nApplying this update (or workaround) will protect against the risk of Vela interpreting the default empty list of approved repositories as \"all repositories\" rather than \"no repositories\" (the current default).\n\n#### Default Enabled Events allows Pull Requests\n\nSince this change only impacts newly enabled repositories, the update will not address the risk to existing enabled repositories resulting from Vela enabling pull request events when a repository is Vela-enabled.\n\nAdditionally, this change only impacts defaults; users can still configure their repositories to allow pull requests as triggering events.\n\nIn order to monitor risk going forward, refer to the `Workaround` section with the heading `Default Enabled Events allows Pull Requests`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [vela@target.com](mailto:vela@target.com)\n\nAffected products: `go-vela/worker`, `go-vela/server`, `go-vela/ui`, `go-vela/documentation`",
"id": "GHSA-5m7g-pj8w-7593",
"modified": "2024-09-06T21:33:41Z",
"published": "2022-11-09T19:17:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/go-vela/server/security/advisories/GHSA-5m7g-pj8w-7593"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/ui/security/advisories/GHSA-xf39-98m2-889v"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/worker/security/advisories/GHSA-2w78-ffv6-p46w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-39395"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/server/commit/05558ee99d70f7d6f83bed7c8f78ac0b35fa26f4"
},
{
"type": "WEB",
"url": "https://docs.docker.com/engine/security/#docker-daemon-attack-surface"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/server/releases/tag/v0.16.0"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/ui/releases/tag/v0.17.0"
},
{
"type": "WEB",
"url": "https://github.com/go-vela/worker/releases/tag/v0.16.0"
},
{
"type": "WEB",
"url": "https://go-vela.github.io/docs/installation/server/reference/#vela_repo_allowlist"
},
{
"type": "WEB",
"url": "https://go-vela.github.io/docs/installation/worker/reference/#vela_runtime_privileged_images"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2022-1100"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Vela Insecure Defaults"
}
GHSA-5MCP-H82R-F9V7
Vulnerability from github – Published: 2023-04-27 03:30 – Updated: 2024-04-04 03:42An issue was discovered in the Hyundai Gen5W_L in-vehicle infotainment system AE_E_PE_EUR.S5W_L001.001.211214. The AppUpgrade binary file, which is used during the firmware installation process, can be modified by an attacker to bypass the version check in order to install any firmware version (e.g., newer, older, or customized). This indirectly allows an attacker to install custom firmware in the IVI system.
{
"affected": [],
"aliases": [
"CVE-2023-26245"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-863"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-04-27T01:15:08Z",
"severity": "HIGH"
},
"details": "An issue was discovered in the Hyundai Gen5W_L in-vehicle infotainment system AE_E_PE_EUR.S5W_L001.001.211214. The AppUpgrade binary file, which is used during the firmware installation process, can be modified by an attacker to bypass the version check in order to install any firmware version (e.g., newer, older, or customized). This indirectly allows an attacker to install custom firmware in the IVI system.",
"id": "GHSA-5mcp-h82r-f9v7",
"modified": "2024-04-04T03:42:32Z",
"published": "2023-04-27T03:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26245"
},
{
"type": "WEB",
"url": "https://sowhat.iit.cnr.it"
},
{
"type": "WEB",
"url": "https://sowhat.iit.cnr.it:8443/can-work/chimaera"
},
{
"type": "WEB",
"url": "https://sowhat.iit.cnr.it:8443/can-work/chimaera/-/blob/main/Report/IIT-01-2023.pdf"
}
],
"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-5MFF-CXQ5-82JV
Vulnerability from github – Published: 2026-04-21 15:32 – Updated: 2026-04-22 00:31Privilege escalation in the Networking component. This vulnerability was fixed in Firefox 150 and Firefox ESR 140.10.
{
"affected": [],
"aliases": [
"CVE-2026-6761"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-21T13:16:22Z",
"severity": "MODERATE"
},
"details": "Privilege escalation in the Networking component. This vulnerability was fixed in Firefox 150 and Firefox ESR 140.10.",
"id": "GHSA-5mff-cxq5-82jv",
"modified": "2026-04-22T00:31:37Z",
"published": "2026-04-21T15:32:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-6761"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2017857"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-30"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-32"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-33"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-34"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-5MQ7-RVWH-8PM7
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-07-13 00:01There is a local privilege escalation vulnerability in some Huawei products. A local, authenticated attacker could craft specific commands to exploit this vulnerability. Successful exploitation may cause the attacker to obtain a higher privilege. Affected product versions include: ManageOne versions 6.5.0,6.5.0.SPC100.B210,6.5.1.1.B010,6.5.1.1.B020,6.5.1.1.B030,6.5.1.1.B040,6.5.1.SPC100.B050,6.5.1.SPC101.B010,6.5.1.SPC101.B040,6.5.1.SPC200,6.5.1.SPC200.B010,6.5.1.SPC200.B030,6.5.1.SPC200.B040,6.5.1.SPC200.B050,6.5.1.SPC200.B060,6.5.1.SPC200.B070,6.5.1RC1.B060,6.5.1RC2.B020,6.5.1RC2.B030,6.5.1RC2.B040,6.5.1RC2.B050,6.5.1RC2.B060,6.5.1RC2.B070,6.5.1RC2.B080,6.5.1RC2.B090,6.5.RC2.B050,8.0.0,8.0.0-LCND81,8.0.0.SPC100,8.0.1,8.0.RC2,8.0.RC3,8.0.RC3.B041,8.0.RC3.SPC100; NFV_FusionSphere versions 6.5.1.SPC23,8.0.0.SPC12; SMC2.0 versions V600R019C00,V600R019C10; iMaster MAE-M versions MAE-TOOL(FusionSphereBasicTemplate_Euler_X86)V100R020C10SPC220.
{
"affected": [],
"aliases": [
"CVE-2021-22299"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-06T02:15:00Z",
"severity": "HIGH"
},
"details": "There is a local privilege escalation vulnerability in some Huawei products. A local, authenticated attacker could craft specific commands to exploit this vulnerability. Successful exploitation may cause the attacker to obtain a higher privilege. Affected product versions include: ManageOne versions 6.5.0,6.5.0.SPC100.B210,6.5.1.1.B010,6.5.1.1.B020,6.5.1.1.B030,6.5.1.1.B040,6.5.1.SPC100.B050,6.5.1.SPC101.B010,6.5.1.SPC101.B040,6.5.1.SPC200,6.5.1.SPC200.B010,6.5.1.SPC200.B030,6.5.1.SPC200.B040,6.5.1.SPC200.B050,6.5.1.SPC200.B060,6.5.1.SPC200.B070,6.5.1RC1.B060,6.5.1RC2.B020,6.5.1RC2.B030,6.5.1RC2.B040,6.5.1RC2.B050,6.5.1RC2.B060,6.5.1RC2.B070,6.5.1RC2.B080,6.5.1RC2.B090,6.5.RC2.B050,8.0.0,8.0.0-LCND81,8.0.0.SPC100,8.0.1,8.0.RC2,8.0.RC3,8.0.RC3.B041,8.0.RC3.SPC100; NFV_FusionSphere versions 6.5.1.SPC23,8.0.0.SPC12; SMC2.0 versions V600R019C00,V600R019C10; iMaster MAE-M versions MAE-TOOL(FusionSphereBasicTemplate_Euler_X86)V100R020C10SPC220.",
"id": "GHSA-5mq7-rvwh-8pm7",
"modified": "2022-07-13T00:01:09Z",
"published": "2022-05-24T17:41:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22299"
},
{
"type": "WEB",
"url": "https://www.huawei.com/en/psirt/security-advisories/huawei-sa-20210120-02-privilege-en"
}
],
"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-5MQV-M2P9-QPRH
Vulnerability from github – Published: 2022-05-24 17:04 – Updated: 2024-04-04 02:44On BIG-IP versions 15.0.0-15.1.0, 14.0.0-14.1.2.3, 13.1.0-13.1.3.2, 12.1.0-12.1.5, and 11.5.2-11.6.5.1, BIG-IQ versions 7.0.0, 6.0.0-6.1.0, and 5.0.0-5.4.0, iWorkflow version 2.3.0, and Enterprise Manager version 3.1.1, authenticated users granted TMOS Shell (tmsh) privileges are able access objects on the file system which would normally be disallowed by tmsh restrictions. This allows for authenticated, low privileged attackers to access objects on the file system which would not normally be allowed.
{
"affected": [],
"aliases": [
"CVE-2019-19151"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-12-23T19:15:00Z",
"severity": "MODERATE"
},
"details": "On BIG-IP versions 15.0.0-15.1.0, 14.0.0-14.1.2.3, 13.1.0-13.1.3.2, 12.1.0-12.1.5, and 11.5.2-11.6.5.1, BIG-IQ versions 7.0.0, 6.0.0-6.1.0, and 5.0.0-5.4.0, iWorkflow version 2.3.0, and Enterprise Manager version 3.1.1, authenticated users granted TMOS Shell (tmsh) privileges are able access objects on the file system which would normally be disallowed by tmsh restrictions. This allows for authenticated, low privileged attackers to access objects on the file system which would not normally be allowed.",
"id": "GHSA-5mqv-m2p9-qprh",
"modified": "2024-04-04T02:44:55Z",
"published": "2022-05-24T17:04:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-19151"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K21711352"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-5MV6-488R-V66H
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 Location Awareness Service handles objects in memory, aka 'Windows Network Location Awareness Service Elevation of Privilege Vulnerability'.
{
"affected": [],
"aliases": [
"CVE-2020-1437"
],
"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 Location Awareness Service handles objects in memory, aka \u0027Windows Network Location Awareness Service Elevation of Privilege Vulnerability\u0027.",
"id": "GHSA-5mv6-488r-v66h",
"modified": "2022-05-24T17:23:09Z",
"published": "2022-05-24T17:23:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1437"
},
{
"type": "WEB",
"url": "https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1437"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-5MVP-RFQX-XFGV
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48In all Qualcomm products with Android releases from CAF using the Linux kernel, user-level permissions can be used to gain access to kernel memory, specifically the ION cache maintenance code is writing to a user supplied address.
{
"affected": [],
"aliases": [
"CVE-2017-9724"
],
"database_specific": {
"cwe_ids": [
"CWE-269"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-21T15:29:00Z",
"severity": "HIGH"
},
"details": "In all Qualcomm products with Android releases from CAF using the Linux kernel, user-level permissions can be used to gain access to kernel memory, specifically the ION cache maintenance code is writing to a user supplied address.",
"id": "GHSA-5mvp-rfqx-xfgv",
"modified": "2022-05-13T01:48:05Z",
"published": "2022-05-13T01:48:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9724"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2017-09-01"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/100658"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:N/UI:R/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.