GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-281

Allowed

Improper Preservation of Permissions

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product does not preserve permissions or incorrectly preserves permissions when copying, restoring, or sharing objects, which can cause them to have less restrictive permissions than intended.

445 vulnerabilities reference this CWE, most recent first.

GHSA-F626-W254-W424

Vulnerability from github – Published: 2025-04-10 21:31 – Updated: 2025-04-10 21:31
VLAI
Details

Improper Preservation of Permissions vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/editpage/IntroMessageBuilder.Php, includes/Permissions/PermissionManager.Php, includes/Permissions/RestrictionStore.Php.

This issue affects MediaWiki: before 1.42.6, 1.43.1.

Severity
0.0 (None)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N/RE:M/U:Green
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-32697"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-10T19:16:01Z",
    "severity": "LOW"
  },
  "details": "Improper Preservation of Permissions vulnerability in Wikimedia Foundation MediaWiki. This vulnerability is associated with program files includes/editpage/IntroMessageBuilder.Php, includes/Permissions/PermissionManager.Php, includes/Permissions/RestrictionStore.Php.\n\nThis issue affects MediaWiki: before 1.42.6, 1.43.1.",
  "id": "GHSA-f626-w254-w424",
  "modified": "2025-04-10T21:31:09Z",
  "published": "2025-04-10T21:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32697"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T140010"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T24521"
    },
    {
      "type": "WEB",
      "url": "https://phabricator.wikimedia.org/T62109"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:N/VI:N/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:M/U:Green",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-F8G7-2XJC-7MFH

Vulnerability from github – Published: 2026-09-10 22:51 – Updated: 2026-09-10 22:51
VLAI
Summary
rclone: Directory metadata (chmod/chown/chtimes) applied through a planted symlink in rclone local --links escapes the destination
Details

Summary

With -l/--links, rclone's local backend recreates a source .rclonelink object as a real symlink at the destination verbatim (preserved by design for faithful backups). Directory-metadata application, however, does not go through the os.Root sandbox and does not use NOFOLLOW syscalls. A local Directory always has translatedLink=false, so when the destination path already exists as a planted symlink, rclone applies chmod/chown/chtimes through that symlink to a target outside the destination tree. An attacker who controls the source contents (malicious/compromised remote, shared bucket) obtains attacker-valued chmod/chown/chtimes of an arbitrary path outside the backup destination.

Root Cause

  • MkdirMetadata (backend/local/local.go:895) calls f.lstat (=os.Lstat, local.go:465) on the destination path. On a pre-planted symlink, os.Lstat succeeds, so the errors.Is(err, os.ErrNotExist) branch (local.go:896) that would create a real directory via the os.Root-guarded f.Mkdir is not taken. Instead a Directory is built directly on the symlink path.
  • writeMetadataToFile runs raw os.Chown (backend/local/metadata.go:131) and os.Chmod (metadata.go:158); setTimes runs raw os.Chtimes (backend/local/local.go:1318).
  • The CVE-2024-52522 NOFOLLOW fix (os.Lchown/lChmod/lChtimes) is gated on if o.translatedLink (metadata.go:128/150, local.go:1315). A Directory (newDirectory→newObject with no .rclonelink suffix) is never translatedLink, so it always takes the raw following branch. The CVE-2026-54572 os.Root fix covers only content writes, not metadata syscalls.

Impact

Attacker-controlled chmod/chown/chtimes (values taken from the source directory's mode/uid/gid/mtime) applied to any file or directory outside the destination. chtimes (mtime) escape works with just --links and default flags; chmod/chown escape additionally needs --metadata. When rclone runs as root with --metadata and a source uid=0, the chown primitive reaches the CVE-2024-52522 privilege-escalation ceiling (take ownership of an out-of-tree path).

Proof of Concept

mkdir -p /src /dest
# run 1: source object pwn.rclonelink whose body = /home/victim/secret.d
printf '/home/victim/secret.d' > /src/pwn.rclonelink
rclone sync --links /src /dest              # plants /dest/pwn -> /home/victim/secret.d
# attacker swaps source pwn to a real directory with chosen metadata:
rm /src/pwn.rclonelink ; mkdir -p /src/pwn/keep ; chmod 777 /src/pwn
rclone sync --links --metadata /src /dest   # MkdirMetadata sees /dest/pwn exists (symlink) ->
                                            # chmod 0777 applied THROUGH it to /home/victim/secret.d
ls -ld /home/victim/secret.d                # => drwxrwxrwx  (outside dir, attacker-chosen mode)

A single-run PoC is achievable against directory-based object sources (drive/onedrive-class) that satisfy both ReadDirMetadata and CanHaveEmptyDirectories and can present pwn.rclonelink and pwn/ simultaneously. Local→local uses the two-run backup model (same repeated-backup model as CVE-2024-52522 and CVE-2026-54572). Verified end-to-end against the real fs/sync.Sync engine on HEAD: the two-run backup backdated the outside target's mtime and chmod'd it 0777 while os.Root correctly blocked the content-copy of pwn/keep — isolating the metadata gap.

Attack Chain

  1. Entry. Victim runs rclone copy/sync --links [--metadata] <untrusted-remote>: /dest. Attacker controls source contents.
  2. Guard: none — --links copying an untrusted remote is a documented, supported operation.
  3. Plant symlink. Source serves pwn.rclonelink with body = absolute outside path; rclone recreates dst/pwn → outside.
  4. Guard: Fs.symlink routes creation through os.Root.Symlink (local.go:~1552).
  5. Bypass proof: os.Root creates the link verbatim by design (commit 1154afe); the upstream os.Root fix's test TestSymlinkEscapeWriteThroughBlocked confirms only write-through is refused, the link is planted.
  6. Deferred dir-metadata fires after transfers. Source presents non-empty dir pwn; setDelayedDirModTimes (sync.go:1002) runs strictly after stopTransfers() (sync.go:988) — after the symlink is planted.
  7. Guard: MkdirMetadata would create a real dir via os.Root-guarded f.Mkdir (local.go:897) inside its errors.Is(err, os.ErrNotExist) branch.
  8. Bypass proof: os.Lstat (local.go:465) on the existing symlink returns success, so the ErrNotExist branch (local.go:896) is NOT taken; f.Mkdir/os.Root never runs. Empirically os.IsNotExist(err)=false for the planted symlink.
  9. Sink follows the symlink. CopyDirMetadata→MkdirMetadata→writeMetadataToFile runs os.Chown/os.Chmod (metadata.go:131/158); DirSetModTime→setTimes runs os.Chtimes (local.go:1318) — all on o.path="dst/pwn" with translatedLink=false.
  10. Guard: CVE-2024-52522 NOFOLLOW branch (os.Lchown/lChmod/lChtimes).
  11. Bypass proof: that branch is gated on if o.translatedLink (metadata.go:128/150, local.go:1315); a Directory always has translatedLink=false, so the raw following branch runs. POSIX-confirmed: chmod 777/touch on a symlink path change the target's mode/mtime.
  12. Impact. chmod/chown/chtimes on an attacker-chosen path outside the destination, with attacker-controlled values.

Bypass Evidence

  • if o.translatedLink gates verified verbatim on v1.75.0 at metadata.go:128/150 and local.go:1315; os.Chown/os.Chmod/os.Chtimes on the else branch at metadata.go:131/158 and local.go:1318.
  • newDirectory→newObject (local.go:581/589/596) never sets the .rclonelink suffix → translatedLink=false for all directories.
  • MkdirMetadata skip branch: os.Lstat succeeds on planted symlink → errors.Is(err, os.ErrNotExist) false at local.go:896 → guarded f.Mkdir skipped.
  • Real fs/sync.Sync E2E on HEAD: TestDirMetadataThroughPlantedSymlink (outside dir → 0777), TestDirSetModTimeThroughPlantedSymlink (mtime set, default-on), TestE2E_TwoRunBackup (backdated outside target while content-copy blocked by os.Root). All PASS. Control TestControl_ContentWriteBlocked confirms harness fidelity.

Affected Versions

<= 1.75.0. Vulnerable code present on latest release tag v1.75.0 and HEAD (5629f26); git log v1.75.0..HEAD -- backend/local/metadata.go backend/local/local.go is empty (no post-release fix).

Suggested Fix

Route directory metadata through os.Root when TranslateSymlinks is set (use fchmodat(AT_SYMLINK_NOFOLLOW)/Lchown/UtimesNanoAt(AT_SYMLINK_NOFOLLOW) on the rel path within the root), and/or extend MkdirMetadata to detect that the pre-existing destination path is a symlink and refuse to apply following-metadata — mirroring the CVE-2024-52522 NOFOLLOW branch that currently exists only for translatedLink objects.

Reported by zx (Jace) — GitHub: @manus-use

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.75.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rclone/rclone"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.75.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-88016"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-59",
      "CWE-281"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-10T22:51:34Z",
    "nvd_published_at": "2026-09-10T16:18:08Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nWith `-l/--links`, rclone\u0027s local backend recreates a source `.rclonelink` object as a real symlink at the destination **verbatim** (preserved by design for faithful backups). Directory-metadata application, however, does **not** go through the `os.Root` sandbox and does **not** use NOFOLLOW syscalls. A local `Directory` always has `translatedLink=false`, so when the destination path already exists as a planted symlink, rclone applies `chmod`/`chown`/`chtimes` **through** that symlink to a target **outside** the destination tree. An attacker who controls the source contents (malicious/compromised remote, shared bucket) obtains attacker-valued `chmod`/`chown`/`chtimes` of an arbitrary path outside the backup destination.\n\n## Root Cause\n- `MkdirMetadata` (`backend/local/local.go:895`) calls `f.lstat` (=`os.Lstat`, local.go:465) on the destination path. On a pre-planted symlink, `os.Lstat` succeeds, so the `errors.Is(err, os.ErrNotExist)` branch (local.go:896) that would create a real directory via the `os.Root`-guarded `f.Mkdir` is **not** taken. Instead a `Directory` is built directly on the symlink path.\n- `writeMetadataToFile` runs raw `os.Chown` (`backend/local/metadata.go:131`) and `os.Chmod` (`metadata.go:158`); `setTimes` runs raw `os.Chtimes` (`backend/local/local.go:1318`).\n- The CVE-2024-52522 NOFOLLOW fix (`os.Lchown`/`lChmod`/`lChtimes`) is gated on `if o.translatedLink` (metadata.go:128/150, local.go:1315). A `Directory` (`newDirectory`\u2192`newObject` with no `.rclonelink` suffix) is never `translatedLink`, so it always takes the raw *following* branch. The CVE-2026-54572 `os.Root` fix covers only content **writes**, not metadata syscalls.\n\n## Impact\nAttacker-controlled `chmod`/`chown`/`chtimes` (values taken from the source directory\u0027s mode/uid/gid/mtime) applied to any file or directory **outside** the destination. `chtimes` (mtime) escape works with just `--links` and default flags; `chmod`/`chown` escape additionally needs `--metadata`. When rclone runs as root with `--metadata` and a source `uid=0`, the `chown` primitive reaches the CVE-2024-52522 privilege-escalation ceiling (take ownership of an out-of-tree path).\n\n## Proof of Concept\n```\nmkdir -p /src /dest\n# run 1: source object pwn.rclonelink whose body = /home/victim/secret.d\nprintf \u0027/home/victim/secret.d\u0027 \u003e /src/pwn.rclonelink\nrclone sync --links /src /dest              # plants /dest/pwn -\u003e /home/victim/secret.d\n# attacker swaps source pwn to a real directory with chosen metadata:\nrm /src/pwn.rclonelink ; mkdir -p /src/pwn/keep ; chmod 777 /src/pwn\nrclone sync --links --metadata /src /dest   # MkdirMetadata sees /dest/pwn exists (symlink) -\u003e\n                                            # chmod 0777 applied THROUGH it to /home/victim/secret.d\nls -ld /home/victim/secret.d                # =\u003e drwxrwxrwx  (outside dir, attacker-chosen mode)\n```\nA single-run PoC is achievable against directory-based object sources (drive/onedrive-class) that satisfy both `ReadDirMetadata` and `CanHaveEmptyDirectories` and can present `pwn.rclonelink` and `pwn/` simultaneously. Local\u2192local uses the two-run backup model (same repeated-backup model as CVE-2024-52522 and CVE-2026-54572). Verified end-to-end against the real `fs/sync.Sync` engine on HEAD: the two-run backup backdated the outside target\u0027s mtime and chmod\u0027d it 0777 while os.Root correctly blocked the content-copy of `pwn/keep` \u2014 isolating the metadata gap.\n\n## Attack Chain\n1. **Entry.** Victim runs `rclone copy`/`sync --links [--metadata] \u003cuntrusted-remote\u003e: /dest`. Attacker controls source contents.\n   - Guard: none \u2014 `--links` copying an untrusted remote is a documented, supported operation.\n2. **Plant symlink.** Source serves `pwn.rclonelink` with body = absolute outside path; rclone recreates `dst/pwn` \u2192 outside.\n   - Guard: `Fs.symlink` routes creation through `os.Root.Symlink` (local.go:~1552).\n   - Bypass proof: `os.Root` creates the link **verbatim by design** (commit 1154afe); the upstream `os.Root` fix\u0027s test `TestSymlinkEscapeWriteThroughBlocked` confirms only write-*through* is refused, the link is planted.\n3. **Deferred dir-metadata fires after transfers.** Source presents non-empty dir `pwn`; `setDelayedDirModTimes` (sync.go:1002) runs strictly after `stopTransfers()` (sync.go:988) \u2014 after the symlink is planted.\n   - Guard: `MkdirMetadata` would create a real dir via os.Root-guarded `f.Mkdir` (local.go:897) inside its `errors.Is(err, os.ErrNotExist)` branch.\n   - Bypass proof: `os.Lstat` (local.go:465) on the existing symlink returns success, so the `ErrNotExist` branch (local.go:896) is NOT taken; `f.Mkdir`/os.Root never runs. Empirically `os.IsNotExist(err)=false` for the planted symlink.\n4. **Sink follows the symlink.** `CopyDirMetadata`\u2192`MkdirMetadata`\u2192`writeMetadataToFile` runs `os.Chown`/`os.Chmod` (metadata.go:131/158); `DirSetModTime`\u2192`setTimes` runs `os.Chtimes` (local.go:1318) \u2014 all on `o.path=\"dst/pwn\"` with `translatedLink=false`.\n   - Guard: CVE-2024-52522 NOFOLLOW branch (`os.Lchown`/`lChmod`/`lChtimes`).\n   - Bypass proof: that branch is gated on `if o.translatedLink` (metadata.go:128/150, local.go:1315); a `Directory` always has `translatedLink=false`, so the raw following branch runs. POSIX-confirmed: `chmod 777`/`touch` on a symlink path change the *target\u0027s* mode/mtime.\n5. **Impact.** `chmod`/`chown`/`chtimes` on an attacker-chosen path outside the destination, with attacker-controlled values.\n\n## Bypass Evidence\n- `if o.translatedLink` gates verified verbatim on v1.75.0 at metadata.go:128/150 and local.go:1315; `os.Chown`/`os.Chmod`/`os.Chtimes` on the else branch at metadata.go:131/158 and local.go:1318.\n- `newDirectory`\u2192`newObject` (local.go:581/589/596) never sets the `.rclonelink` suffix \u2192 `translatedLink=false` for all directories.\n- `MkdirMetadata` skip branch: `os.Lstat` succeeds on planted symlink \u2192 `errors.Is(err, os.ErrNotExist)` false at local.go:896 \u2192 guarded `f.Mkdir` skipped.\n- Real `fs/sync.Sync` E2E on HEAD: `TestDirMetadataThroughPlantedSymlink` (outside dir \u2192 0777), `TestDirSetModTimeThroughPlantedSymlink` (mtime set, default-on), `TestE2E_TwoRunBackup` (backdated outside target while content-copy blocked by os.Root). All PASS. Control `TestControl_ContentWriteBlocked` confirms harness fidelity.\n\n## Affected Versions\n`\u003c= 1.75.0`. Vulnerable code present on latest release tag v1.75.0 and HEAD (5629f26); `git log v1.75.0..HEAD -- backend/local/metadata.go backend/local/local.go` is empty (no post-release fix).\n\n## Suggested Fix\nRoute directory metadata through `os.Root` when `TranslateSymlinks` is set (use `fchmodat(AT_SYMLINK_NOFOLLOW)`/`Lchown`/`UtimesNanoAt(AT_SYMLINK_NOFOLLOW)` on the `rel` path within the root), and/or extend `MkdirMetadata` to detect that the pre-existing destination path is a symlink and refuse to apply following-metadata \u2014 mirroring the CVE-2024-52522 NOFOLLOW branch that currently exists only for `translatedLink` objects.\n\n---\nReported by **zx (Jace)** \u2014 GitHub: @manus-use",
  "id": "GHSA-f8g7-2xjc-7mfh",
  "modified": "2026-09-10T22:51:34Z",
  "published": "2026-09-10T22:51:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/security/advisories/GHSA-f8g7-2xjc-7mfh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88016"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/17b0c03338a857bcb0a68d2d4c82ddbdec3f7893"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/commit/a7ab39d3d1958afa1446982c1dc4e4a73a887e3e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rclone/rclone"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rclone/rclone/releases/tag/v1.75.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "rclone: Directory metadata (chmod/chown/chtimes) applied through a planted symlink in rclone local --links escapes the destination"
}

GHSA-FC8M-X59C-5F6R

Vulnerability from github – Published: 2024-07-30 00:34 – Updated: 2026-04-02 21:31
VLAI
Details

An input validation issue was addressed with improved input validation. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to modify protected parts of the file system.

Severity
8.4 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-40800"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-29T23:15:12Z",
    "severity": "HIGH"
  },
  "details": "An input validation issue was addressed with improved input validation. This issue is fixed in macOS Sonoma 14.6, macOS Monterey 12.7.6, macOS Ventura 13.6.8. An app may be able to modify protected parts of the file system.",
  "id": "GHSA-fc8m-x59c-5f6r",
  "modified": "2026-04-02T21:31:50Z",
  "published": "2024-07-30T00:34:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40800"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120910"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120911"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/120912"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214118"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT214120"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214118"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214119"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/kb/HT214120"
    },
    {
      "type": "WEB",
      "url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2024-2010"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/18"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/19"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2024/Jul/20"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FF7W-225P-JFC7

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

Win32k in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an elevation of privilege vulnerability when it fails to properly handle objects in memory, aka "Win32k Elevation of Privilege Vulnerability". This CVE ID is unique from CVE-2017-8578, CVE-2017-8580, CVE-2017-8577, and CVE-2017-8467.

Severity
7.0 (High)
CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-8581"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-11T21:29:00Z",
    "severity": "HIGH"
  },
  "details": "Win32k in Microsoft Windows Server 2008 SP2 and R2 SP1, Windows 7 SP1, Windows 8.1, Windows Server 2012 Gold and R2, Windows RT 8.1, Windows 10 Gold, 1511, 1607, and 1703, and Windows Server 2016 allows an elevation of privilege vulnerability when it fails to properly handle objects in memory, aka \"Win32k Elevation of Privilege Vulnerability\". This CVE ID is unique from CVE-2017-8578, CVE-2017-8580, CVE-2017-8577, and CVE-2017-8467.",
  "id": "GHSA-ff7w-225p-jfc7",
  "modified": "2022-05-13T01:47:38Z",
  "published": "2022-05-13T01:47:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-8581"
    },
    {
      "type": "WEB",
      "url": "https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8581"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99423"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1038853"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FG56-PQV7-FM98

Vulnerability from github – Published: 2021-11-18 00:00 – Updated: 2022-05-04 00:01
VLAI
Details

Insecure inherited permissions in the Intel(R) PROSet/Wireless WiFi software installer for Windows 10 before version 22.40 may allow an authenticated user to potentially enable escalation of privilege via local access.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-0064"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-732"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-17T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Insecure inherited permissions in the Intel(R) PROSet/Wireless WiFi software installer for Windows 10 before version 22.40 may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-fg56-pqv7-fm98",
  "modified": "2022-05-04T00:01:02Z",
  "published": "2021-11-18T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0064"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00509.html"
    }
  ],
  "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-FG57-CQ37-V9F2

