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

CWE-538

Allowed

Insertion of Sensitive Information into Externally-Accessible File or Directory

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.

164 vulnerabilities reference this CWE, most recent first.

GHSA-85G2-PMRX-R49Q

Vulnerability from github – Published: 2026-05-21 20:16 – Updated: 2026-07-21 13:54
VLAI
Summary
Fission runtime pods automount the fission-fetcher service-account token into the user function container, granting function code namespace-wide secret / configmap read
Details

Summary

Fission runtime pods were created with ServiceAccountName: fission-fetcher, and the fission-fetcher ServiceAccount was granted namespace-wide get on secrets and configmaps (it needs that to load function code, env vars, and config). The runtime pod's automounted token was reachable from inside the user's function container at /var/run/secrets/kubernetes.io/serviceaccount/token, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function's namespace — far beyond the Function.spec.secrets allowlist that the function specification suggests.

Affected component

  • pkg/executor/executortype/poolmgr/gp_deployment.go:154-156 — pool-manager runtime pod ServiceAccountName.
  • pkg/executor/executortype/newdeploy/newdeploy.go:225-227 — new-deploy runtime pod ServiceAccountName.
  • pkg/utils/serviceaccount.go:51-64 — fission-fetcher RBAC: namespace-wide get on secrets / configmaps.

Impact

A user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:

  1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).
  2. Read every configmap in that namespace.
  3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.

This violates the principle that Function.spec.secrets is the authoritative declaration of which secrets a function can read.

Root cause

The fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting ServiceAccountName: fission-fetcher on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.

Fix

Released in v1.23.0:

  • PR #3366 (commit fe1842ef):
  • The user function container now sets AutomountServiceAccountToken: false at the container level (via projected-volume token suppression), so the user container no longer sees the pod's SA token even though the fetcher sidecar still does.
  • The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.
  • For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via Function.spec.podspec with the minimum necessary RBAC (documented separately).

Mitigation (until upgrade)

  1. Restrict who can create / update Function and Package CRDs in your cluster — treat the ability to ship function code as equivalent to namespace-wide secret read.
  2. Reduce the fission-fetcher ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings).
  3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.22.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fission/fission"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46617"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269",
      "CWE-538"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-21T20:16:12Z",
    "nvd_published_at": "2026-06-10T18:17:05Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFission runtime pods were created with `ServiceAccountName: fission-fetcher`, and the `fission-fetcher` ServiceAccount was granted namespace-wide `get` on `secrets` and `configmaps` (it needs that to load function code, env vars, and config). The runtime pod\u0027s automounted token was reachable from inside the user\u0027s function container at `/var/run/secrets/kubernetes.io/serviceaccount/token`, so user-supplied function code inherited the same Kubernetes API privileges and could read any secret or configmap in the function\u0027s namespace \u2014 far beyond the `Function.spec.secrets` allowlist that the function specification suggests.\n\n### Affected component\n\n- `pkg/executor/executortype/poolmgr/gp_deployment.go:154-156` \u2014 pool-manager runtime pod `ServiceAccountName`.\n- `pkg/executor/executortype/newdeploy/newdeploy.go:225-227` \u2014 new-deploy runtime pod `ServiceAccountName`.\n- `pkg/utils/serviceaccount.go:51-64` \u2014 `fission-fetcher` RBAC: namespace-wide `get` on `secrets` / `configmaps`.\n\n### Impact\n\nA user able to deploy or update a function in any namespace where Fission runtime pods are scheduled could:\n\n1. Read every secret in that namespace (TLS keys, OIDC client secrets, database credentials, cloud provider credentials).\n2. Read every configmap in that namespace.\n3. Use those credentials to pivot to other Kubernetes resources or external systems the secrets unlock.\n\nThis violates the principle that `Function.spec.secrets` is the authoritative declaration of which secrets a function can read.\n\n### Root cause\n\nThe fetcher sidecar legitimately needs the SA token to call the Fission control plane and fetch package archives. Setting `ServiceAccountName: fission-fetcher` on the pod gives every container in the pod (including the user container) the automounted token. Kubernetes does not provide per-container service-account scoping inside a single pod, so the user container has to be moved into a separate identity / token-mount scheme.\n\n### Fix\n\nReleased in [v1.23.0](https://github.com/fission/fission/releases/tag/v1.23.0):\n\n- **PR #3366** (commit `fe1842ef`):\n  - The user function container now sets `AutomountServiceAccountToken: false` at the container level (via projected-volume token suppression), so the user container no longer sees the pod\u0027s SA token even though the fetcher sidecar still does.\n  - The fetcher sidecar retains its existing token mount (separate projected volume) since it needs cluster API access for its own work.\n  - For the few legitimate use cases where a function needs its own Kubernetes API access, the user is expected to mount a different ServiceAccount via `Function.spec.podspec` with the minimum necessary RBAC (documented separately).\n\n### Mitigation (until upgrade)\n\n1. Restrict who can create / update `Function` and `Package` CRDs in your cluster \u2014 treat the ability to ship function code as equivalent to namespace-wide secret read.\n2. Reduce the `fission-fetcher` ClusterRole / Role scope where possible (e.g. constrain it to specific named secrets via separate Role bindings).\n3. Add NetworkPolicy egress rules denying function pods access to the Kubernetes API server (this blunts the token even if it leaks).",
  "id": "GHSA-85g2-pmrx-r49q",
  "modified": "2026-07-21T13:54:09Z",
  "published": "2026-05-21T20:16:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/security/advisories/GHSA-85g2-pmrx-r49q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46617"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/pull/3366"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fission/fission"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/releases/tag/v1.23.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fission runtime pods automount the fission-fetcher service-account token into the user function   container, granting function code namespace-wide secret / configmap read"
}

