Common Weakness Enumeration

CWE-732

Allowed-with-Review

Incorrect 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.

2221 vulnerabilities reference this CWE, most recent first.

GHSA-RGMH-52XQ-8WG7

Vulnerability from github – Published: 2024-04-07 09:30 – Updated: 2024-12-09 18:31
VLAI
Details

The SystemUI module has a vulnerability in permission management. Impact: Successful exploitation of this vulnerability may affect availability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-52715"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-07T09:15:08Z",
    "severity": "HIGH"
  },
  "details": "The SystemUI module has a vulnerability in permission management.\nImpact: Successful exploitation of this vulnerability may affect availability.",
  "id": "GHSA-rgmh-52xq-8wg7",
  "modified": "2024-12-09T18:31:18Z",
  "published": "2024-04-07T09:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52715"
    },
    {
      "type": "WEB",
      "url": "https://consumer.huawei.com/en/support/bulletin/2024/4"
    },
    {
      "type": "WEB",
      "url": "https://https://device.harmonyos.com/en/docs/security/update/security-bulletins-202404-0000001880501689"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RH76-VMRR-W867

Vulnerability from github – Published: 2025-05-26 18:30 – Updated: 2025-05-26 18:30
VLAI
Details

For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-46802"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-26T16:15:20Z",
    "severity": "MODERATE"
  },
  "details": "For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.",
  "id": "GHSA-rh76-vmrr-w867",
  "modified": "2025-05-26T18:30:25Z",
  "published": "2025-05-26T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46802"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-46802"
    },
    {
      "type": "WEB",
      "url": "https://www.openwall.com/lists/oss-security/2025/05/12/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:N/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-RHGP-6WQ6-9J67

Vulnerability from github – Published: 2026-06-22 17:11 – Updated: 2026-06-22 17:11
VLAI
Summary
motionEye's World-Readable Configuration File Exposes Admin Password Hash
Details

Security Advisory: World-Readable Configuration File Exposes Admin Password Hash in motionEye

Summary

motionEye v0.43.1 and prior versions create the configuration file /etc/motioneye/motion.conf with 644 permissions (-rw-r--r--), making it readable by any local user on the system. This file contains sensitive data including the admin password hash, which can be leveraged by other vulnerabilities to escalate privileges.

Affected Versions

  • motionEye <= 0.43.1b4
  • Fixed in motionEye 0.44.0b1 (applies 0600 mode to motion.conf and camera-*.conf files)

Vulnerability Details

World-Readable Configuration File (CWE-732)

When motionEye writes its configuration, the file /etc/motioneye/motion.conf is created with 644 permissions regardless of the installation method. This file contains the admin password hash in the @admin_password field:

# @admin_username admin
# @admin_password c18006fc138809314751cd1991f1e0b820fabd37

Any local user can read this hash without elevated privileges:

$ sudo -u testuser cat /etc/motioneye/motion.conf
# @admin_password c18006fc138809314751cd1991f1e0b820fabd37

Additionally, per-camera configuration files (camera-*.conf) are also created with the same 644 permissions, potentially exposing camera-specific credentials and settings.

Impact

The exposed admin password hash enables several attack paths:

  • Offline password cracking: The SHA1 hash can be cracked to recover the plaintext admin password
  • Authentication bypass: When combined with the signature authentication weakness (see GHSA-45h7-499j-7ww3), the hash can be used directly to forge authenticated admin API requests
  • Full system compromise: When further chained with CVE-2025-60787 (OS command injection), a local unprivileged user can escalate to the Motion daemon user (often root)

Proof of Concept

The following demonstrates that an unprivileged user can read the admin password hash from the config file and verify it matches the admin's password:

# Verify the file permissions
$ ls -la /etc/motioneye/motion.conf
-rw-r--r-- 1 motion motion 255 Mar 11 15:42 /etc/motioneye/motion.conf

# Read the hash as an unprivileged user
$ sudo -u testuser cat /etc/motioneye/motion.conf | grep admin_password
# @admin_password c18006fc138809314751cd1991f1e0b820fabd37

# Verify the hash matches the admin password (SHA1)
$ sudo -u testuser python3 -c "import hashlib; print(hashlib.sha1(b'testpassword123').hexdigest())"
c18006fc138809314751cd1991f1e0b820fabd37

Verified Output

The following output was captured on a fresh motionEye v0.43.1b4 installation (official motioneye_init method, admin password set to testpassword123):

$ ls -la /etc/motioneye/motion.conf
-rw-r--r-- 1 motion motion 255 Mar 11 15:42 /etc/motioneye/motion.conf

$ sudo -u testuser cat /etc/motioneye/motion.conf | grep admin_password
# @admin_password c18006fc138809314751cd1991f1e0b820fabd37

$ sudo -u testuser python3 -c "import hashlib; print(hashlib.sha1(b'testpassword123').hexdigest())"
c18006fc138809314751cd1991f1e0b820fabd37

The hash extracted by the unprivileged testuser matches the SHA1 of the admin password, confirming full credential exposure.

Reproduction Steps

This vulnerability has been tested and confirmed with both installation methods described in the official motionEye documentation.

Method 1: Manual Installation

  1. Install motionEye on a Linux system: bash sudo pip install motioneye mkdir -p /etc/motioneye /var/log/motioneye /var/lib/motioneye /run/motioneye cp /usr/local/lib/python3.12/dist-packages/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf sudo meyectl startserver -c /etc/motioneye/motioneye.conf

  2. Set an admin password via the web UI at http://localhost:8765

  3. Verify the config file is world-readable: bash ls -la /etc/motioneye/motion.conf # -rw-r--r-- 1 root root 255 ... /etc/motioneye/motion.conf

  4. As an unprivileged user, read the hash: bash sudo -u testuser cat /etc/motioneye/motion.conf # @admin_password c18006fc138809314751cd1991f1e0b820fabd37

Method 2: Official motioneye_init Installation

  1. Install motionEye using the official init script: bash sudo pip install motioneye sudo motioneye_init

  2. The motioneye_init script automatically creates the required directories, installs the systemd service, and starts motionEye. Set an admin password via the web UI at http://localhost:8765

  3. Verify the config file is still world-readable: bash ls -la /etc/motioneye/motion.conf # -rw-r--r-- 1 motion motion 255 ... /etc/motioneye/motion.conf

Note that while the ownership changes to motion:motion (instead of root:root in the manual method), the permissions remain 644, meaning any local user can still read the file.

  1. Confirm as an unprivileged user: bash sudo -u testuser cat /etc/motioneye/motion.conf # @admin_password c18006fc138809314751cd1991f1e0b820fabd37

Both installation methods produce the same vulnerable state, confirming this is the default behavior of the software and not a user misconfiguration.

Related Vulnerabilities

  • GHSA-45h7-499j-7ww3: Password hash accepted as API signing key (CWE-836), which allows the hash exposed by this vulnerability to be used for forging authenticated admin API requests
  • CVE-2025-60787: OS command injection via image_file_name, which requires admin authentication. When chained with both this vulnerability and GHSA-45h7-499j-7ww3, enables local privilege escalation to root

Suggested Remediation

  1. Fix file permissions: Create motion.conf and camera-*.conf with 600 permissions (-rw-------), readable only by the motionEye service user (addressed in motionEye 0.44.0b1)

Timeline

  • 2026-03-11: Vulnerability discovered during security research
  • 2026-03-11: Vendor notified via GitHub Security Advisory
  • 2026-03-12: Vendor acknowledged, confirmed fix in motionEye 0.44.0b1
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "motioneye"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.44.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32315"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T17:11:36Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "# Security Advisory: World-Readable Configuration File Exposes Admin Password Hash in motionEye\n\n## Summary\n\nmotionEye v0.43.1 and prior versions create the configuration file `/etc/motioneye/motion.conf` with `644` permissions (`-rw-r--r--`), making it readable by any local user on the system. This file contains sensitive data including the admin password hash, which can be leveraged by other vulnerabilities to escalate privileges.\n\n## Affected Versions\n\n- motionEye \u003c= 0.43.1b4\n- Fixed in motionEye 0.44.0b1 (applies `0600` mode to `motion.conf` and `camera-*.conf` files)\n\n## Vulnerability Details\n\n### World-Readable Configuration File (CWE-732)\n\nWhen motionEye writes its configuration, the file `/etc/motioneye/motion.conf` is created with `644` permissions regardless of the installation method. This file contains the admin password hash in the `@admin_password` field:\n\n```\n# @admin_username admin\n# @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n```\n\nAny local user can read this hash without elevated privileges:\n\n```bash\n$ sudo -u testuser cat /etc/motioneye/motion.conf\n# @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n```\n\nAdditionally, per-camera configuration files (`camera-*.conf`) are also created with the same `644` permissions, potentially exposing camera-specific credentials and settings.\n\n## Impact\n\nThe exposed admin password hash enables several attack paths:\n\n- **Offline password cracking:** The SHA1 hash can be cracked to recover the plaintext admin password\n- **Authentication bypass:** When combined with the signature authentication weakness (see GHSA-45h7-499j-7ww3), the hash can be used directly to forge authenticated admin API requests\n- **Full system compromise:** When further chained with CVE-2025-60787 (OS command injection), a local unprivileged user can escalate to the Motion daemon user (often root)\n\n## Proof of Concept\n\nThe following demonstrates that an unprivileged user can read the admin password hash from the config file and verify it matches the admin\u0027s password:\n\n```bash\n# Verify the file permissions\n$ ls -la /etc/motioneye/motion.conf\n-rw-r--r-- 1 motion motion 255 Mar 11 15:42 /etc/motioneye/motion.conf\n\n# Read the hash as an unprivileged user\n$ sudo -u testuser cat /etc/motioneye/motion.conf | grep admin_password\n# @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n\n# Verify the hash matches the admin password (SHA1)\n$ sudo -u testuser python3 -c \"import hashlib; print(hashlib.sha1(b\u0027testpassword123\u0027).hexdigest())\"\nc18006fc138809314751cd1991f1e0b820fabd37\n```\n\n### Verified Output\n\nThe following output was captured on a fresh motionEye v0.43.1b4 installation (official `motioneye_init` method, admin password set to `testpassword123`):\n\n```\n$ ls -la /etc/motioneye/motion.conf\n-rw-r--r-- 1 motion motion 255 Mar 11 15:42 /etc/motioneye/motion.conf\n\n$ sudo -u testuser cat /etc/motioneye/motion.conf | grep admin_password\n# @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n\n$ sudo -u testuser python3 -c \"import hashlib; print(hashlib.sha1(b\u0027testpassword123\u0027).hexdigest())\"\nc18006fc138809314751cd1991f1e0b820fabd37\n```\n\nThe hash extracted by the unprivileged `testuser` matches the SHA1 of the admin password, confirming full credential exposure.\n\n## Reproduction Steps\n\nThis vulnerability has been tested and confirmed with both installation methods described in the official motionEye documentation.\n\n### Method 1: Manual Installation\n\n1. Install motionEye on a Linux system:\n   ```bash\n   sudo pip install motioneye\n   mkdir -p /etc/motioneye /var/log/motioneye /var/lib/motioneye /run/motioneye\n   cp /usr/local/lib/python3.12/dist-packages/motioneye/extra/motioneye.conf.sample /etc/motioneye/motioneye.conf\n   sudo meyectl startserver -c /etc/motioneye/motioneye.conf\n   ```\n\n2. Set an admin password via the web UI at `http://localhost:8765`\n\n3. Verify the config file is world-readable:\n   ```bash\n   ls -la /etc/motioneye/motion.conf\n   # -rw-r--r-- 1 root root 255 ... /etc/motioneye/motion.conf\n   ```\n\n4. As an unprivileged user, read the hash:\n   ```bash\n   sudo -u testuser cat /etc/motioneye/motion.conf\n   # @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n   ```\n\n### Method 2: Official `motioneye_init` Installation\n\n1. Install motionEye using the official init script:\n   ```bash\n   sudo pip install motioneye\n   sudo motioneye_init\n   ```\n\n2. The `motioneye_init` script automatically creates the required directories, installs the systemd service, and starts motionEye. Set an admin password via the web UI at `http://localhost:8765`\n\n3. Verify the config file is still world-readable:\n   ```bash\n   ls -la /etc/motioneye/motion.conf\n   # -rw-r--r-- 1 motion motion 255 ... /etc/motioneye/motion.conf\n   ```\n\n   Note that while the ownership changes to `motion:motion` (instead of `root:root` in the manual method), the permissions remain `644`, meaning any local user can still read the file.\n\n4. Confirm as an unprivileged user:\n   ```bash\n   sudo -u testuser cat /etc/motioneye/motion.conf\n   # @admin_password c18006fc138809314751cd1991f1e0b820fabd37\n   ```\n\nBoth installation methods produce the same vulnerable state, confirming this is the default behavior of the software and not a user misconfiguration.\n\n## Related Vulnerabilities\n\n- **GHSA-45h7-499j-7ww3:** Password hash accepted as API signing key (CWE-836), which allows the hash exposed by this vulnerability to be used for forging authenticated admin API requests\n- **CVE-2025-60787:** OS command injection via `image_file_name`, which requires admin authentication. When chained with both this vulnerability and GHSA-45h7-499j-7ww3, enables local privilege escalation to root\n\n## Suggested Remediation\n\n1. **Fix file permissions:** Create `motion.conf` and `camera-*.conf` with `600` permissions (`-rw-------`), readable only by the motionEye service user (addressed in motionEye 0.44.0b1)\n\n## Timeline\n\n- **2026-03-11:** Vulnerability discovered during security research\n- **2026-03-11:** Vendor notified via GitHub Security Advisory\n- **2026-03-12:** Vendor acknowledged, confirmed fix in motionEye 0.44.0b1",
  "id": "GHSA-rhgp-6wq6-9j67",
  "modified": "2026-06-22T17:11:37Z",
  "published": "2026-06-22T17:11:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/motioneye-project/motioneye/security/advisories/GHSA-rhgp-6wq6-9j67"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/motioneye-project/motioneye"
    }
  ],
  "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"
    }
  ],
  "summary": "motionEye\u0027s World-Readable Configuration File Exposes Admin Password Hash"
}

