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.

155 vulnerabilities reference this CWE, most recent first.

GHSA-7Q89-R4X7-5664

Vulnerability from github – Published: 2025-08-12 18:31 – Updated: 2025-10-08 15:32
VLAI
Details

By using the "uscan" protocol provided by the eSCL specification, an attacker can discover the serial number of multi-function printers that implement the Brother-provided firmware. This serial number can, in turn, can be leveraged by the flaw described by CVE-2024-51978 to calculate the default administrator password. This flaw is similar to CVE-2024-51977, with the only difference being the protocol by which an attacker can use to learn the remote device's serial number. The eSCL/uscan vector is typically only exposed on the local network. Any discovery service that implements the eSCL specification can be used to exploit this vulnerability, and one such implementation is the runZero Explorer. Changing the default administrator password will render this vulnerability virtually worthless, since the calculated default administrator password would no longer be the correct password.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-8452"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-12T16:15:29Z",
    "severity": "MODERATE"
  },
  "details": "By using the \"uscan\" protocol provided by the eSCL specification, an attacker can discover the serial number of multi-function printers that implement the Brother-provided firmware. This serial number can, in turn, can be leveraged by the flaw described by CVE-2024-51978 to calculate the default administrator password. This flaw is similar to\u00a0CVE-2024-51977, with the only difference being the protocol by which an attacker can use to learn the remote device\u0027s serial number. The eSCL/uscan vector is typically only exposed on the local network.\u00a0Any discovery service that implements the eSCL specification can be used to exploit this vulnerability, and one such implementation is the runZero Explorer.\u00a0Changing the default administrator password will render this vulnerability virtually worthless, since the calculated default administrator password would no longer be the correct password.",
  "id": "GHSA-7q89-r4x7-5664",
  "modified": "2025-10-08T15:32:26Z",
  "published": "2025-08-12T18:31:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8452"
    },
    {
      "type": "WEB",
      "url": "https://help.runzero.com/docs/installing-an-explorer"
    },
    {
      "type": "WEB",
      "url": "https://support.brother.com/g/b/faqend.aspx?c=us\u0026lang=en\u0026prod=group2\u0026faqid=faq00100851_000"
    },
    {
      "type": "WEB",
      "url": "https://takeonme.org/gcves/GCVE-1337-2025-00000000000000000000000000000000000000000000000001011111011111010111111001000000000000000000000000000000000000000000000000000000001"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-51977"
    },
    {
      "type": "WEB",
      "url": "https://www.rapid7.com/blog/post/multiple-brother-devices-multiple-vulnerabilities-fixed"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8452-54WP-RMV6

Vulnerability from github – Published: 2025-12-18 18:49 – Updated: 2025-12-18 18:49
VLAI
Summary
Storybook manager bundle may expose environment variables during build
Details

On December 11th, the Storybook team received a responsible disclosure alerting them to a potential vulnerability in certain built and published Storybooks.

The vulnerability is a bug in how Storybook handles environment variables defined in a .env file, which could, in specific circumstances, lead to those variables being unexpectedly bundled into the artifacts created by the storybook build command. When a built Storybook is published to the web, the bundle’s source is viewable, thus potentially exposing those variables to anyone with access. If those variables contained secrets, they should be considered compromised.

Who is impacted?

For a project to be vulnerable to this issue, it must:

  • Build the Storybook (i.e. run storybook build directly or indirectly) in a directory that contains a .env file (including variants like .env.local)
  • The .env file contains sensitive secrets
  • Use Storybook version 7.0.0 or above
  • Publish the built Storybook to the web

Storybooks built without a .env file at build time are not affected, including common CI-based builds where secrets are provided via platform environment variables rather than .env files.

Users' Storybook runtime environments (i.e. storybook dev) are not affected. Deployed applications that share a repo with a project's Storybook are not affected.

Storybook 6 and below are not affected.

Recommended actions

First, Storybook recommends that everyone audit for any sensitive secrets provided via .env files and rotate those keys.

Second, Storybook has released patched versions of all affected major Storybook versions that no longer have this vulnerability. Projects should upgrade their Storybook—on both local machines and CI environments—to one of these versions before publishing again.

  • 10.1.10+
  • 9.1.17+
  • 8.6.15+
  • 7.6.21+

Finally, some projects may have been relying on the undocumented behavior at the heart of this issue and will need to change how they reference environment variables after this update. If a project can no longer read necessary environmental variable values, it can either prefix the variables with STORYBOOK_ or use the env property in Storybook’s configuration to manually specify values. In either case, do not include sensitive secrets as they will be included in the built bundle.

Further information

Details of the vulnerability can be found on the Storybook announcement.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.6.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "8.0.0"
            },
            {
              "fixed": "8.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.1.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "storybook"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.1.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68429"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-538",
      "CWE-541"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-18T18:49:21Z",
    "nvd_published_at": "2025-12-17T23:16:05Z",
    "severity": "HIGH"
  },
  "details": "On December 11th, the Storybook team received a responsible disclosure alerting them to a potential vulnerability in certain built and published Storybooks. \n\nThe vulnerability is a bug in how Storybook handles environment variables defined in a `.env` file, which could, in specific circumstances, lead to those variables being unexpectedly bundled into the artifacts created by the `storybook build` command. When a built Storybook is published to the web, the bundle\u2019s source is viewable, thus potentially exposing those variables to anyone with access. If those variables contained secrets, they should be considered compromised.\n\n## Who is impacted?\n\nFor a project to be vulnerable to this issue, it must:\n\n- Build the Storybook (i.e. run `storybook build` directly or indirectly) in a directory that contains a `.env` file (including variants like `.env.local`)\n- The `.env` file contains sensitive secrets\n- Use Storybook version `7.0.0` or above\n- Publish the built Storybook to the web\n\nStorybooks built without a `.env` file at build time are not affected, including common CI-based builds where secrets are provided via platform environment variables rather than `.env` files.\n\nUsers\u0027 Storybook runtime environments (i.e. `storybook dev`) are not affected. Deployed applications that share a repo with a project\u0027s Storybook are not affected.\n\nStorybook 6 and below are not affected.\n\n## Recommended actions\n\nFirst, Storybook recommends that everyone audit for any sensitive secrets provided via `.env` files and rotate those keys.\n\nSecond, Storybook has released patched versions of all affected major Storybook versions that no longer have this vulnerability. Projects should upgrade their Storybook\u2014on both local machines and CI environments\u2014to one of these versions **before publishing again**.\n\n- `10.1.10+`\n- `9.1.17+`\n- `8.6.15+`\n- `7.6.21+`\n\nFinally, some projects may have been relying on the undocumented behavior at the heart of this issue and will need to change how they reference environment variables after this update. If a project can no longer read necessary environmental variable values, it can either prefix the variables with `STORYBOOK_` or use the [`env` property in Storybook\u2019s configuration](https://storybook.js.org/docs/configure/environment-variables#using-storybook-configuration) to manually specify values. In either case, **do not** include sensitive secrets as they *will* be included in the built bundle.\n\n## Further information\n\nDetails of the vulnerability can be found on the [Storybook announcement](https://storybook.js.org/blog/security-advisory).",
  "id": "GHSA-8452-54wp-rmv6",
  "modified": "2025-12-18T18:49:21Z",
  "published": "2025-12-18T18:49:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/storybookjs/storybook/security/advisories/GHSA-8452-54wp-rmv6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68429"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/storybookjs/storybook"
    },
    {
      "type": "WEB",
      "url": "https://storybook.js.org/blog/security-advisory"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Storybook manager bundle may expose environment variables during build"
}

GHSA-849G-4QQP-R4R8

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

IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could disclose sensitive information to an authenticated user from the monitoring and event tables.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-36372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-538"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T20:17:25Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 11.5.0 through 11.5.9, and 12.1.0 through 12.1.4 for Linux, UNIX and Windows (includes Db2 Connect Server) could disclose sensitive information to an authenticated user from the monitoring and event tables.",
  "id": "GHSA-849g-4qqp-r4r8",
  "modified": "2026-06-30T21:31:43Z",
  "published": "2026-06-30T21:31:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36372"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277417"
    }
  ],
  "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"
    }
  ]
}

GHSA-85G2-PMRX-R49Q

Vulnerability from github – Published: 2026-05-21 20:16 – Updated: 2026-06-10 18:41
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-06-10T18:41:53Z",
  "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-06-19 21:42
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": [],
  "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-06-19T21:42:24Z",
  "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"
}
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