GHSA-88XC-3623-X7QH

Vulnerability from github – Published: 2023-10-16 21:30 – Updated: 2024-02-16 21:31
VLAI
Details

The WP Job Openings WordPress plugin before 3.4.3 does not block listing the contents of the directories where it stores attachments to job applications, allowing unauthenticated visitors to list and download private attachments if the autoindex feature of the web server is enabled.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-4933"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538",
      "CWE-552",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-10-16T20:15:17Z",
    "severity": "MODERATE"
  },
  "details": "The WP Job Openings WordPress plugin before 3.4.3 does not block listing the contents of the directories where it stores attachments to job applications, allowing unauthenticated visitors to list and download private attachments if the autoindex feature of the web server is enabled.",
  "id": "GHSA-88xc-3623-x7qh",
  "modified": "2024-02-16T21:31:31Z",
  "published": "2023-10-16T21:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-4933"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/882f6c36-44c6-4273-81cd-2eaaf5e81fa7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8MHF-4C94-V897

Vulnerability from github – Published: 2022-05-17 02:19 – Updated: 2025-04-20 03:41
VLAI
Details

Sendio versions before 8.2.1 were affected by a Local File Inclusion vulnerability that allowed an unauthenticated, remote attacker to read potentially sensitive system files via a specially crafted URL.

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

{
  "affected": [],
  "aliases": [
    "CVE-2016-10399"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-07-27T18:29:00Z",
    "severity": "HIGH"
  },
  "details": "Sendio versions before 8.2.1 were affected by a Local File Inclusion vulnerability that allowed an unauthenticated, remote attacker to read potentially sensitive system files via a specially crafted URL.",
  "id": "GHSA-8mhf-4c94-v897",
  "modified": "2025-04-20T03:41:31Z",
  "published": "2022-05-17T02:19:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10399"
    },
    {
      "type": "WEB",
      "url": "https://sendio.com/support/software-release-history"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8V9V-GW67-Q3R5

Vulnerability from github – Published: 2025-11-15 00:30 – Updated: 2025-11-15 00:30
VLAI
Details

Ubee EVW3226 cable modem/routers firmware versions up to and including 1.0.20 store configuration backup files in the web root after they are generated for download. These backup files remain accessible without authentication until the next reboot. A remote attacker on the local network can request 'Configuration_file.cfg' directly to obtain the backup archive. Because backup files are not encrypted, they expose sensitive information including the plaintext admin password, allowing full compromise of the device.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-15056"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-14T23:15:41Z",
    "severity": "HIGH"
  },
  "details": "Ubee EVW3226 cable modem/routers firmware versions up to and including 1.0.20 store configuration backup files in the web root after they are generated for download. These backup files remain accessible without authentication until the next reboot. A remote attacker on the local network can request \u0027Configuration_file.cfg\u0027 directly to obtain the backup archive. Because backup files are not encrypted, they expose sensitive information including the plaintext admin password, allowing full compromise of the device.",
  "id": "GHSA-8v9v-gw67-q3r5",
  "modified": "2025-11-15T00:30:26Z",
  "published": "2025-11-15T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-15056"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2016/Jul/66"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20160403014231/http://www.ubeeinteractive.com/products/cable/evw3226"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20160726145043/http://www.search-lab.hu/advisories/122-ubee-evw3226-modem-router-multiple-vulnerabilities"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/40156"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/ubee-evw3226-unauthenticated-backup-file-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-8WCJ-MFRC-JX5Q

