Common Weakness Enumeration

CWE-367

Allowed

Time-of-check Time-of-use (TOCTOU) Race Condition

Abstraction: Base · Status: Incomplete

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check.

1063 vulnerabilities reference this CWE, most recent first.

GHSA-3PXQ-F3CP-JMXP

Vulnerability from github – Published: 2026-03-03 21:20 – Updated: 2026-03-18 01:31

Summary

OpenClaw: Unified root-bound write hardening for browser output and related path-boundary flows

Details

Summary

A path-confinement bypass in browser output handling allowed writes outside intended roots in openclaw versions up to and including 2026.3.1.

The fix unifies root-bound, file-descriptor-verified write semantics and canonical path-boundary validation across browser output and related install/skills write paths.

Affected Packages / Versions

Package: openclaw (npm)
Latest published npm version at triage time: 2026.3.1
Affected range: <= 2026.3.1
Patched release: 2026.3.2 (released)

Fix Commit(s)

104d32bb64cdf19d5e77f70553a511a2ae90ad1c

Technical Notes

Browser output writes now use root-bound, fd/inode-verified commit flow.
Install + skills path checks now share canonical in-base validation to reduce drift and close equivalent escape surfaces.
Added regression coverage for symlink-rebind and root-bound source-path write behavior.

Severity

5.3 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22180"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T21:20:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nA path-confinement bypass in browser output handling allowed writes outside intended roots in `openclaw` versions up to and including `2026.3.1`.\n\nThe fix unifies root-bound, file-descriptor-verified write semantics and canonical path-boundary validation across browser output and related install/skills write paths.\n\n### Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version at triage time: `2026.3.1`\n- Affected range: `\u003c= 2026.3.1`\n- Patched release: `2026.3.2` (released)\n\n### Fix Commit(s)\n- `104d32bb64cdf19d5e77f70553a511a2ae90ad1c`\n\n### Technical Notes\n- Browser output writes now use root-bound, fd/inode-verified commit flow.\n- Install + skills path checks now share canonical in-base validation to reduce drift and close equivalent escape surfaces.\n- Added regression coverage for symlink-rebind and root-bound source-path write behavior.",
  "id": "GHSA-3pxq-f3cp-jmxp",
  "modified": "2026-03-18T01:31:51Z",
  "published": "2026-03-03T21:20:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-3pxq-f3cp-jmxp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/104d32bb64cdf19d5e77f70553a511a2ae90ad1c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenClaw: Unified root-bound write hardening for browser output and related path-boundary flows"
}

GHSA-3Q2P-72CJ-682C

Vulnerability from github – Published: 2026-06-12 21:07 – Updated: 2026-06-12 21:07

Summary

File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path

Details

Summary

This is similar vulnrability of CVE-2026-0035, which was fixed in Android MediaProvider with high severity. In the original Java issue, MediaStore.createWriteRequest() accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.

filebrowser/filebrowser has the analogous issue in Go. POST /api/share/<path> accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through GET /api/public/dl/<hash>.

Details

The vulnerable create path is:

http/share.go
sharePostHandler()
route: POST /api/share/<path>

sharePostHandler() only checks that the caller is authenticated and has share/download permissions. It then builds a share.Link directly from r.URL.Path and saves it:

s = &share.Link{
    Path:         r.URL.Path,
    Hash:         str,
    Expire:       expire,
    UserID:       d.user.ID,
    PasswordHash: string(hash),
    Token:        token,
}

if err := d.store.Share.Save(s); err != nil {
    return http.StatusInternalServerError, err
}

There is no Stat, Exists, or equivalent check before the public share record is committed.

The vulnerable consume path is:

http/public.go
withHashFile()
routes: GET /api/public/share/<hash>, GET /api/public/dl/<hash>

Each public request loads the saved share by hash and then resolves link.Path against the owner's current filesystem state:

file, err := files.NewFileInfo(&files.FileOptions{
    Fs:   d.user.Fs,
    Path: link.Path,
    ...
})

This means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.

PoC

The PoC below starts from external HTTP input only.