GHSA-RHHC-XVM8-7W83

Vulnerability from github – Published: 2025-12-19 03:31 – Updated: 2025-12-19 03:31
VLAI
Details

A local privilege escalation vulnerability exists in the Foxit PDF Reader/Editor Update Service. During plugin installation, incorrect file system permissions are assigned to resources used by the update service. A local attacker with low privileges could modify or replace these resources, which are later executed by the service, resulting in execution of arbitrary code with SYSTEM privileges.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-13941"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-19T02:16:04Z",
    "severity": "HIGH"
  },
  "details": "A local privilege escalation vulnerability exists in the Foxit PDF Reader/Editor Update Service. During plugin installation, incorrect file system permissions are assigned to resources used by the update service. A local attacker with low privileges could modify or replace these resources, which are later executed by the service, resulting in execution of arbitrary code with SYSTEM privileges.",
  "id": "GHSA-rhhc-xvm8-7w83",
  "modified": "2025-12-19T03:31:18Z",
  "published": "2025-12-19T03:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13941"
    },
    {
      "type": "WEB",
      "url": "https://www.foxit.com/support/security-bulletins.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RHQM-JG9X-WP83

Vulnerability from github – Published: 2023-05-04 21:30 – Updated: 2024-04-04 03:49
VLAI
Details

Insecure permissions in the settings page of GARO Wallbox GLB/GTB/GTC before v189 allows attackers to redirect users to a crafted update package link via a man-in-the-middle attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-30399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-04T21:15:11Z",
    "severity": "HIGH"
  },
  "details": "Insecure permissions in the settings page of GARO Wallbox GLB/GTB/GTC before v189 allows attackers to redirect users to a crafted update package link via a man-in-the-middle attack.",
  "id": "GHSA-rhqm-jg9x-wp83",
  "modified": "2024-04-04T03:49:09Z",
  "published": "2023-05-04T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30399"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Yof3ng/IoT/blob/master/Garo/CVE-2023-30399.md"
    },
    {
      "type": "WEB",
      "url": "https://www.garo.se"
    },
    {
      "type": "WEB",
      "url": "http://garocharging.com/glb-wallbox"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RJ7F-MCVJ-V87G

Vulnerability from github – Published: 2022-05-24 19:17 – Updated: 2022-07-26 00:01
VLAI
Details

Tad Book3 editing book page does not perform identity verification. Remote attackers can use the vulnerability to view and modify arbitrary content of books without permission.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-41974"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-285",
      "CWE-306",
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-08T16:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "Tad Book3 editing book page does not perform identity verification. Remote attackers can use the vulnerability to view and modify arbitrary content of books without permission.",
  "id": "GHSA-rj7f-mcvj-v87g",
  "modified": "2022-07-26T00:01:12Z",
  "published": "2022-05-24T19:17:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41974"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-5173-e21ba-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RMQ6-X837-659X

Vulnerability from github – Published: 2022-05-13 01:45 – Updated: 2022-05-13 01:45
VLAI
Details

VMware Xenon 1.x, prior to 1.5.4-CR7_1, 1.5.7_7, 1.5.4-CR6_2, 1.3.7-CR1_2, 1.1.0-CR0-3, 1.1.0-CR3_1,1.4.2-CR4_1, and 1.5.4_8, contains an authentication bypass vulnerability due to insufficient access controls for utility endpoints. Successful exploitation of this issue may result in information disclosure.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-4952"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-02T14:29:00Z",
    "severity": "HIGH"
  },
  "details": "VMware Xenon 1.x, prior to 1.5.4-CR7_1, 1.5.7_7, 1.5.4-CR6_2, 1.3.7-CR1_2, 1.1.0-CR0-3, 1.1.0-CR3_1,1.4.2-CR4_1, and 1.5.4_8, contains an authentication bypass vulnerability due to insufficient access controls for utility endpoints. Successful exploitation of this issue may result in information disclosure.",
  "id": "GHSA-rmq6-x837-659x",
  "modified": "2022-05-13T01:45:58Z",
  "published": "2022-05-13T01:45:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-4952"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/055ae13603f0cc3cd7cf59f20ce314bf8db583e1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/06b9947cf603ba40fd8b03bfeb2e84528a7ab592"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/30ae41bccf418d88b52b35a81efb3c1304b798f8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/5682ef8d40569afd00fb9a5933e7706bb5b66713"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/756d893573414eec8635c2aba2345c4dcf10b21c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/7a747d82b80cd38d2c11a0d9cdedb71c722a2c75"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/b1fd306047ecdac82661d636ebee801a7f2b3a0a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/c23964eb57e846126daef98ef7ed15400313e977"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vmware/xenon/commit/ec30db9afada9cb52852082ce4d7d0095524f3b3"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/oss-sec/2018/q1/153"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/103093"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RMX3-FC98-HH3F

Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49
VLAI
Details

