CWE-73

{
  "affected": [],
  "aliases": [
    "CVE-2024-55371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-16T21:15:45Z",
    "severity": "CRITICAL"
  },
  "details": "Wallos \u003c= 2.38.2 has a file upload vulnerability in the restore backup function, which allows authenticated users to restore backups by uploading a ZIP file. The contents of the ZIP file are extracted on the server. This functionality enables an authenticated attacker (being an administrator is not required) to upload malicious files to the server. Once a web shell is installed, the attacker gains the ability to execute arbitrary commands.",
  "id": "GHSA-mp2g-3625-m5pp",
  "modified": "2025-04-17T15:32:34Z",
  "published": "2025-04-16T21:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55371"
    },
    {
      "type": "WEB",
      "url": "https://www.datafarm.co.th/blog/CVE-2024-55371-and-CVE-2024-55372-Malicious-File-Upload-to-RCE-in-Wallos-Application"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:email-ext"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1933.1935.v276319e3cc47"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T19:42:14Z",
    "nvd_published_at": "2026-05-27T15:16:31Z",
    "severity": "HIGH"
  },
  "details": "Jenkins Email Extension Plugin 1933.v45cec755423f and earlier includes a feature that allows inlining images as `base64` in email content by setting the `data-inline` attribute. No restrictions are placed on the image URLs that can be inlined.\n\nThis allows attackers able to control the email content to specify `file:` URLs for images to read arbitrary files from the Jenkins controller filesystem.\n\nThe feature allowing inlining images as `base64` in email content by setting the `data-inline` attribute is removed from Email Extension Plugin 1933.1935.v276319e3cc47.",
  "id": "GHSA-mq58-m26g-46gp",
  "modified": "2026-07-01T19:42:14Z",
  "published": "2026-05-27T15:33:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-48920"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/email-ext-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2026-05-27/#SECURITY-3705"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Email Extension Plugin: Attackers able to control email content may specify `file:` URLs for images to read arbitrary files from Jenkins controller filesystem"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.12.4"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "apm-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.13.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46383"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-15T18:25:34Z",
    "nvd_published_at": "2026-05-15T17:16:49Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nMicrosoft APM contains a Windows-specific archive extraction boundary failure in the legacy-bundle probe used by `apm install \u003cbundle\u003e` on supported Python 3.10 and 3.11 runtimes. When `apm install` is given a local `.tar.gz` that is not recognized as a plugin-format bundle, APM probes whether it is a legacy `--format apm` bundle. On Python versions earlier than 3.12, that probe extracts untrusted tar members with raw `tar.extractall()` without rejecting Windows absolute member names such as `D:/...`.\n\nThis issue is still present on the latest `main` commit at review time (`2b7a931d58a73cbfc0bcf086cea332d204075e27`) and on the latest release (`v0.12.4`). In both cases, a crafted legacy-looking tarball caused an external file to be created or overwritten outside the temporary extraction root before `apm install` finished rejecting the bundle with the expected legacy-format usage error.\n\nThis report is scoped narrowly to Windows installations running Python 3.10 or 3.11.\n\n### Details\n\nThe broken trust boundary is the boundary between an untrusted local bundle artifact and the host filesystem state that APM is allowed to modify while probing that artifact. The attacker-controlled input is the tar member name inside the `.tar.gz` bundle. A crafted archive can include a member whose name is a Windows absolute path such as `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`.\n\nThe current install caller path still reaches the legacy probe for `.tar.gz` inputs that are not recognized as plugin-format bundles. In `src/apm_cli/commands/install.py`, the local-bundle branch first calls `detect_local_bundle()`. If the path exists, is a tarball, and is not recognized as a plugin-format bundle, the caller still invokes `_looks_like_legacy_apm_bundle()` to distinguish a legacy bundle from an arbitrary tarball and to choose the error message.\n\nThe root cause is in `src/apm_cli/bundle/local_bundle.py`. `_looks_like_legacy_apm_bundle()`:\n\n- opens the tarball,\n- rejects only symlink and hardlink members,\n- and on Python versions earlier than 3.12 calls raw `tar.extractall(tmp)`.\n\nThat helper does not reject Windows absolute member names and does not perform the Windows-aware containment checks already present elsewhere in the same module.\n\nThis is particularly clear because the adjacent `detect_local_bundle()` path in the same file already contains safer pre-extraction validation. It rejects:\n\n- `PureWindowsPath(name).drive`\n- `PureWindowsPath(name).is_absolute()`\n- path traversal via `validate_path_segments(...)`\n\nThat safer validation is not reused by `_looks_like_legacy_apm_bundle()`.\n\nOn Python versions earlier than 3.12, `_looks_like_legacy_apm_bundle()` performs extraction before legacy-format rejection is raised, so archive member names become filesystem writes during bundle classification rather than during an accepted install step. The write occurs before command rejection because the legacy probe must extract the tarball in order to look for `apm.lock.yaml` at the bundle root and confirm that `plugin.json` is absent. As a result, the out-of-root write happens during classification, before the caller raises the legacy-format usage error.\n\nThe issue is not limited to creating new files. On both latest `main` and latest release, the same vulnerable path overwrote an already-existing writable target file with attacker-controlled contents before the command finished legacy-format rejection. It was further verified the same overwrite primitive against a pre-existing project workflow file at `.github/workflows/ci.yml`, replacing its YAML contents before rejection.\n\nThis is a security issue rather than intended package-manager behavior. The user is asking APM to inspect or install a local bundle. The expected behavior is that bundle contents are handled within the extraction sandbox used for that operation. Writing to an arbitrary host path outside the extraction root during pre-install probing is not part of expected local-bundle behavior, and it happens even when APM ultimately rejects the tarball.\n\nThis issue is also distinct from the prior public APM plugin path-escape issue. The prior public issue involved manifest-controlled path escape during plugin normalization in `plugin_parser.py`, where attacker-controlled manifest entries were resolved outside the plugin root during install. This issue is different in input, timing, and code path: it is an archive-member extraction bug in `src/apm_cli/bundle/local_bundle.py` during legacy-bundle probing, before bundle classification completes and before `apm install` rejects the bundle. No manifest processing is required to trigger it.\n\nAs additional same-family scope information, the same Windows absolute-path extraction weakness is also reproducible in apm unpack.In `src/apm_cli/bundle/unpacker.py`, the unpacker rejects `/` and `..` but still misses Windows absolute tar member names before calling `tar.extractall()` on Python versions earlier than 3.12. Because `apm unpack` is deprecated, I am not presenting it as a second standalone vulnerability title; I am including it only as additional affected surface from the same validation family.\n\n### PoC\n\nValidation environment used for the included proof:\n\n- Windows 11 Pro\n- Python 3.11.9 x64\n- Latest `main` commit: `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- Latest release commit: `6aceef72be490a9c716547f600a2659f3f2826b7` (`v0.12.4`)\n\nMinimal malicious archive contents:\n\n- `bundle/apm.lock.yaml`\n- `D:/apm/run-main-install/outside/legacy-probe-outside-main.txt`\n\nThe first member makes the archive look like a legacy APM bundle. The second member proves the out-of-root write. The outside target path must be writable by the user running APM. The proof uses a user-controlled directory for that reason.\n\nOne straightforward way to build this input is to use Python\u0027s `tarfile` module directly and add:\n\n- `bundle/apm.lock.yaml`\n- `TarInfo(\"D:/apm/run-main-install/outside/legacy-probe-outside-main.txt\")`\n\nwith file content such as:\n\n```text\noutside write via install main\n```\n\nReproduction steps for latest `main`:\n\n1. Check out `microsoft/apm` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`.\n2. Use a real Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the checked-out tree.\n4. Create the malicious legacy-looking tarball described above.\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\n```\n\nExpected safe behavior:\n\n- APM rejects the tarball without creating or overwriting any host file outside the temporary extraction root.\n\nObserved result on latest `main`:\n\n- the import path resolved to the checked-out `main` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-main-install\\outside\\legacy-probe-outside-main.txt\n```\n\nThe file contained:\n\n```text\noutside write via install main\n```\n\nI also verified overwrite, not just creation, by pre-creating a writable target file and then running the same install path. The existing file contents changed from `ORIGINAL-MAIN` to `OVERWRITTEN-MAIN` before rejection.\n\nI further verified overwrite of a pre-existing project workflow file. Before the run, the target file contained:\n\n```yaml\nname: safe\non: [push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo safe\n```\n\nAfter the run, the same file contained attacker-controlled replacement YAML:\n\n```yaml\nname: overwritten\non: [push]\njobs:\n  build:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo overwritten-by-archive\n```\n\nObserved command output on latest `main`:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-main-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nReproduction steps for latest release `v0.12.4`:\n\n1. Check out tag `v0.12.4` / commit `6aceef72be490a9c716547f600a2659f3f2826b7`.\n2. Use the same Windows Python 3.11 runtime.\n3. Ensure the `apm_cli` import resolves to the `v0.12.4` tree.\n4. Create the same malicious tarball shape, for example with:\n\n```text\nD:/apm/run-release-install/outside/legacy-probe-outside-release.txt\n```\n\n5. Run:\n\n```powershell\npython -m apm_cli.cli install D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\n```\n\nObserved result on latest release:\n\n- the import path resolved to the checked-out `v0.12.4` tree,\n- the command ended with the expected legacy-format rejection,\n- the process exit code was `2`,\n- and the file below had already been created outside the temporary extraction root:\n\n```text\nD:\\apm\\run-release-install\\outside\\legacy-probe-outside-release.txt\n```\n\nThe file contained:\n\n```text\noutside write via install release\n```\n\nI also verified overwrite, not just creation, on the latest release by pre-creating a writable target file. The existing file contents changed from `ORIGINAL-RELEASE` to `OVERWRITTEN-RELEASE` before rejection. The same workflow-file overwrite pattern was also reproducible on the latest release.\n\nObserved command output on latest release:\n\n```text\n[!] Install interrupted after 0.0s.\nUsage: python -m apm_cli.cli install [OPTIONS] [PACKAGES]...\nTry \u0027python -m apm_cli.cli install --help\u0027 for help.\n\nError: \u0027D:\\apm\\run-release-install\\input\\legacy-bundle.tar.gz\u0027 was packed with \u0027--format apm\u0027 (legacy format). \u0027apm install \u003cbundle\u003e\u0027 requires the plugin format. Repack with \u0027apm pack --format plugin --archive\u0027, or use \u0027apm unpack\u0027 to deploy the legacy bundle.\n```\n\nAdditional same-family affected surface:\n\n- `apm unpack` on latest `main` and latest release also created an outside file when given a tarball containing a Windows absolute member name.\n- In that path the command completed successfully with exit code `0`, which further confirms that the Windows absolute-path validation gap is present outside the primary install probe as well.\n\n### Impact\n\nThis is an arbitrary local file overwrite outside the intended extraction root during a current APM install path. The impacted population is Windows users running APM on supported Python 3.10 or 3.11 runtimes. The attacker capability required is the ability to supply a crafted local bundle and induce the victim to run `apm install` on it.\n\nThe strongest demonstrated real-world consequence is attacker-controlled overwrite of an existing writable file at an attacker-selected Windows path outside the extraction root, using the privileges of the user running APM. An overwrite of a project-controlled GitHub Actions workflow file with attacker-controlled YAML before rejection was verified.  Workflow execution from this report hasn\u0027t been claimed; the demonstrated consequence is high-integrity modification of a trusted automation file outside the intended extraction boundary.\n\nThe issue is currently reachable on:\n\n- latest `main` at `2b7a931d58a73cbfc0bcf086cea332d204075e27`\n- latest release `v0.12.4`\n\n### Mitigation\n\n1. Reuse the existing pre-extraction validation already implemented in `detect_local_bundle()` for `_looks_like_legacy_apm_bundle()`.\n2. Reject Windows absolute member names before any extraction step.\n3. Apply equivalent Windows absolute-path validation to the unpacker in `src/apm_cli/bundle/unpacker.py`.\n4. Add regression tests for:\n   - Windows absolute member paths in the legacy-bundle probe path\n   - Windows absolute member paths in the unpack path\n   - confirmation that no host write occurs before the legacy-format rejection is raised\n\n### Attachment\n[apm-legacy-probe-windows-absolute-path-write-20260511.zip](https://github.com/user-attachments/files/27578792/apm-legacy-probe-windows-absolute-path-write-20260511.zip)",
  "id": "GHSA-mq5j-pw29-jcv3",
  "modified": "2026-05-15T23:50:07Z",
  "published": "2026-05-15T18:25:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/apm/security/advisories/GHSA-mq5j-pw29-jcv3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46383"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/apm/commit/77d1dda8303c8d7ccb6148788a6274fdece98499"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/microsoft/apm"
    },
    {
      "type": "WEB",
      "url": "https://github.com/microsoft/apm/releases/tag/v0.13.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Microsoft APM: Windows absolute-path tar member overwrite during legacy-bundle probing in `apm install`"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-47956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-06-10T17:24:06Z",
    "severity": "MODERATE"
  },
  "details": "External control of file name or path in Windows Security App allows an authorized attacker to perform spoofing locally.",
  "id": "GHSA-mq97-x574-83g4",
  "modified": "2025-06-10T18:32:31Z",
  "published": "2025-06-10T18:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47956"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-47956"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2021-47871"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-21T18:16:20Z",
    "severity": "HIGH"
  },
  "details": "Hestia Control Panel 1.3.2 contains an arbitrary file write vulnerability that allows authenticated attackers to write files to arbitrary locations using the API index.php endpoint. Attackers can exploit the v-make-tmp-file command to write SSH keys or other content to specific file paths on the server.",
  "id": "GHSA-mq9q-3qrm-9f7q",
  "modified": "2026-01-21T18:30:31Z",
  "published": "2026-01-21T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47871"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hestiacp/hestiacp"
    },
    {
      "type": "WEB",
      "url": "https://hestiacp.com"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/49667"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/hestia-control-panel-arbitrary-file-write"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.4.7"
            },
            {
              "fixed": "2026.4.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41389"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T22:33:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nWebchat tool-result media normalization could pass local and UNC-style file paths into the host-side media embedding path without applying the configured local-root containment policy.\n\n## Impact\n\nA crafted tool-result media reference could cause the host to attempt local file reads or Windows UNC/network path access while preparing webchat media blocks. This could disclose allowed host files or trigger network credential exposure on affected Windows deployments. Severity remains medium because exploitation depends on a tool-result media path reaching the webchat embedding path, but the sink is a host-side file read before the user sees the rendered result.\n\n## Affected versions\n\n- Affected: `\u003e= 2026.4.7, \u003c 2026.4.15`\n- Patched: `2026.4.15`\n\n## Fix\n\nOpenClaw `2026.4.15` hardens the webchat media path and the shared media resolver. Remote-host `file://` URLs and Windows network paths are rejected before filesystem access, and audio embedding now enforces configured `localRoots` containment before `stat` or read operations.\n\nVerified in `v2026.4.15`:\n\n- `src/gateway/server-methods/chat-webchat-media.ts` uses safe file-URL parsing, rejects Windows network paths, and calls `assertLocalMediaAllowed` before probing local audio files.\n- `src/media/web-media.ts` rejects remote-host `file://` URLs, Windows network paths, and local-root bypasses on the shared media path.\n- `src/gateway/server-methods/chat-webchat-media.test.ts` covers both remote-host `file://` rejection and local-root denial before filesystem access.\n\nFix commits included in `v2026.4.15` and absent from `v2026.4.14`:\n\n- `1470de5d3e0970856d86cd99336bb8ada3fe87da` via PR #67293\n- `6e58f1f9f54bca1fea1268ec0ee4c01a2af03dde` via PR #67298\n- `52ef42302ead9e183e6c8810e0a04ee4ef8ae9fc` via PR #67303 as defense-in-depth for trusted media passthrough anchoring\n\nThanks to @Kherrisan for reporting this issue.",
  "id": "GHSA-mr34-9552-qr95",
  "modified": "2026-05-08T01:13:04Z",
  "published": "2026-04-17T22:33:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-mr34-9552-qr95"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41389"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/67293"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/67298"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/67303"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1470de5d3e0970856d86cd99336bb8ada3fe87da"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/52ef42302ead9e183e6c8810e0a04ee4ef8ae9fc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/6e58f1f9f54bca1fea1268ec0ee4c01a2af03dde"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-arbitrary-file-read-via-unvalidated-tool-result-media-paths"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Webchat media embedding enforces local-root containment for tool-result files"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "directus"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.8.0"
            },
            {
              "fixed": "11.9.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@directus/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.1.0"
            },
            {
              "fixed": "28.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-55746"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-20T19:08:20Z",
    "nvd_published_at": "2025-08-20T18:15:35Z",
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nA vulnerability exists in the file update mechanism which allows an unauthenticated actor to modify existing files with arbitrary contents (without changes being applied to the files\u0027 database-resident metadata) and / or upload new files, with arbitrary content and extensions, which won\u0027t show up in the Directus UI.\n\n## Details\n\nDirectus exposes the CRUD operations for uploading or handling files under the `/files` route.\n\nThe endpoint handler is responsible for updating an existing file identified by the provided primary key specified through the `pk` parameter. Primary keys are UUID values such as `/files/927b3abf-fb4b-4c66-bdaa-eb7dc48a51cb`. Here the `filename_disk` value is never sanitized, it\u0027s possible to pass a path containing traversal sequences (`../`) through it, but a fully arbitrary file write is not possible in case the \"local\" storage handler is used. (Other storage implementations haven\u0027t been checked during the research process). The `packages/storage-driver-local/src/index.ts` file defines two relevant functions: `write` and `fullpath`.\n\nThe `write` method uses the `fullPath` method to create the absolute path for the to-be-created file. The `join` method is used to create the final path string. As the `fullPath` method uses `join` to create a relative path starting with the separator to be added under the download dir, this call normalizes the path and further upwards traversal is not possible during the write operation. With that being said, it is still possible, to make the system \"ignore\" the `temp_` prefix given to the file, resulting in an arbitrarily named file being placed in the upload folder.\n\nAs a summary for the vulnerability:\n\n- It is possible, to change the contents of an existing file, as an existing UUID can be specified as the file name\n        - The metadata won\u0027t change, so the mime type cannot be modified\n        - This also makes the changes happen \"silently\", without directus knowing about the changes\n- A new, previously non-existent file can be created with arbitrary contents\n        - The file won\u0027t show up in on the Directus UI, it can only be seen through other means (such as shell access)\n- An extension MUST be defined for the file to be modified\n        - This prevents us from uploading executables or malware with no extensions, but these wouldn\u0027t be executable either way\n\nRecommendations for fixing the vulnerability can be found in later chapters.\n\n## Requirements \n\nAs providing a primary key is required for successful exploitation, at least one asset with a known UUID must be available for an attacker. This can usually be achieved by browsing an application that uses the given Directus instance to provide images. \n\nNaturally, the instance needs to be accessible over the network used by the attacker as well.\n\nOnce network access and knowledge of at least one file UUID is available for the attacker, exploitation can be done by sending a single request.\n\n## Potential impacts\n\nThe impact of successful exploitation is highly dependent on how Directus is set up to be used by a different application. Many different configurations can be created, but the following are likely the most noteworthy:\n\n1. Setting up a phishing site\n\nSVGs can be used to set up very sophisticated looking pages, as it allows the embedding of HTML, CSS and scripts. The issue is once again with the `default-src: none` CSP settings. This setting prevents the use of CSS in the SVG file, so the created page will look strange.\n\nWhile the page obviously looks strange, it\u0027s important to notice that since the domain checks out, the browser could fill out the login forms, making for a much more convincing page as shown below:\n\nAn error message can be used to make it look like an error in the system!\n\n2. Server serves files directly from the upload directory:\n\nIn this setup, a server such ash nginx serves files in a static manner. The served files are loaded from a \"public\" folder made accessible through Directus as it\u0027s recommended in the files API docs. Quoting: \"make a public folder and allow access to this\", except the upload folder is directly served by the server:\n\nSince the files loaded by the server are sourced directly from the file storage, the arbitrary file write might allow an attacker to upload a webshell into the folder, giving it an arbitrary file extension. As the extension checks out as a valid PHP file for instance, and the contents are correct code, an attacker can achieve unauthenticated code execution on the server.\n\n3. Poisoning hosted files\n\nThe previous examples focused on active exploitation, but it\u0027s important to mention that the vulnerability allows for arbitrary changes in files. This can be used for many different attack primitives. Let\u0027s consider the following scenario: Directus is used not only to serve contents on a company\u0027s web page, but internally as well. Onboarding documents for new entries are hosted on the instance. Manuals with links to internal services are provided through PDF files. If the file can be accessed and modified by an attacker, it would be trivial to set up a spoofed instance which receives credentials for internal services but redirects to the original, internal service right after. \n\n## Credits\n\nThe bug was discovered by Zombor M\u00e1t\u00e9, a security researcher at PCA Cyber Security (https://pcacybersecurity.com/)",
  "id": "GHSA-mv33-9f6j-pfmc",
  "modified": "2025-08-20T19:08:20Z",
  "published": "2025-08-20T19:08:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/security/advisories/GHSA-mv33-9f6j-pfmc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55746"
    },
    {
      "type": "WEB",
      "url": "https://github.com/directus/directus/commit/d84dcc36f75fc5c858d43746b8f9c426c38d696b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/directus/directus"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Directus allows unauthenticated file upload and file modification due to lacking input sanitization"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-7496"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-06T02:15:35Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability has been found in itsourcecode Airline Reservation System 1.0 and classified as critical. This vulnerability affects unknown code of the file /index.php. The manipulation of the argument page leads to file inclusion. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. VDB-273622 is the identifier assigned to this vulnerability.",
  "id": "GHSA-mvr6-gmwj-mq86",
  "modified": "2024-08-06T03:30:50Z",
  "published": "2024-08-06T03:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7496"
    },
    {
      "type": "WEB",
      "url": "https://github.com/DeepMountains/zzz/blob/main/CVE1-1.md"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.273622"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.273622"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?submit.385892"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/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"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-34030"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-15T12:16:25Z",
    "severity": "MODERATE"
  },
  "details": "The\u00a0Wertheim SafeController Software, AssemblyVersion 6.15.8328.28014, does not sufficiently validate the branch code when a new branch is created. The branch code is later used in multiple application functions, including filesystem path generation for uploaded files, profile pictures, and settings. An authenticated attacker with the settings_branches_manage privilege can include path traversal sequences in the branch code and influence the final filesystem location used by affected file operations. This can allow files to be stored in unintended locations, subject to service-account write permissions and branch-code length restrictions.",
  "id": "GHSA-mvvf-7w7v-ww2x",
  "modified": "2026-06-15T12:32:45Z",
  "published": "2026-06-15T12:32:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34030"
    },
    {
      "type": "WEB",
      "url": "https://r.sec-consult.com/wertheim"
    },
    {
      "type": "WEB",
      "url": "https://wertheim-safes.com/safe-deposit-box-management"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-11838"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-73"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-13T06:15:26Z",
    "severity": "HIGH"
  },
  "details": "External Control of File Name or Path vulnerability in PlexTrac allows Local Code Inclusion through use of an undocumented API endpoint.This issue affects PlexTrac: from 1.61.3 before 2.8.1.",
  "id": "GHSA-mw8h-f5q9-mjrp",
  "modified": "2025-10-01T18:30:27Z",
  "published": "2024-12-13T06:30:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11838"
    },
    {
      "type": "WEB",
      "url": "https://docs.plextrac.com/plextrac-documentation/master/security-advisories#release-2.11.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:N/SC:H/SI:H/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:Red",
      "type": "CVSS_V4"
    }
  ]
}