Vulnerability from github – Published: 2023-06-23 18:30 – Updated: 2024-04-04 05:07
VLAI
Details

A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in watchOS 9.5, iOS 15.7.6 and iPadOS 15.7.6, macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5, macOS Big Sur 11.7.7, macOS Monterey 12.6.6. An app may be able to bypass Privacy preferences

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-32388"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-23T18:15:12Z",
    "severity": "MODERATE"
  },
  "details": "A privacy issue was addressed with improved private data redaction for log entries. This issue is fixed in watchOS 9.5, iOS 15.7.6 and iPadOS 15.7.6, macOS Ventura 13.4, iOS 16.5 and iPadOS 16.5, macOS Big Sur 11.7.7, macOS Monterey 12.6.6. An app may be able to bypass Privacy preferences",
  "id": "GHSA-fg57-cq37-v9f2",
  "modified": "2024-04-04T05:07:49Z",
  "published": "2023-06-23T18:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-32388"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213757"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213758"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213759"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213760"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213764"
    },
    {
      "type": "WEB",
      "url": "https://support.apple.com/en-us/HT213765"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FJ76-6R22-QFGV

Vulnerability from github – Published: 2022-05-24 17:07 – Updated: 2024-04-04 02:46
VLAI
Details

Gentoo Portage through 2.3.84 allows local users to place a Trojan horse plugin in the /usr/lib64/nagios/plugins directory by leveraging access to the nagios user account, because this directory is writable in between a call to emake and a call to fowners.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-20384"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-362"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-01-21T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Gentoo Portage through 2.3.84 allows local users to place a Trojan horse plugin in the /usr/lib64/nagios/plugins directory by leveraging access to the nagios user account, because this directory is writable in between a call to emake and a call to fowners.",
  "id": "GHSA-fj76-6r22-qfgv",
  "modified": "2024-04-04T02:46:43Z",
  "published": "2022-05-24T17:07:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20384"
    },
    {
      "type": "WEB",
      "url": "https://bugs.gentoo.org/692492"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2020/01/21/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMV9-2X57-JQMV

Vulnerability from github – Published: 2022-05-24 17:33 – Updated: 2022-05-24 17:33
VLAI
Details

Improper permissions in the installer for the Intel(R) Processor Identification Utility before version 6.4.0603 may allow an authenticated user to potentially enable escalation of privilege via local access.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-12335"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-11-12T19:15:00Z",
    "severity": "HIGH"
  },
  "details": "Improper permissions in the installer for the Intel(R) Processor Identification Utility before version 6.4.0603 may allow an authenticated user to potentially enable escalation of privilege via local access.",
  "id": "GHSA-fmv9-2x57-jqmv",
  "modified": "2022-05-24T17:33:35Z",
  "published": "2022-05-24T17:33:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12335"
    },
    {
      "type": "WEB",
      "url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00419"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-FQMF-W4XH-33RH

Vulnerability from github – Published: 2025-01-21 21:13 – Updated: 2025-01-21 21:13
VLAI
Summary
gix-worktree-state nonexclusive checkout sets executable files world-writable
Details

Summary

gix-worktree-state specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.

Details

Git repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).