Improper access control in core module lead XBL_LOADER performs the ZI region clear for QTEE instead of XBL_SEC in Snapdragon Mobile in version SD 845, SD 850.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-11951"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-26T13:29:00Z",
    "severity": "MODERATE"
  },
  "details": "Improper access control in core module lead XBL_LOADER performs the ZI region clear for QTEE instead of XBL_SEC in Snapdragon Mobile in version SD 845, SD 850.",
  "id": "GHSA-rmx3-fc98-hh3f",
  "modified": "2022-05-13T01:49:23Z",
  "published": "2022-05-13T01:49:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11951"
    },
    {
      "type": "WEB",
      "url": "https://www.qualcomm.com/company/product-security/bulletins"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RPG9-M4GW-3XWF

Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-11-08 19:00
VLAI
Details

debian/sympa.postinst for the Debian Sympa package before 6.2.40~dfsg-7 uses mode 4755 for sympa_newaliases-wrapper, whereas the intended permissions are mode 4750 (for access by the sympa group)

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-26932"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-10-10T18:15:00Z",
    "severity": "MODERATE"
  },
  "details": "debian/sympa.postinst for the Debian Sympa package before 6.2.40~dfsg-7 uses mode 4755 for sympa_newaliases-wrapper, whereas the intended permissions are mode 4750 (for access by the sympa group)",
  "id": "GHSA-rpg9-m4gw-3xwf",
  "modified": "2022-11-08T19:00:25Z",
  "published": "2022-05-24T17:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-26932"
    },
    {
      "type": "WEB",
      "url": "https://bugs.debian.org/971904"
    },
    {
      "type": "WEB",
      "url": "https://salsa.debian.org/sympa-team/sympa/-/merge_requests/1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4818"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-RPMF-VPJ8-R88J

Vulnerability from github – Published: 2024-07-18 18:31 – Updated: 2026-06-03 15:30
VLAI
Details

Incorrect Permission Assignment for Critical Resource vulnerability in PruvaSoft Informatics Apinizer Management Console allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Apinizer Management Console: before 2024.05.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-5618"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-18T17:15:05Z",
    "severity": "CRITICAL"
  },
  "details": "Incorrect Permission Assignment for Critical Resource vulnerability in PruvaSoft Informatics Apinizer Management Console allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects Apinizer Management Console: before 2024.05.1.",
  "id": "GHSA-rpmf-vpj8-r88j",
  "modified": "2026-06-03T15:30:33Z",
  "published": "2024-07-18T18:31:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5618"
    },
    {
      "type": "WEB",
      "url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-24-1010"
    },
    {
      "type": "WEB",
      "url": "https://www.usom.gov.tr/bildirim/tr-24-1010"
    }
  ],
  "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"
    }
  ]
}

Mitigation
Implementation

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
Architecture and Design

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
Architecture and Design Operation

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
Implementation Installation

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
System Configuration

For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.

Mitigation
Documentation

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
Installation

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
Operation System Configuration

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
Implementation System Configuration Operation

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.