Vulnerability from github – Published: 2026-06-30 18:20 – Updated: 2026-06-30 18:20
VLAI
Summary
Fission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container
Details

Summary

Fission builder pods were created with ServiceAccountName: fission-builder and no AutomountServiceAccountToken: false, so the kubelet auto-mounted the service-account token into every container in the pod — including the user-supplied builder image.

Details

The user controls the builder container image, command, and podspec through Environment.spec.builder.image / .container / .podspec. With the SA token auto-mounted at /var/run/secrets/kubernetes.io/serviceaccount/token inside that container, any code running there inherited the fission-builder identity. The fission-builder SA holds namespace-wide get on secrets and configmaps (pkg/utils/serviceaccount.go), so the user-controlled builder container could read every Secret in the builder namespace by name.

This is the buildermgr sibling of GHSA-85g2-pmrx-r49q (CVE-2026-46617), whose fix suppressed the SA-token automount on function runtime pods but did not cover the structurally identical primitive in pkg/buildermgr/envwatcher.go.

Impact

A subject with create/update on Environment CRDs in a namespace observed by the buildermgr could read every Secret and ConfigMap in the builder namespace via the auto-mounted fission-builder token.

Fix

Fixed in #3390 and released in v1.24.0. In createBuilderDeployment:

  • Set pod-level AutomountServiceAccountToken=false on the initial PodSpec and add the projected fetcher SA-token volume.
  • Re-clamp AutomountServiceAccountToken=false after every MergePodSpec call so a user-supplied podspec cannot restore the kubelet automount.
  • Mount the token via a projected volume on the fetcher sidecar only, so the legitimate build → archive-upload flow keeps its cluster API access.

Reuses the projected-volume helpers from pkg/executor/util/satoken.go introduced by the GHSA-85g2-pmrx-r49q fix.

Behavioural change

The user-supplied builder container no longer receives an auto-mounted SA token. The fetcher sidecar still gets its token via a projected volume.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.23.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fission/fission"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-50565"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-250",
      "CWE-269",
      "CWE-538"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-30T18:20:03Z",
    "nvd_published_at": "2026-06-10T18:17:12Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nFission builder pods were created with `ServiceAccountName: fission-builder` and no `AutomountServiceAccountToken: false`, so the kubelet auto-mounted the service-account token into every container in the pod \u2014 including the\nuser-supplied builder image.\n\n### Details\n\nThe user controls the builder container image, command, and podspec through `Environment.spec.builder.image` / `.container` / `.podspec`. With the SA token auto-mounted at `/var/run/secrets/kubernetes.io/serviceaccount/token` inside that\n container, any code running there inherited the `fission-builder` identity. The `fission-builder` SA holds namespace-wide `get` on `secrets` and `configmaps` (`pkg/utils/serviceaccount.go`), so the user-controlled builder container\ncould read every Secret in the builder namespace by name.\n\nThis is the buildermgr sibling of GHSA-85g2-pmrx-r49q (CVE-2026-46617), whose fix suppressed the SA-token automount on function runtime pods but did not cover the structurally identical primitive in `pkg/buildermgr/envwatcher.go`.\n\n### Impact\n\nA subject with `create`/`update` on `Environment` CRDs in a namespace observed by the buildermgr could read every Secret and ConfigMap in the builder namespace via the auto-mounted `fission-builder` token.\n\n### Fix\n\nFixed in [#3390](https://github.com/fission/fission/pull/3390) and released in [v1.24.0](https://github.com/fission/fission/releases/tag/v1.24.0). In `createBuilderDeployment`:\n\n- Set pod-level `AutomountServiceAccountToken=false` on the initial PodSpec and add the projected fetcher SA-token volume.\n- Re-clamp `AutomountServiceAccountToken=false` after every `MergePodSpec` call so a user-supplied podspec cannot restore the kubelet automount.\n- Mount the token via a projected volume on the fetcher sidecar only, so the legitimate build \u2192 archive-upload flow keeps its cluster API access.\n\nReuses the projected-volume helpers from `pkg/executor/util/satoken.go` introduced by the GHSA-85g2-pmrx-r49q fix.\n\n### Behavioural change\n\nThe user-supplied builder container no longer receives an auto-mounted SA token. The fetcher sidecar still gets its token via a projected volume.",
  "id": "GHSA-8wcj-mfrc-jx5q",
  "modified": "2026-06-30T18:20:03Z",
  "published": "2026-06-30T18:20:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/security/advisories/GHSA-8wcj-mfrc-jx5q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50565"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/pull/3390"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/commit/8fa799417c77ce8a0189d9858bfe11ece29b84a6"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fission/fission"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fission/fission/releases/tag/v1.24.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fission builder pods auto-mount the fission-builder ServiceAccount token in the user-supplied builder container"
}