Authenticate to File Browser.
Confirm /future4.txt does not exist.
Create a public share for /future4.txt anyway.
Confirm the public share returns 404.
Upload a file to /future4.txt.
Reuse the same public share URL and read the file content.

Reproduction commands:

TOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"Password123!"}')

curl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \
  -H "X-Auth: $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{}'

curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO

curl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \
  -H "X-Auth: $TOKEN" \
  --data-binary 'fourth-secret'

curl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO

Impact

An authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.

Reference

Original CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.63.6"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.63.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T21:07:55Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nThis is similar vulnrability of **`CVE-2026-0035`**, which was fixed in Android `MediaProvider` with **high** severity. In the original Java issue, `MediaStore.createWriteRequest()` accepted attacker-controlled URIs and created a future grant even when the referenced media item did not exist yet. The Android fix added an existence check before creating the request.\n\n`filebrowser/filebrowser` has the analogous issue in Go. `POST /api/share/\u003cpath\u003e` accepts an authenticated request for an arbitrary path and stores a public share record without checking whether the target file currently exists. Later, when a file is created at that same path, the previously created public share immediately becomes valid and exposes the new file through `GET /api/public/dl/\u003chash\u003e`.\n\n### Details\nThe vulnerable create path is:\n\n- `http/share.go`\n- `sharePostHandler()`\n- route: `POST /api/share/\u003cpath\u003e`\n\n`sharePostHandler()` only checks that the caller is authenticated and has share/download permissions. It then builds a `share.Link` directly from `r.URL.Path` and saves it:\n\n```go\ns = \u0026share.Link{\n    Path:         r.URL.Path,\n    Hash:         str,\n    Expire:       expire,\n    UserID:       d.user.ID,\n    PasswordHash: string(hash),\n    Token:        token,\n}\n\nif err := d.store.Share.Save(s); err != nil {\n    return http.StatusInternalServerError, err\n}\n```\n\nThere is no `Stat`, `Exists`, or equivalent check before the public share record is committed.\n\nThe vulnerable consume path is:\n\n- `http/public.go`\n- `withHashFile()`\n- routes: `GET /api/public/share/\u003chash\u003e`, `GET /api/public/dl/\u003chash\u003e`\n\nEach public request loads the saved share by hash and then resolves `link.Path` against the owner\u0027s current filesystem state:\n\n```go\nfile, err := files.NewFileInfo(\u0026files.FileOptions{\n    Fs:   d.user.Fs,\n    Path: link.Path,\n    ...\n})\n```\n\nThis means the share is not bound to an object that existed at creation time. It is bound only to a path string, so a share created for a nonexistent path becomes valid later as soon as that path is populated.\n\n\n### PoC\nThe PoC below starts from external HTTP input only.\n\n1. Authenticate to File Browser.\n2. Confirm `/future4.txt` does not exist.\n3. Create a public share for `/future4.txt` anyway.\n4. Confirm the public share returns `404`.\n5. Upload a file to `/future4.txt`.\n6. Reuse the same public share URL and read the file content.\n\nReproduction commands:\n\n```bash\nTOKEN=$(curl -s -X POST http://127.0.0.1:8091/api/login \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"username\":\"admin\",\"password\":\"Password123!\"}\u0027)\n\ncurl -i -X POST http://127.0.0.1:8091/api/share/future4.txt \\\n  -H \"X-Auth: $TOKEN\" \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{}\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n\ncurl -i -X POST http://127.0.0.1:8091/api/resources/future4.txt \\\n  -H \"X-Auth: $TOKEN\" \\\n  --data-binary \u0027fourth-secret\u0027\n\ncurl -i http://127.0.0.1:8091/api/public/dl/JVeEQlLO\n```\n\n\n### Impact\nAn authenticated user can create a public share for a path before the file exists, and that same share later exposes whatever file is created at that path. This can unintentionally publish future sensitive files and bypass the expected invariant that a share grants access only to an existing object reviewed at creation time.\n\n### Reference\n\nOriginal CVE: https://nvd.nist.gov/vuln/detail/CVE-2026-0035",
  "id": "GHSA-3q2p-72cj-682c",
  "modified": "2026-06-12T21:07:55Z",
  "published": "2026-06-12T21:07:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-3q2p-72cj-682c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/commit/166583db632e088e9f0adce30aec43bb9d9019f4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser: Improper Access Control Occurs via Pre-Created Public Share for a Non-existent Path"
}