gix_worktree_state::checkout has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:

  • If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask.
  • If the file is considered possibly already to exist—even in a clean checkout if the application does not specify the option to treat the destination directory as empty—then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask. 

Specifically, checkout::entry::checkout chooses the strategy for each file. The same strategy is usually chosen for each executable file, if no process (i.e. long running) smudge filter is in use. The strategy depends on the checkout::Options::destination_is_initially_empty value, which is passed along to checkout::entry::open_file, whose return value includes a flag indicating whether permissions still need to be set:

  • With destination_is_initially_empty: true, executable permissions are specified when opening the file, via OpenOptionsEx::mode, by its effect on the behavior of OpenOptions::open. A mode of 0777 is safe here, for the same reason the default mode of 0666 is safe. When creating a file, the applied mode is the specified mode with any bits unset from it that are set in the umask.

https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L265-L268

The set_executable_after_creation flag in the open_file return value is then false.

  • With destination_is_initially_empty: false, executable permissions are set in a separate step, via PermissionsExt::set_mode and set_permissions. A mode of 0777 is not safe here, because the umask is not applied. The vulnerable code appears in checkout::entry::finalize_entry, which receives the set_executable_after_creation flag originally from open_file:

https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L288-L293

The file has unrestricted permissions.

finalize_entry is likewise called from checkout::chunk::process_delayed_filter_results.