GHSA-9359-W3RX-353R

Vulnerability from github – Published: 2026-06-10 09:31 – Updated: 2026-06-10 09:31
VLAI
Details

A vulnerability has been found in some Dahua products. An attacker may obtain the device’s CA root certificate. If that CA is installed and trusted on client systems, the attacker could issue fraudulent certificates trusted by those clients and undermine the certificate trust chain.

Severity
2.3 (Low)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-29114"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-10T07:16:24Z",
    "severity": "LOW"
  },
  "details": "A vulnerability has been found in some Dahua products. An attacker\nmay obtain the device\u2019s CA root certificate. If that CA is installed and\ntrusted on client systems, the attacker could issue fraudulent certificates\ntrusted by those clients and undermine the certificate trust chain.",
  "id": "GHSA-9359-w3rx-353r",
  "modified": "2026-06-10T09:31:57Z",
  "published": "2026-06-10T09:31:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29114"
    },
    {
      "type": "WEB",
      "url": "https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psirt/dhcc-sa-202606-001:-security-advisory-%E2%80%93-vulnerabilities-found-in-some-dahua-products"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9C83-RR99-VFWJ

Vulnerability from github – Published: 2026-06-19 21:42 – Updated: 2026-07-20 21:31
VLAI
Summary
MCPVault: PathFilter restricted directories (.git/.obsidian/node_modules) only denied at vault root, not nested
Details

PathFilter's deny-list glob patterns are anchored, so .git, .obsidian, and node_modules were only blocked at the vault root. Nested copies inside the vault (e.g. tools/cli/node_modules/..., tools/somerepo/.git/config, a nested .obsidian/) were fully traversable via isAllowed/isAllowedForListing. Impact: a nested .git/config (remote URLs / embedded tokens) and nested .obsidian contents could be read, under the same prompt-injection threat model as GHSA-j99q-93c9-h869 (an attacker influences the path an agent reads). It also caused nested node_modules to pollute the tag index (#128, the public symptom). Fixed in 0.11.5 by denying these restricted names at any path depth (matched case-insensitively as any path segment).

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bitbonsai/mcpvault"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-538"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T21:42:24Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "PathFilter\u0027s deny-list glob patterns are anchored, so `.git`, `.obsidian`, and `node_modules` were only blocked at the vault root. Nested copies inside the vault (e.g. `tools/cli/node_modules/...`, `tools/somerepo/.git/config`, a nested `.obsidian/`) were fully traversable via isAllowed/isAllowedForListing. Impact: a nested `.git/config` (remote URLs / embedded tokens) and nested `.obsidian` contents could be read, under the same prompt-injection threat model as GHSA-j99q-93c9-h869 (an attacker influences the path an agent reads). It also caused nested `node_modules` to pollute the tag index (#128, the public symptom). Fixed in 0.11.5 by denying these restricted names at any path depth (matched case-insensitively as any path segment).",
  "id": "GHSA-9c83-rr99-vfwj",
  "modified": "2026-07-20T21:31:20Z",
  "published": "2026-06-19T21:42:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bitbonsai/mcpvault/security/advisories/GHSA-9c83-rr99-vfwj"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bitbonsai/mcpvault"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCPVault: PathFilter restricted directories (.git/.obsidian/node_modules) only denied at vault root, not nested"
}

GHSA-C3F5-RVXJ-625X