GHSA-3R66-J4HR-JMXJ

Vulnerability from github – Published: 2026-06-09 15:32 – Updated: 2026-06-09 15:32

Details

A vulnerability in the quarantine and restore workflow of the X-VPN macOS website versions 77.0 through 77.5 allow a local attacker to leverage a race condition and symlink manipulation to achieve privileged file corruption.

Severity

7.3 (High)


                  
                    CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-2638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T13:16:35Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the quarantine and restore workflow of the X-VPN macOS website versions 77.0 through 77.5 allow a local attacker to leverage a race condition and symlink manipulation to achieve privileged file corruption.",
  "id": "GHSA-3r66-j4hr-jmxj",
  "modified": "2026-06-09T15:32:17Z",
  "published": "2026-06-09T15:32:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2638"
    },
    {
      "type": "WEB",
      "url": "https://fluidattacks.com/es/advisories/soad"
    },
    {
      "type": "WEB",
      "url": "https://xvpn.io"
    },
    {
      "type": "WEB",
      "url": "https://xvpn.io/download/vpn-mac"
    },
    {
      "type": "WEB",
      "url": "https://xvpn.io/resources/statement-local-privilege-escalation-vulnerability"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-3V2R-C9X3-5FGR

Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-30 03:37

Details

In the Linux kernel, the following vulnerability has been resolved:

sched/psi: fix race between file release and pressure write

A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1].

Consider the following scenario involving execution on two separate CPUs:

CPU0 CPU1 ==== ==== vfs_rmdir() kernfs_iop_rmdir() cgroup_rmdir() cgroup_kn_lock_live() cgroup_destroy_locked() cgroup_addrm_files() cgroup_rm_file() kernfs_remove_by_name() kernfs_remove_by_name_ns() vfs_write() __kernfs_remove() new_sync_write() kernfs_drain() kernfs_fop_write_iter() kernfs_drain_open_files() cgroup_file_write() kernfs_release_file() pressure_write() cgroup_file_release() ctx = of->priv; kfree(ctx); of->priv = NULL; cgroup_kn_unlock() cgroup_kn_lock_live() cgroup_get(cgrp) cgroup_kn_unlock() if (ctx->psi.trigger) // here, trigger uaf for ctx, that is of->priv

The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered.

Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write().

And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point after the live kn lock has been successfully acquired.

In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition:

CPU0: write memory.pressure CPU1: write cgroup.pressure=0 =========================== =============================

kernfs_fop_write_iter() kernfs_get_active_of(of) pressure_write() cgroup_kn_lock_live(memory.pressure) cgroup_tryget(cgrp) kernfs_break_active_protection(kn) ... blocks on cgroup_mutex

                                      cgroup_pressure_write()
                                      cgroup_kn_lock_live(cgroup.pressure)
                                      cgroup_file_show(memory.pressure, false)
                                        kernfs_show(false)
                                          kernfs_drain_open_files()
                                            cgroup_file_release(of)
                                              kfree(ctx)
                                                of->priv = NULL
                                      cgroup_kn_unlock()

... acquires cgroup_mutex ctx = of->priv; // may now be NULL if (ctx->psi.trigger) // NULL dereference

Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.

Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.