PoC

  1. On a Unix-like system such as GNU/Linux or macOS, create a new project and define its dependencies. While the vulnerability is in gix-worktree-state, this example will use vulnerable code through the gix crate, which exposes it. Run:

sh cargo new checkout-index cd checkout-index cargo add gix gix-object

  1. In the checkout-index directory, edit src/main.rs so that its entire contents are:

rust fn main() -> Result<(), Box<dyn std::error::Error>> { let repo = gix::discover("has-executable")?; let mut index = repo.open_index()?; gix::worktree::state::checkout( &mut index, repo.work_dir().ok_or("need non-bare repo")?, gix_object::find::Never, // Can also use: repo.objects.clone() &gix::progress::Discard, &gix::progress::Discard, &Default::default(), Default::default(), )?; Ok(()) }

  1. Create the test repository that the vulnerable program will operate on. Still in the checkout-index directory, run:

sh git init has-executable touch has-executable/a has-executable/b chmod +x has-executable/b git -C has-executable add .

It is not necessary to commit the changes, only to stage them, since the test program will check out the index.

  1. Optionally, run rm has-executable/[ab] to remove the staged files from disk.

  2. Run the program by issuing cargo run. The program uses gix-worktree-state to check out the index. It should terminate successfully and not issue any errors.

  3. Run ls -l has-executable to inspect the permissions of the checked out files. Observe that owner, group, and other all have read, write, and execute permissions on b.

text -rw-r--r-- 1 ek ek 0 Jan 9 03:38 a -rwxrwxrwx 1 ek ek 0 Jan 9 03:38 b

With affected versions of gix-worktree-state, the output shows -rwxrwxrwx for b, whether the files were removed in step 4 or not.

  1. It was not necessary to set destination_is_initially_empty to false explicitly to trigger the bug, because that is its default value. If desired, modify the program to pass true and rerun the experiment to verify that b is no longer created with excessive permissions. The modified program would change the last checkout argument from Default::default(), to:

rust gix::worktree::state::checkout::Options { destination_is_initially_empty: true, ..Default::default() },

Impact

Setting unlimited file permissions is a problem on systems where a user account exists on the system that should not have the ability to access and modify the files. That applies to multi-user systems, or when an account is used to run software with reduced abilities. (Some programs may also treat broad write permissions to mean less validation is required.)

This bug affects Unix-like systems but not Windows. The gix clone command is not believed to be affected, due to checkout_exclusive's use of destination_is_initially_empty: true. Specialized uses in which repositories are known never to have any files marked executable are unaffected. Repositories that no untrusted users can access, due to not having the ability to traverse the directories to them or due to sufficiently restrictive ACLs, are likewise unaffected.

The default value of destination_is_initially_empty is false, so some applications may be affected even if they don't attempt checkouts in nonempty directories. The 0777 permissions are applied to files that are created earlier in the same checkout, as well as those that already existed, regardless of their prior permissions. On preexisting files, 0777 is set even if overwrite_existing is false, as that prevents the checkout from changing file contents but not permissions.

Files not tracked/staged as executable are not checked out with insecure permissions. Such a file that previously existed keeps its old permissions. However, this may include executable permissions that no longer match repository metadata, as well as undesired write permissions acquired from a previous vulnerable checkout. set_mode(0o777) clears other bits, so the bug is not exacerbated by the presence of setuid/setgid bits. In some applications, the vulnerable strategy may be used only for files rewritten by a long running smudge filter or only in the presence of delays.

Severity
5.0 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "gix-worktree-state"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-22620"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281",
      "CWE-687"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-21T21:13:06Z",
    "nvd_published_at": "2025-01-20T16:15:28Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`gix-worktree-state` specifies 0777 permissions when checking out executable files, intending that the umask will restrict them appropriately. But one of the strategies it uses to set permissions is not subject to the umask. This causes files in a repository to be world-writable in some situations.\n\n### Details\n\nGit repositories track executable bits for regular files. In tree objects and the index, regular file modes are stored as 0644 if not executable, or 0755 if executable. But this is independent of how the permissions are set in the filesystem (where supported).\n\n[`gix_worktree_state::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/function.rs#L8-L35) has two strategies for checking out a file and marking it executable on a Unix-like operating system, one of which is vulnerable:\n\n- If the file is created by assuming it does not already exist, correct permissions are applied, because permissions specified when opening a file are subject to the umask.\n- If the file is considered possibly already to exist\u2014even in a clean checkout if the application does not specify the option to treat the destination directory as empty\u2014then permissions conferring unrestricted access to any user account on the system are wrongly applied, because permissions specified when calling chmod on an existing file are not subject to the umask.\u00a0\n\nSpecifically, [`checkout::entry::checkout`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L56-L191) chooses the strategy for each file. The same strategy is usually chosen for each executable file, if no [process](https://github.com/git/git/blob/a60673e9252b08d4eca90543b3729f4798b9aafd/Documentation/RelNotes/2.11.0.txt#L149-L154) (i.e. [long running](https://github.com/GitoxideLabs/gitoxide/discussions/996)) smudge filter is in use. The strategy depends on the [`checkout::Options::destination_is_initially_empty`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/mod.rs#L50-L53) value, which is passed along to [`checkout::entry::open_file`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L253-L277), whose return value includes a flag indicating whether permissions still need to be set:\n\n- With `destination_is_initially_empty: true`, executable permissions are specified when opening the file, via [`OpenOptionsEx::mode`](https://doc.rust-lang.org/std/os/unix/fs/trait.OpenOptionsExt.html#tymethod.mode), by its effect on the behavior of [`OpenOptions::open`](https://doc.rust-lang.org/std/fs/struct.OpenOptions.html#method.open). A mode of 0777 is safe here, for the same reason the default mode of 0666 is safe. When creating a file, the applied mode is the specified mode with any bits unset from it that are set in the umask.\n\n   https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L265-L268\n\n  The `set_executable_after_creation` flag in the `open_file` return value is then `false`.\n\n- With `destination_is_initially_empty: false`, executable permissions are set in a separate step, via [`PermissionsExt::set_mode`](https://doc.rust-lang.org/beta/std/os/unix/fs/trait.PermissionsExt.html#tymethod.set_mode) and [`set_permissions`](https://doc.rust-lang.org/beta/std/fs/fn.set_permissions.html). A mode of 0777 is not safe here, because the umask is not applied. The vulnerable code appears in [`checkout::entry::finalize_entry`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L279-L299), which receives the `set_executable_after_creation` flag originally from `open_file`:\n\n  https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/entry.rs#L288-L293\n\n  The file has unrestricted permissions.\n\n`finalize_entry` is [likewise called](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/chunk.rs#L229-L236) from [`checkout::chunk::process_delayed_filter_results`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/chunk.rs#L157-L259).\n\n### PoC\n\n1. On a Unix-like system such as GNU/Linux or macOS, create a new project and define its dependencies. While the vulnerability is in `gix-worktree-state`, this example will use vulnerable code through the `gix` crate, which exposes it. Run:\n\n   ```sh\n   cargo new checkout-index\n   cd checkout-index\n   cargo add gix gix-object\n   ```\n\n2. In the `checkout-index` directory, edit `src/main.rs` so that its entire contents are:\n\n   ```rust\n   fn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n       let repo = gix::discover(\"has-executable\")?;\n       let mut index = repo.open_index()?;\n       gix::worktree::state::checkout(\n           \u0026mut index,\n           repo.work_dir().ok_or(\"need non-bare repo\")?,\n           gix_object::find::Never, // Can also use: repo.objects.clone()\n           \u0026gix::progress::Discard,\n           \u0026gix::progress::Discard,\n           \u0026Default::default(),\n           Default::default(),\n       )?;\n       Ok(())\n   }\n   ```\n\n3. Create the test repository that the vulnerable program will operate on. Still in the `checkout-index` directory, run:\n\n   ```sh\n   git init has-executable\n   touch has-executable/a has-executable/b\n   chmod +x has-executable/b\n   git -C has-executable add .\n   ```\n\n   It is not necessary to commit the changes, only to stage them, since the test program will check  out the index.\n\n4. *Optionally*, run `rm has-executable/[ab]` to remove the staged files from disk.\n\n5. Run the program by issuing `cargo run`. The program uses `gix-worktree-state` to check out the index. It should terminate successfully and not issue any errors.\n\n6. Run `ls -l has-executable` to inspect the permissions of the checked out files. Observe that owner, group, and other all have read, write, and execute permissions on `b`.\n\n   ```text\n   -rw-r--r-- 1 ek ek 0 Jan  9 03:38 a\n   -rwxrwxrwx 1 ek ek 0 Jan  9 03:38 b\n   ```\n\n   With affected versions of `gix-worktree-state`, the output shows `-rwxrwxrwx` for `b`, whether the files were removed in step 4 or not.\n\n7. It was not necessary to set `destination_is_initially_empty` to `false` explicitly to trigger the bug, because that is its default value. If desired, modify the program to pass `true` and rerun the experiment to verify that `b` is no longer created with excessive permissions. The modified program would change the last `checkout` argument from `Default::default(),` to:\n\n   ```rust\n           gix::worktree::state::checkout::Options {\n               destination_is_initially_empty: true,\n               ..Default::default()\n           },\n   ```\n\n### Impact\n\nSetting unlimited file permissions is a problem on systems where a user account exists on the system that should not have the ability to access and modify the files. That applies to multi-user systems, or when an account is used to run software with reduced abilities. (Some programs may also treat broad write permissions to mean less validation is required.)\n\nThis bug affects Unix-like systems but not Windows. The `gix clone` command is not believed to be affected, due to [`checkout_exclusive`](https://github.com/GitoxideLabs/gitoxide/blob/af704f57bb9480c47cdd393465264d586f1d4562/gitoxide-core/src/index/checkout.rs#L14-L172)\u0027s [use](https://github.com/GitoxideLabs/gitoxide/blob/af704f57bb9480c47cdd393465264d586f1d4562/gitoxide-core/src/index/checkout.rs#L61) of `destination_is_initially_empty: true`. Specialized uses in which repositories are known never to have any files marked executable are unaffected. Repositories that no untrusted users can access, due to not having the ability to traverse the directories to them or due to sufficiently restrictive ACLs, are likewise unaffected.\n\nThe default value of `destination_is_initially_empty` is `false`, so some applications may be affected even if they don\u0027t attempt checkouts in nonempty directories. The 0777 permissions are applied to files that are created earlier in the same checkout, as well as those that already existed, regardless of their prior permissions. On preexisting files, 0777 is set *even if [`overwrite_existing`](https://github.com/GitoxideLabs/gitoxide/blob/8d84818240d44e1f5fe78a231b5d9bffd0283918/gix-worktree-state/src/checkout/mod.rs#L54-L58) is `false`*, as that prevents the checkout from changing file contents but not permissions.\n\nFiles not tracked/staged as executable are not checked out with insecure permissions. Such a file that previously existed keeps its old permissions. However, this may include executable permissions that no longer match repository metadata, as well as undesired write permissions acquired from a previous vulnerable checkout. `set_mode(0o777)` clears other bits, so the bug is not exacerbated by the presence of setuid/setgid bits. In some applications, the vulnerable strategy may be used only for files rewritten by a [long running](https://git-scm.com/docs/gitattributes/2.40.0#_long_running_filter_process) smudge filter or only in the presence of [delays](https://git-scm.com/docs/gitattributes/2.40.0#_delay).",
  "id": "GHSA-fqmf-w4xh-33rh",
  "modified": "2025-01-21T21:13:06Z",
  "published": "2025-01-21T21:13:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-fqmf-w4xh-33rh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22620"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GitoxideLabs/gitoxide"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2025-0001.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gix-worktree-state nonexclusive checkout sets executable files world-writable"
}

GHSA-FR68-G2QF-53VM

Vulnerability from github – Published: 2021-11-24 00:00 – Updated: 2021-11-30 00:01
VLAI
Details

There is a Improper Preservation of Permissions vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the confidentiality of users is affected.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-37006"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-281"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-23T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "There is a Improper Preservation of Permissions vulnerability in Huawei Smartphone.Successful exploitation of this vulnerability will cause the confidentiality of users is affected.",
  "id": "GHSA-fr68-g2qf-53vm",
  "modified": "2021-11-30T00:01:01Z",
  "published": "2021-11-24T00:00:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-37006"
    },
    {
      "type": "WEB",
      "url": "https://device.harmonyos.com/cn/docs/security/update/security-bulletins-202108-0000001180965965"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

No mitigation information available for this CWE.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list