Vulnerability from github – Published: 2025-01-27 15:30 – Updated: 2026-04-01 18:33
VLAI
Details

Insertion of Sensitive Information into Externally-Accessible File or Directory vulnerability in codection Import and export users and customers allows Retrieve Embedded Sensitive Data. This issue affects Import and export users and customers: from n/a through 1.27.12.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-24689"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-27T15:15:16Z",
    "severity": "MODERATE"
  },
  "details": "Insertion of Sensitive Information into Externally-Accessible File or Directory vulnerability in codection Import and export users and customers allows Retrieve Embedded Sensitive Data. This issue affects Import and export users and customers: from n/a through 1.27.12.",
  "id": "GHSA-c3f5-rvxj-625x",
  "modified": "2026-04-01T18:33:29Z",
  "published": "2025-01-27T15:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24689"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/import-users-from-csv-with-meta/vulnerability/wordpress-import-and-export-users-and-customers-plugin-1-27-12-sensitive-data-exposure-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-C65R-5X48-PVC5

Vulnerability from github – Published: 2025-11-15 00:30 – Updated: 2025-11-15 00:30
VLAI
Details

TG8 Firewall exposes a directory such as /data/ over HTTP without authentication. This directory stores credential files for previously logged-in users. A remote unauthenticated attacker can enumerate and download files within the directory to obtain valid account usernames and passwords, leading to loss of confidentiality and further unauthorized access.

Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-4471"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-14T23:15:43Z",
    "severity": "HIGH"
  },
  "details": "TG8 Firewall exposes a directory such as /data/ over HTTP without authentication. This directory stores credential files for previously logged-in users. A remote unauthenticated attacker can enumerate and download files within the directory to obtain valid account usernames and passwords, leading to loss of confidentiality and further unauthorized access.",
  "id": "GHSA-c65r-5x48-pvc5",
  "modified": "2025-11-15T00:30:26Z",
  "published": "2025-11-15T00:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-4471"
    },
    {
      "type": "WEB",
      "url": "https://ssd-disclosure.com/ssd-advisory-tg8-firewall-preauth-rce-and-password-disclosure"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20211024224240/http://www.tg8security.com"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/tg8-firewall-unauthenticated-user-password-disclosure"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/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:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-CCF8-539P-4GC2

Vulnerability from github – Published: 2026-06-12 21:31 – Updated: 2026-06-12 21:31
VLAI
Details

During WiFi association, Naxclow device firmware prints the host network’s SSID, PSK, and negotiated WPA keys in cleartext to an exposed UART console on production hardware. The UART pads are labeled, run with default serial settings, and drop to an interactive RT-Thread shell that permits arbitrary memory reads, enabling full firmware extraction. An attacker with brief physical access, common for outdoor-mounted devices, can therefore recover WiFi credentials and bootstrap firmware-side attacks.

Severity
4.6 (Medium)
CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
5.1 (Medium)
CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-50099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-12T19:16:29Z",
    "severity": "MODERATE"
  },
  "details": "During WiFi association, Naxclow device firmware prints the host network\u2019s SSID, PSK, and negotiated WPA keys in cleartext to an exposed UART console on production hardware. The UART pads are labeled, run with default serial settings, and drop to an interactive RT-Thread shell that permits arbitrary memory reads, enabling full firmware extraction. An attacker with brief physical access, common for outdoor-mounted devices, can therefore recover WiFi credentials and bootstrap firmware-side attacks.",
  "id": "GHSA-ccf8-539p-4gc2",
  "modified": "2026-06-12T21:31:44Z",
  "published": "2026-06-12T21:31:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-50099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-162-02.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-162-02"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:N/VC:H/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:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Architecture and Design Operation System Configuration

Do not expose file and directory information to the user.

CAPEC-95: WSDL Scanning

This attack targets the WSDL interface made available by a web service. The attacker may scan the WSDL interface to reveal sensitive information about invocation patterns, underlying technology implementations and associated vulnerabilities. This type of probing is carried out to perform more serious attacks (e.g. parameter tampering, malicious content injection, command injection, etc.). WSDL files provide detailed information about the services ports and bindings available to consumers. For instance, the attacker can submit special characters or malicious content to the Web service and can cause a denial of service condition or illegal access to database records. In addition, the attacker may try to guess other private methods by using the information provided in the WSDL files.

← Back to the CWE list