[1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace: pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---

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

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-52991"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-24T17:17:09Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/psi: fix race between file release and pressure write\n\nA potential race condition exists between pressure write and cgroup file\nrelease regarding the priv member of struct kernfs_open_file, which\ntriggers the uaf reported in [1].\n\nConsider the following scenario involving execution on two separate CPUs:\n\n   CPU0\t\t\t\t\tCPU1\n   ====\t\t\t\t\t====\n\t\t\t\t\tvfs_rmdir()\n\t\t\t\t\tkernfs_iop_rmdir()\n\t\t\t\t\tcgroup_rmdir()\n\t\t\t\t\tcgroup_kn_lock_live()\n\t\t\t\t\tcgroup_destroy_locked()\n\t\t\t\t\tcgroup_addrm_files()\n\t\t\t\t\tcgroup_rm_file()\n\t\t\t\t\tkernfs_remove_by_name()\n\t\t\t\t\tkernfs_remove_by_name_ns()\n vfs_write()\t\t\t\t__kernfs_remove()\n new_sync_write()\t\t\tkernfs_drain()\n kernfs_fop_write_iter()\t\tkernfs_drain_open_files()\n cgroup_file_write()\t\t\tkernfs_release_file()\n pressure_write()\t\t\tcgroup_file_release()\n ctx = of-\u003epriv;\n\t\t\t\t\tkfree(ctx);\n \t\t\t\t\tof-\u003epriv = NULL;\n\t\t\t\t\tcgroup_kn_unlock()\n cgroup_kn_lock_live()\n cgroup_get(cgrp)\n cgroup_kn_unlock()\n if (ctx-\u003epsi.trigger)  // here, trigger uaf for ctx, that is of-\u003epriv\n\nThe cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards\nthe memory deallocation of of-\u003epriv performed within cgroup_file_release().\nHowever, the operations involving of-\u003epriv executed within pressure_write()\nare not entirely covered by the protection of cgroup_mutex. Consequently,\nif the code in pressure_write(), specifically the section handling the\nctx variable executes after cgroup_file_release() has completed, a uaf\nvulnerability involving of-\u003epriv is triggered.\n\nTherefore, the issue can be resolved by extending the scope of the\ncgroup_mutex lock within pressure_write() to encompass all code paths\ninvolving of-\u003epriv, thereby properly synchronizing the race condition\noccurring between cgroup_file_release() and pressure_write().\n\nAnd, if an live kn lock can be successfully acquired while executing\nthe pressure write operation, it indicates that the cgroup deletion\nprocess has not yet reached its final stage; consequently, the priv\npointer within open_file cannot be NULL. Therefore, the operation to\nretrieve the ctx value must be moved to a point *after* the live kn\nlock has been successfully acquired.\n\nIn another situation, specifically after entering cgroup_kn_lock_live()\nbut before acquiring cgroup_mutex, there exists a different class of\nrace condition:\n\nCPU0: write memory.pressure               CPU1: write cgroup.pressure=0\n===========================\t\t  =============================\n\nkernfs_fop_write_iter()\n kernfs_get_active_of(of)\n pressure_write()\n   cgroup_kn_lock_live(memory.pressure)\n     cgroup_tryget(cgrp)\n     kernfs_break_active_protection(kn)\n     ... blocks on cgroup_mutex\n\n                                     \t  cgroup_pressure_write()\n                                     \t  cgroup_kn_lock_live(cgroup.pressure)\n                                     \t  cgroup_file_show(memory.pressure, false)\n                                     \t    kernfs_show(false)\n                                     \t      kernfs_drain_open_files()\n                                     \t        cgroup_file_release(of)\n                                     \t          kfree(ctx)\n                                     \t            of-\u003epriv = NULL\n                                     \t  cgroup_kn_unlock()\n\n   ... acquires cgroup_mutex\n   ctx = of-\u003epriv;        // may now be NULL\n   if (ctx-\u003epsi.trigger)  // NULL dereference\n\nConsequently, there is a possibility that of-\u003epriv is NULL, the pressure\nwrite needs to check for this.\n\nNow that the scope of the cgroup_mutex has been expanded, the original\nexplicit cgroup_get/put operations are no longer necessary, this is\nbecause acquiring/releasing the live kn lock inherently executes a\ncgroup get/put operation.\n\n[1]\nBUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\nCall Trace:\n pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011\n cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43\n---truncated---",
  "id": "GHSA-3v2r-c9x3-5fgr",
  "modified": "2026-06-30T03:37:13Z",
  "published": "2026-06-24T18:32:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52991"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-52991"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492403"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/03dc070fa0fc3cb4068693f468ccd5f8a7e58282"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a5b98009f16d8a5fb4a8ff9a193f5735515c38fa"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d4352c0709bfd38c752fccbde7fd72a82ac78f23"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-52991.json"
    }
  ],
  "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-3W2F-J9R3-9H89

Vulnerability from github – Published: 2023-07-11 18:31 – Updated: 2025-10-22 00:32

Details

Microsoft Outlook Security Feature Bypass Vulnerability

Severity

8.8 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-35311"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-11T18:15:17Z",
    "severity": "HIGH"
  },
  "details": "Microsoft Outlook Security Feature Bypass Vulnerability",
  "id": "GHSA-3w2f-j9r3-9h89",
  "modified": "2025-10-22T00:32:44Z",
  "published": "2023-07-11T18:31:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35311"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-35311"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-35311"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3X52-FW35-W3MF

Vulnerability from github – Published: 2024-07-15 18:31 – Updated: 2024-07-15 18:31

Details

Race condition in the installer for Zoom Workplace App for Windows and Zoom Rooms App for Windows may allow an authenticated user to conduct a denial of service via local access.

Severity

6.6 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-39821"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-15T18:15:04Z",
    "severity": "MODERATE"
  },
  "details": "Race condition in the installer for Zoom Workplace App for Windows and Zoom Rooms App for Windows may allow an authenticated user to conduct a denial of service via local access.",
  "id": "GHSA-3x52-fw35-w3mf",
  "modified": "2024-07-15T18:31:16Z",
  "published": "2024-07-15T18:31:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39821"
    },
    {
      "type": "WEB",
      "url": "https://www.zoom.com/en/trust/security-bulletin/zsb-24028"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3X5M-G386-PXWQ

Vulnerability from github – Published: 2022-05-17 00:48 – Updated: 2022-05-17 00:48

Details

fts.c in coreutils 8.4 allows local users to delete arbitrary files.

Severity

4.7 (Medium)


                  
                    CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2015-1865"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-362",
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-20T18:29:00Z",
    "severity": "MODERATE"
  },
  "details": "fts.c in coreutils 8.4 allows local users to delete arbitrary files.",
  "id": "GHSA-3x5m-g386-pxwq",
  "modified": "2022-05-17T00:48:03Z",
  "published": "2022-05-17T00:48:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-1865"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1211300"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/76073"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3XM8-389P-X4RM

Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2026-07-14 15:31

Details

In the Linux kernel, the following vulnerability has been resolved:

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata()

But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point.

In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst:

Quiescence

After the ndo_stop routine has been called, the hardware must
not receive or transmit any data. All in flight packets must
be aborted. If necessary, poll or wait for completion of
any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit.

The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).

Severity

4.7 (Medium)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-49998"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-21T18:15:19Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: improve shutdown sequence\n\nAlexander Sverdlin presents 2 problems during shutdown with the\nlan9303 driver. One is specific to lan9303 and the other just happens\nto reproduce there.\n\nThe first problem is that lan9303 is unique among DSA drivers in that it\ncalls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown,\nnot remove):\n\nphy_state_machine()\n-\u003e ...\n   -\u003e dsa_user_phy_read()\n      -\u003e ds-\u003eops-\u003ephy_read()\n         -\u003e lan9303_phy_read()\n            -\u003e chip-\u003eops-\u003ephy_read()\n               -\u003e lan9303_mdio_phy_read()\n                  -\u003e dev_get_drvdata()\n\nBut we never stop the phy_state_machine(), so it may continue to run\nafter dsa_switch_shutdown(). Our common pattern in all DSA drivers is\nto set drvdata to NULL to suppress the remove() method that may come\nafterwards. But in this case it will result in an NPD.\n\nThe second problem is that the way in which we set\ndp-\u003econduit-\u003edsa_ptr = NULL; is concurrent with receive packet\nprocessing. dsa_switch_rcv() checks once whether dev-\u003edsa_ptr is NULL,\nbut afterwards, rather than continuing to use that non-NULL value,\ndev-\u003edsa_ptr is dereferenced again and again without NULL checks:\ndsa_conduit_find_user() and many other places. In between dereferences,\nthere is no locking to ensure that what was valid once continues to be\nvalid.\n\nBoth problems have the common aspect that closing the conduit interface\nsolves them.\n\nIn the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN\nevent in dsa_user_netdevice_event() which closes user ports as well.\ndsa_port_disable_rt() calls phylink_stop(), which synchronously stops\nthe phylink state machine, and ds-\u003eops-\u003ephy_read() will thus no longer\ncall into the driver after this point.\n\nIn the second case, dev_close(conduit) should do this, as per\nDocumentation/networking/driver.rst:\n\n| Quiescence\n| ----------\n|\n| After the ndo_stop routine has been called, the hardware must\n| not receive or transmit any data.  All in flight packets must\n| be aborted. If necessary, poll or wait for completion of\n| any reset commands.\n\nSo it should be sufficient to ensure that later, when we zeroize\nconduit-\u003edsa_ptr, there will be no concurrent dsa_switch_rcv() call\non this conduit.\n\nThe addition of the netif_device_detach() function is to ensure that\nioctls, rtnetlinks and ethtool requests on the user ports no longer\npropagate down to the driver - we\u0027re no longer prepared to handle them.\n\nThe race condition actually did not exist when commit 0650bf52b31f\n(\"net: dsa: be compatible with masters which unregister on shutdown\")\nfirst introduced dsa_switch_shutdown(). It was created later, when we\nstopped unregistering the user interfaces from a bad spot, and we just\nreplaced that sequence with a racy zeroization of conduit-\u003edsa_ptr\n(one which doesn\u0027t ensure that the interfaces aren\u0027t up).",
  "id": "GHSA-3xm8-389p-x4rm",
  "modified": "2026-07-14T15:31:15Z",
  "published": "2024-10-21T18:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49998"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2e93bf719462ac6d23c881c8b93e5dc9bf5ab7f5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6c24a03a61a245fe34d47582898331fa034b6ccd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/87bd909a7014e32790e8c759d5b7694a95778ca5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab5d3420a1120950703dbdc33698b28a6ebc3d23"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab9e90619b6339becc5415647ae154a9a46a044d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b4a65d479213fe84ecb14e328271251eebe69492"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-42MR-8VJ5-9J9X

Vulnerability from github – Published: 2022-11-15 12:00 – Updated: 2022-11-18 00:30

Details

DMA transactions which are targeted at input buffers used for the SdMmcDevice software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the SdMmcDevice driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel's iSTARE group. This was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022054

Severity

7.0 (High)


                  
                    CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-33984"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-15T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "DMA transactions which are targeted at input buffers used for the SdMmcDevice software SMI handler could cause SMRAM corruption through a TOCTOU attack. DMA transactions which are targeted at input buffers used for the software SMI handler used by the SdMmcDevice driver could cause SMRAM corruption through a TOCTOU attack. This issue was discovered by Insyde engineering based on the general description provided by Intel\u0027s iSTARE group. This was fixed in kernel 5.2: 05.27.25, kernel 5.3: 05.36.25, kernel 5.4: 05.44.25, kernel 5.5: 05.52.25 https://www.insyde.com/security-pledge/SA-2022054",
  "id": "GHSA-42mr-8vj5-9j9x",
  "modified": "2022-11-18T00:30:19Z",
  "published": "2022-11-15T12:00:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-33984"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-450613.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge"
    },
    {
      "type": "WEB",
      "url": "https://www.insyde.com/security-pledge/SA-2022054"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-442J-39WM-28R2

Vulnerability from github – Published: 2026-03-29 15:16 – Updated: 2026-03-29 15:16

Summary

Handlebars.js has a Property Access Validation Bypass in container.lookup

Details

Summary

In lib/handlebars/runtime.js, the container.lookup() function uses container.lookupProperty() as a gate check to enforce prototype-access controls, but then discards the validated result and performs a second, unguarded property access (depths[i][name]). This Time-of-Check Time-of-Use (TOCTOU) pattern means the security check and the actual read are decoupled, and the raw access bypasses any sanitization that lookupProperty may perform.

Only relevant when the compat compile option is enabled ({compat: true}), which activates depthedLookup in lib/handlebars/compiler/javascript-compiler.js.

Description

The vulnerable code in lib/handlebars/runtime.js (lines 137–144):

lookup: function (depths, name) {
  const len = depths.length;
  for (let i = 0; i < len; i++) {
    let result = depths[i] && container.lookupProperty(depths[i], name);
    if (result != null) {
      return depths[i][name];  // BUG: should be `return result;`
    }
  }
},

container.lookupProperty() (lines 119–136) enforces hasOwnProperty checks and resultIsAllowed() prototype-access controls. However, container.lookup() only uses lookupProperty as a boolean gate — if the gate passes (result != null), it then performs an independent, raw depths[i][name] access that circumvents any transformation or wrapped value that lookupProperty may have returned.

Workarounds

Avoid enabling { compat: true } when rendering templates that include untrusted data.
Ensure context data objects are plain JSON (no Proxies, no getter-based accessor properties).

Severity

3.7 (Low)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.7.8"
      },
      "package": {
        "ecosystem": "npm",
        "name": "handlebars"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.7.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-367"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-29T15:16:37Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\nIn `lib/handlebars/runtime.js`, the `container.lookup()` function uses `container.lookupProperty()` as a gate check to enforce prototype-access controls, but then discards the validated result and performs a second, unguarded property access (`depths[i][name]`). This Time-of-Check Time-of-Use (TOCTOU) pattern means the security check and the actual read are decoupled, and the raw access bypasses any sanitization that `lookupProperty` may perform.\n\nOnly relevant when the **compat** compile option is enabled (`{compat: true}`), which activates `depthedLookup` in `lib/handlebars/compiler/javascript-compiler.js`.\n\n## Description\n\nThe vulnerable code in `lib/handlebars/runtime.js` (lines 137\u2013144):\n\n```javascript\nlookup: function (depths, name) {\n  const len = depths.length;\n  for (let i = 0; i \u003c len; i++) {\n    let result = depths[i] \u0026\u0026 container.lookupProperty(depths[i], name);\n    if (result != null) {\n      return depths[i][name];  // BUG: should be `return result;`\n    }\n  }\n},\n```\n\n`container.lookupProperty()` (lines 119\u2013136) enforces `hasOwnProperty` checks and `resultIsAllowed()` prototype-access controls. However, `container.lookup()` only uses `lookupProperty` as a boolean gate \u2014 if the gate passes (`result != null`), it then performs an independent, raw `depths[i][name]` access that circumvents any transformation or wrapped value that `lookupProperty` may have returned.\n\n## Workarounds\n\n- Avoid enabling `{ compat: true }` when rendering templates that include untrusted data.\n- Ensure context data objects are plain JSON (no Proxies, no getter-based accessor properties).",
  "id": "GHSA-442j-39wm-28r2",
  "modified": "2026-03-29T15:16:37Z",
  "published": "2026-03-29T15:16:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/security/advisories/GHSA-442j-39wm-28r2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/commit/68d8df5a88e0a26fe9e6084c5c6aaebe67b07da2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/handlebars-lang/handlebars.js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/handlebars-lang/handlebars.js/releases/tag/v4.7.9"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Handlebars.js has a Property Access Validation Bypass in container.lookup"
}

Mitigation

Implementation

The most basic advice for TOCTOU vulnerabilities is to not perform a check before the use. This does not resolve the underlying issue of the execution of a function on a resource whose state and identity cannot be assured, but it does help to limit the false sense of security given by the check.

Mitigation

Implementation

When the file being altered is owned by the current user and group, set the effective gid and uid to that of the current user and group when executing this statement.

Mitigation

Architecture and Design

Limit the interleaving of operations on files from multiple processes.

Mitigation

Implementation Architecture and Design

If you cannot perform operations atomically and you must share access to the resource between multiple processes or threads, then try to limit the amount of time (CPU cycles) between the check and use of the resource. This will not fix the problem, but it could make it more difficult for an attack to succeed.

Mitigation

Implementation

Recheck the resource after the use call to verify that the action was taken appropriately.

Mitigation

Architecture and Design

Ensure that some environmental locking mechanism can be used to protect resources effectively.

Mitigation

Implementation

Ensure that locking occurs before the check, as opposed to afterwards, such that the resource, as checked, is the same as it is when in use.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.

← Back to the CWE list