Common Weakness Enumeration

CWE-1395

Allowed-with-Review

Dependency on Vulnerable Third-Party Component

Abstraction: Class · Status: Incomplete

The product has a dependency on a third-party component that contains one or more known vulnerabilities.

110 vulnerabilities reference this CWE, most recent first.

GHSA-VJ2P-7PGW-G2WF

Vulnerability from github – Published: 2026-03-27 15:46 – Updated: 2026-03-27 15:46
VLAI
Summary
Postiz App has a High-Severity SSRF Vulnerability via Next.js
Details

Impact

A successful SSRF attack allows an attacker to: - Bypass firewalls to scan and interact with internal network services/ports. - Access sensitive cloud metadata services (e.g., AWS IMDS 169.254.169.254) to potentially leak instance credentials. - Pivot into the internal network environment where Postiz is hosted.

Workarounds

There are no workarounds known to this, please upgrade to Postiz version v2.21.1.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "postiz"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.0.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T15:46:53Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Impact\nA successful SSRF attack allows an attacker to:\n- Bypass firewalls to scan and interact with internal network services/ports.\n- Access sensitive cloud metadata services (e.g., AWS IMDS 169.254.169.254) to potentially leak instance credentials.\n- Pivot into the internal network environment where Postiz is hosted.\n\n### Workarounds\nThere are no workarounds known to this, please upgrade to Postiz version `v2.21.1`.",
  "id": "GHSA-vj2p-7pgw-g2wf",
  "modified": "2026-03-27T15:46:53Z",
  "published": "2026-03-27T15:46:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitroomhq/postiz-app/security/advisories/GHSA-vj2p-7pgw-g2wf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-fr5h-rqp8-mj6g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34351"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitroomhq/postiz-app"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Postiz App has a High-Severity SSRF Vulnerability via Next.js"
}

GHSA-VJWG-28GV-PM8H

Vulnerability from github – Published: 2024-04-24 17:02 – Updated: 2024-05-08 14:01
VLAI
Summary
Pimcore TinyMCE Bundle - tinymce CVE-2024-29203, CVE-2024-29881
Details

Impact

The TineMCE Bundle uses tinymce version 6.7.3. CVEs for this version exists for <6.8.1: https://nvd.nist.gov/vuln/detail/CVE-2024-29203 https://nvd.nist.gov/vuln/detail/CVE-2024-29881

Patches

The package should be updated to at least 6.8.1 to avoid XSS vulnerability.

Workarounds

Upgrade pimcore to release 11.2.3 or 11.1.6.5.

References

https://nvd.nist.gov/vuln/detail/CVE-2024-29203 https://nvd.nist.gov/vuln/detail/CVE-2024-29881

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.2.0"
            },
            {
              "fixed": "11.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "pimcore/pimcore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0-ALPHA1"
            },
            {
              "fixed": "11.1.6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-24T17:02:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe TineMCE Bundle uses tinymce version 6.7.3. CVEs for this version exists for \u003c6.8.1:\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-29203\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-29881\n\n### Patches\nThe package should be updated to at least 6.8.1 to avoid XSS vulnerability.\n\n### Workarounds\nUpgrade pimcore to release 11.2.3 or 11.1.6.5.\n\n### References\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-29203\nhttps://nvd.nist.gov/vuln/detail/CVE-2024-29881\n",
  "id": "GHSA-vjwg-28gv-pm8h",
  "modified": "2024-05-08T14:01:01Z",
  "published": "2024-04-24T17:02:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pimcore/pimcore/security/advisories/GHSA-vjwg-28gv-pm8h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pimcore/pimcore"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Pimcore TinyMCE Bundle - tinymce CVE-2024-29203, CVE-2024-29881"
}

GHSA-VRPV-VW92-328G

Vulnerability from github – Published: 2025-02-06 17:10 – Updated: 2025-02-06 17:10
VLAI
Summary
Multiple rtmpdump vulnerabilities
Details

The version of rtmpdump contained in this package has multiple known vulnerabilities.

Patches

This package is abandoned and should not be used anymore. There is no patched release.

Workarounds

You should install rmtpdump from another source.

References

  • https://github.com/advisories/GHSA-fm48-q5qq-894j
  • https://github.com/advisories/GHSA-pfv7-grcx-8gcc
  • https://github.com/advisories/GHSA-hg4c-2mw4-gwpm
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "rudloff/rtmpdump-bin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-06T17:10:32Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "The version of rtmpdump contained in this package has multiple known vulnerabilities.\n\n### Patches\nThis package is abandoned and should not be used anymore.\nThere is no patched release.\n\n### Workarounds\nYou should install rmtpdump from another source.\n\n### References\n* https://github.com/advisories/GHSA-fm48-q5qq-894j\n* https://github.com/advisories/GHSA-pfv7-grcx-8gcc\n* https://github.com/advisories/GHSA-hg4c-2mw4-gwpm",
  "id": "GHSA-vrpv-vw92-328g",
  "modified": "2025-02-06T17:10:32Z",
  "published": "2025-02-06T17:10:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Rudloff/rtmpdump-bin/security/advisories/GHSA-vrpv-vw92-328g"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Rudloff/rtmpdump-bin"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-fm48-q5qq-894j"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-hg4c-2mw4-gwpm"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-pfv7-grcx-8gcc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Multiple rtmpdump vulnerabilities"
}

GHSA-VVFQ-8HWR-QM4M

Vulnerability from github – Published: 2025-02-18 22:36 – Updated: 2025-03-10 22:36
VLAI
Summary
Nokogiri updates packaged libxml2 to 2.13.6 to resolve CVE-2025-24928 and CVE-2024-56171
Details

Summary

Nokogiri v1.18.3 upgrades its dependency libxml2 to v2.13.6.

libxml2 v2.13.6 addresses:

  • CVE-2025-24928
  • described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/847
  • CVE-2024-56171
  • described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/828

Impact

CVE-2025-24928

Stack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.

CVE-2024-56171

Use-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of xsd:keyref in combination with recursively defined types that have additional identity constraints.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "nokogiri"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-121",
      "CWE-1395",
      "CWE-416"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-18T22:36:03Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Summary\n\nNokogiri v1.18.3 upgrades its dependency libxml2 to [v2.13.6](https://gitlab.gnome.org/GNOME/libxml2/-/releases/v2.13.6).\n\nlibxml2 v2.13.6 addresses:\n\n- CVE-2025-24928\n  - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/847\n- CVE-2024-56171\n   - described at https://gitlab.gnome.org/GNOME/libxml2/-/issues/828\n\n## Impact\n\n### CVE-2025-24928\n\nStack-buffer overflow is possible when reporting DTD validation errors if the input contains a long (~3kb) QName prefix.\n\n### CVE-2024-56171\n\nUse-after-free is possible during validation against untrusted XML Schemas (.xsd) and, potentially, validation of untrusted documents against trusted Schemas if they make use of `xsd:keyref` in combination with recursively defined types that have additional identity constraints.",
  "id": "GHSA-vvfq-8hwr-qm4m",
  "modified": "2025-03-10T22:36:22Z",
  "published": "2025-02-18T22:36:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-vvfq-8hwr-qm4m"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/nokogiri/GHSA-vvfq-8hwr-qm4m.yml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sparklemotion/nokogiri"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "Nokogiri updates packaged libxml2 to 2.13.6 to resolve CVE-2025-24928 and CVE-2024-56171"
}

GHSA-VVG7-8RMQ-92G7

Vulnerability from github – Published: 2025-12-17 20:57 – Updated: 2025-12-17 20:57
VLAI
Summary
Auth0 WordPress has Improper Audience Validation via Auth0-PHP SDK Dependency
Details

Description

In applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.

Affected product and versions

Projects are affected if they meet the following preconditions:

  • Applications using the Auth0 Wordpress plugin with version between 5.0.0-BETA0 and 5.4.0,
  • Auth0 Wordpress plugin uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.

Resolution

Upgrade Auth0 Wordpress plugin to version 5.5.0 or greater.

Acknowledgement

Okta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.4.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "auth0/wordpress"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0-BETA0"
            },
            {
              "fixed": "5.5.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-17T20:57:09Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Description\nIn applications built with the Auth0-PHP SDK, the audience validation in access tokens is performed improperly. Without proper validation, affected applications may accept ID tokens as Access tokens.\n\n### Affected product and versions\nProjects are affected if they meet the following preconditions:\n\n- Applications using the Auth0 Wordpress plugin with version between 5.0.0-BETA0 and 5.4.0,\n- Auth0 Wordpress plugin uses the Auth0-PHP SDK with versions between 8.0.0 and 8.17.0.\n\n### Resolution\nUpgrade Auth0 Wordpress plugin to version 5.5.0 or greater.\n\n### Acknowledgement\nOkta would like to thank Jafar Sadiq (iaf4r) for their discovery and responsible disclosure.",
  "id": "GHSA-vvg7-8rmq-92g7",
  "modified": "2025-12-17T20:57:09Z",
  "published": "2025-12-17T20:57:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/security/advisories/GHSA-vvg7-8rmq-92g7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/commit/b207c6f7fd06507b90c4e6bcc18a857ef9e018de"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/auth0/wordpress"
    },
    {
      "type": "WEB",
      "url": "https://github.com/auth0/wordpress/releases/tag/5.5.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Auth0 WordPress has Improper Audience Validation via Auth0-PHP SDK Dependency"
}

GHSA-W2FM-25VW-VH7F

Vulnerability from github – Published: 2026-04-01 23:58 – Updated: 2026-04-01 23:58
VLAI
Summary
mcp-handler has a tool response leak across concurrent client sessions ('Race Condition')
Details

mcp-handler versions prior to 1.1.0 accepted @modelcontextprotocol/sdk < 1.26.0 as a peer dependency. That SDK version contains a vulnerability [CVE-2026-25536] that causes concurrent requests from different clients to share server-side state including authentication context and tool execution results when a StreamableHTTPServerTransport instance is reused across requests.

Note: This is not a vulnerability in mcp-handler itself. The root cause is in the peer dependency @modelcontextprotocol/sdk.

Impact

A low-privileged attacker making concurrent requests to an mcp-handler endpoint can read another client's session data, including authentication information and tool execution state. This is a confidentiality breach with potential for limited integrity impact.

Root Cause: CVE-2026-25536 in @modelcontextprotocol/sdk < 1.26.0. The SDK did not prevent reuse of stateless transports across client connections.

Patches

Upgrade to mcp-handler@1.1.0. This release raises the minimum peer dependency to @modelcontextprotocol/sdk@>=1.26.0, which contains the fix for CVE-2026-25536.

Workarounds

  • Upgrade @modelcontextprotocol/sdk to >=1.26.0 (note: the SDK will throw on transport reuse, which will break mcp-handler < 1.1.0 which effectively forces the upgrade)
  • Alternatively, manually create fresh McpServer and transport instances per request in your handler code
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "mcp-handler"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-362"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T23:58:50Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "`mcp-handler` versions prior to 1.1.0 accepted `@modelcontextprotocol/sdk` \u003c 1.26.0 as a peer dependency. That SDK version contains a vulnerability [[CVE-2026-25536](https://nvd.nist.gov/vuln/detail/CVE-2026-25536)] that causes concurrent requests from different clients to share server-side state including authentication context and tool execution results when a `StreamableHTTPServerTransport` instance is reused across requests.\n\n**Note:** This is _not_ a vulnerability in `mcp-handler` itself. The root cause is in the peer dependency `@modelcontextprotocol/sdk`. \n\n### Impact\n\nA low-privileged attacker making concurrent requests to an `mcp-handler` endpoint can read another client\u0027s session data, including authentication information and tool execution state. This is a confidentiality breach with potential for limited integrity impact.\n\n**Root Cause:** [CVE-2026-25536](https://nvd.nist.gov/vuln/detail/CVE-2026-25536) in `@modelcontextprotocol/sdk` \u003c 1.26.0. The SDK did not prevent reuse of stateless transports across client connections.\n\n### Patches\n\nUpgrade to `mcp-handler@1.1.0`. This release raises the minimum peer dependency to `@modelcontextprotocol/sdk@\u003e=1.26.0`, which contains the fix for CVE-2026-25536. \n\n### Workarounds\n\n- Upgrade `@modelcontextprotocol/sdk` to `\u003e=1.26.0` (note: the SDK will throw on transport reuse, which will break `mcp-handler` \u003c 1.1.0 which effectively forces the upgrade)\n- Alternatively, manually create fresh `McpServer` and transport instances per request in your handler code",
  "id": "GHSA-w2fm-25vw-vh7f",
  "modified": "2026-04-01T23:58:50Z",
  "published": "2026-04-01T23:58:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/mcp-handler/security/advisories/GHSA-w2fm-25vw-vh7f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25536"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-345p-7cg4-v4c7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/mcp-handler"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "mcp-handler has a tool response leak across concurrent client sessions (\u0027Race Condition\u0027)"
}

GHSA-W2JF-268Q-MRVH

Vulnerability from github – Published: 2025-11-06 15:44 – Updated: 2025-11-06 15:44
VLAI
Summary
OpenTofu affected denials of service in "tofu init" with maliciously-crafted module package responses
Details

Impact

Unauthenticated denial of service.

Summary

When installing module packages from attacker-controlled sources, tofu init may use unbounded memory, cause high CPU usage, or crash when encountering maliciously-crafted TLS certificate chains or tar archives.

Those who depend on modules or providers served from untrusted third-party servers may experience denial of service due to tofu init failing to complete successfully. In the case of unbounded memory usage or high CPU usage, other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.

These vulnerabilities do not permit arbitrary code execution or allow disclosure of confidential information.

Details

OpenTofu relies on third-party implementations of TLS certificate verification and tar archive extraction from the standard library of the Go programming language.

The Go project has recently published the following advisories for those implementations which indirectly affect OpenTofu's behavior:

  • CVE-2025-58183: Unbounded allocation when parsing GNU sparse map in archive/tar
  • CVE-2025-58185: Parsing DER payload can cause memory exhaustion in encoding/asn1
  • CVE-2025-58187: Quadratic complexity when checking name constraints in crypto/x509
  • CVE-2025-58188: Panic when validating certificates with DSA public keys in crypto/x509

OpenTofu's threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of installing these dependencies with tofu init, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the TLS-related vulnerabilities can occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because they affect the transport of the packages rather than the content of the packages.

An attacker can exploit this either by controlling the TLS certificate chain used to authenticate the connection to the server where the dependencies are hosted, or (in the case of module packages only) by controlling the content of a package served when OpenTofu is expecting to receive a package using the "tar" archive format with or without compression.

However, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the tofu init process, which does not execute third-party dependency code itself.

Patches

OpenTofu v1.10.7 addresses these vulnerabilities by being built against Go 1.24.9, which contains improved versions of the upstream implementations.

The OpenTofu v1.9 and v1.8 series are also impacted by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.9 for those series would effectively end support for certain versions of macOS and Linux, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.9 or v1.8 releases we recommend planning to upgrade to OpenTofu v1.10.7 in the near future, and reviewing the Workarounds section below in the meantime.

Workarounds

These vulnerabilities can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running tofu init. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies before adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.

Successful exploitation requires that the attacker control either an HTTPS server that tofu init would contact during dependency installation or a tar archive that OpenTofu would fetch and extract during the module installation process. Note that OpenTofu modules can have their own dependencies on other modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/opentofu/opentofu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-11-06T15:44:04Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Impact\n\nUnauthenticated denial of service.\n\n### Summary\n\nWhen installing module packages from attacker-controlled sources, `tofu init` may use unbounded memory, cause high CPU usage, or crash when encountering maliciously-crafted TLS certificate chains or tar archives.\n\nThose who depend on modules or providers served from untrusted third-party servers may experience denial of service due to `tofu init` failing to complete successfully. In the case of unbounded memory usage or high CPU usage, other processes running on the same computer as OpenTofu may also fail or have their performance degraded due to the depletion of shared system resources.\n\nThese vulnerabilities **do not** permit arbitrary code execution or allow disclosure of confidential information.\n\n### Details\n\nOpenTofu relies on third-party implementations of TLS certificate verification and tar archive extraction from the standard library of the Go programming language.\n\nThe Go project has recently published the following advisories for those implementations which indirectly affect OpenTofu\u0027s behavior:\n\n- [CVE-2025-58183](https://www.cve.org/CVERecord?id=CVE-2025-58183): Unbounded allocation when parsing GNU sparse map in archive/tar\n- [CVE-2025-58185](https://www.cve.org/CVERecord?id=CVE-2025-58185): Parsing DER payload can cause memory exhaustion in encoding/asn1\n- [CVE-2025-58187](https://www.cve.org/CVERecord?id=CVE-2025-58187): Quadratic complexity when checking name constraints in crypto/x509\n- [CVE-2025-58188](https://www.cve.org/CVERecord?id=CVE-2025-58188): Panic when validating certificates with DSA public keys in crypto/x509\n\nOpenTofu\u0027s threat model considers module and package dependencies to be arbitrary third-party code that operators must carefully review after installation. However, these particular problems affect the process of _installing_ these dependencies with `tofu init`, and so can potentially occur before an operator has had the opportunity to review what is being installed. In particular, the TLS-related vulnerabilities can occur before OpenTofu actually retrieves a dependency package and performs checksum verification, because they affect the transport of the packages rather than the content of the packages.\n\nAn attacker can exploit this either by controlling the TLS certificate chain used to authenticate the connection to the server where the dependencies are hosted, or (in the case of module packages only) by controlling the content of a package served when OpenTofu is expecting to receive a package using the \"tar\" archive format with or without compression.\n\nHowever, the attacker must also coerce an OpenTofu operator into attempting dependency installation from the server they control. Typical use of OpenTofu already requires caution in selection of third-party dependencies because they are arbitrary code, and so the vulnerability here is only in the addition of a potential denial of service in the `tofu init` process, which does not execute third-party dependency code itself.\n\n### Patches\n\nOpenTofu v1.10.7 addresses these vulnerabilities by being built against Go 1.24.9, which contains improved versions of the upstream implementations.\n\nThe OpenTofu v1.9 and v1.8 series are also impacted by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.9 for those series would effectively end support for certain versions of macOS and Linux, and the OpenTofu Project has determined that the impact of these vulnerabilities is not high enough to justify that disruption in a patch release. For those using the OpenTofu v1.9 or v1.8 releases we recommend planning to upgrade to OpenTofu v1.10.7 in the near future, and reviewing the Workarounds section below in the meantime.\n\n### Workarounds\n\nThese vulnerabilities can be exploited only if an attacker can coerce an operator to add a dependency from an attacker-controlled source to their configuration before running `tofu init`. Those who are unable to upgrade can therefore minimize risk by reviewing new dependencies _before_ adding them to the configuration, such as by directly fetching the relevant artifacts using software other than OpenTofu.\n\nSuccessful exploitation requires that the attacker control either an HTTPS server that `tofu init` would contact during dependency installation or a tar archive that OpenTofu would fetch and extract during the module installation process. Note that OpenTofu modules can have their own dependencies on other modules, so an attacker could potentially use a module served from a source such as GitHub or the OpenTofu Registry to indirectly request a module from a server they control.",
  "id": "GHSA-w2jf-268q-mrvh",
  "modified": "2025-11-06T15:44:04Z",
  "published": "2025-11-06T15:44:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/security/advisories/GHSA-w2jf-268q-mrvh"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/issues/3458"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/issues/3462"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/issues/3464"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/issues/3465"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/pull/3467"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/opentofu/opentofu"
    },
    {
      "type": "WEB",
      "url": "https://github.com/opentofu/opentofu/releases/tag/v1.10.7"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTofu affected denials of service in \"tofu init\" with maliciously-crafted module package responses"
}

GHSA-W37M-7FHW-FMV9

Vulnerability from github – Published: 2025-12-11 22:49 – Updated: 2025-12-11 22:49
VLAI
Summary
Next Server Actions Source Code Exposure
Details

A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as CVE-2025-55183.

A malicious HTTP request can be crafted and sent to any App Router endpoint that can return the compiled source code of Server Functions. This could reveal business logic, but would not expose secrets unless they were hardcoded directly into Server Function code.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0.0-canary.0"
            },
            {
              "fixed": "15.0.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.1.1-canary.0"
            },
            {
              "fixed": "15.1.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.2.0-canary.0"
            },
            {
              "fixed": "15.2.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.3.0-canary.0"
            },
            {
              "fixed": "15.3.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.4.0-canary.0"
            },
            {
              "fixed": "15.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.5.1-canary.0"
            },
            {
              "fixed": "15.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.6.0-canary.0"
            },
            {
              "fixed": "15.6.0-canary.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.0.0-beta.0"
            },
            {
              "fixed": "16.0.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "16.1.0-canary.0"
            },
            {
              "fixed": "16.1.0-canary.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-497",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-11T22:49:56Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A vulnerability affects certain React packages for versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 and frameworks that use the affected packages, including Next.js 15.x and 16.x using the App Router. The issue is tracked upstream as [CVE-2025-55183](https://www.cve.org/CVERecord?id=CVE-2025-55183).\n\nA malicious HTTP request can be crafted and sent to any App Router endpoint that can return the compiled source code of [Server Functions](https://react.dev/reference/rsc/server-functions). This could reveal business logic, but would not expose secrets unless they were hardcoded directly into [Server Function](https://react.dev/reference/rsc/server-functions) code.",
  "id": "GHSA-w37m-7fhw-fmv9",
  "modified": "2025-12-11T22:49:56Z",
  "published": "2025-12-11T22:49:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-w37m-7fhw-fmv9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    },
    {
      "type": "WEB",
      "url": "https://nextjs.org/blog/security-update-2025-12-11"
    },
    {
      "type": "WEB",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-55183"
    }
  ],
  "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"
    }
  ],
  "summary": "Next Server Actions Source Code Exposure "
}

GHSA-WCJX-V2WJ-XG87

Vulnerability from github – Published: 2026-03-26 22:27 – Updated: 2026-03-26 22:27
VLAI
Summary
C2C CI utils is vulnerable to DoS via pyasn dependency (CVE-2026-30922)
Details

Pin vulnerable version of pyasn, see: See: https://github.com/advisories/GHSA-jr27-m4p2-rc6r

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 1.1.65"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "c2cciutils"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.66"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395",
      "CWE-674"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-26T22:27:12Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Pin vulnerable version of pyasn, see: See: https://github.com/advisories/GHSA-jr27-m4p2-rc6r",
  "id": "GHSA-wcjx-v2wj-xg87",
  "modified": "2026-03-26T22:27:12Z",
  "published": "2026-03-26T22:27:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/camptocamp/c2cciutils/security/advisories/GHSA-wcjx-v2wj-xg87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/camptocamp/c2cciutils/commit/1ab415014817d7d1cf09ad56cc8a7dec2a1108d8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/camptocamp/c2cciutils"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "C2C CI utils is vulnerable to DoS via pyasn dependency (CVE-2026-30922)"
}

GHSA-X9P2-77V6-6VHF

Vulnerability from github – Published: 2026-02-05 18:02 – Updated: 2026-02-12 14:23
VLAI
Summary
FrankenPHP has delayed propagation of security fixes in upstream base images
Details

Delayed propagation of security fixes in upstream base images

Summary

Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images.

FrankenPHP's container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers.

Impact

Users pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., libcrypto3) even if they were using the "latest" version of a specific FrankenPHP tag.

Specifically, this includes vulnerabilities recently patched in Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3, such as CVE-2025-15467 (Remote Code Execution in libcrypto3).

Details

The issue was a lack of automated "staleness" detection in the CI/CD pipeline.

Unless explicitly told, our build server was building new Docker images only when a new tag for base images was created. However, base images such as Alpine, PHP, and Go usually overwrite existing Docker tags to apply security fixes, which wasn't triggering a new build on our side.

Patches

As of February 4, 2026, the CI/CD pipeline has been updated.

  • Automated Detection: A daily check is now performed to compare the digest of local base images against upstream registries.
  • Auto-Rebuild: If a change is detected in base images (even if the tag name remains the same), FrankenPHP images are automatically rebuilt and re-pushed.

Users are advised to pull the latest versions of their specific tags to receive these updates.

Workarounds

You can force a local rebuild of your environment using the --pull flag to ensure you are fetching the latest patched base layers:

docker pull dunglas/frankenphp:latest
# If building your own image based on FrankenPHP
docker build --pull -t my-app .

References

Credits

Thanks to Tim Nelles for reporting and fixing this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dunglas/frankenphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1395"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-05T18:02:25Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# Delayed propagation of security fixes in upstream base images\n\n## Summary\n\n**Vulnerability in base Docker images (PHP, Go, and Alpine) not automatically propagating to FrankenPHP images.**\n\nFrankenPHP\u0027s container images were previously built only when specific version tags were updated or when manual triggers were initiated. This meant that if an upstream base image (such as Alpine Linux or official PHP/Go images) received a security patch under an existing tag, the FrankenPHP image would remain on the older, vulnerable version of those base layers.\n\n## Impact\n\nUsers pulling FrankenPHP images may have been running environments with known vulnerabilities in underlying system libraries (e.g., `libcrypto3`) even if they were using the \"latest\" version of a specific FrankenPHP tag.\n\nSpecifically, this includes vulnerabilities recently patched in **Alpine 3.20.9, 3.21.6, 3.22.3, and 3.23.3**, such as **CVE-2025-15467** (Remote Code Execution in `libcrypto3`).\n\n## Details\n\nThe issue was a lack of automated \"staleness\" detection in the CI/CD pipeline.\n\nUnless explicitly told, our build server was building new Docker images only when a new tag for base images was created. However, base images such as Alpine, PHP, and Go usually overwrite existing Docker tags to apply security fixes, which wasn\u0027t triggering a new build on our side.\n\n## Patches\n\nAs of **February 4, 2026**, the CI/CD pipeline has been updated.\n\n* **Automated Detection:** A daily check is now performed to compare the digest of local base images against upstream registries.\n* **Auto-Rebuild:** If a change is detected in base images (even if the tag name remains the same), FrankenPHP images are automatically rebuilt and re-pushed.\n\n**Users are advised to pull the latest versions of their specific tags to receive these updates.**\n\n## Workarounds\n\nYou can force a local rebuild of your environment using the `--pull` flag to ensure you are fetching the latest patched base layers:\n\n```bash\ndocker pull dunglas/frankenphp:latest\n# If building your own image based on FrankenPHP\ndocker build --pull -t my-app .\n```\n\n## References\n\n* [Alpine Linux Security Advisories](https://www.alpinelinux.org/posts/Alpine-3.20.9-3.21.6-3.22.3-3.23.3-released.html)\n* **CVE-2025-15467** (RCE in libcrypto3)\n\n## Credits\n\nThanks to [Tim Nelles](https://timnelles.de/) for reporting and fixing this issue.",
  "id": "GHSA-x9p2-77v6-6vhf",
  "modified": "2026-02-12T14:23:09Z",
  "published": "2026-02-05T18:02:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/security/advisories/GHSA-x9p2-77v6-6vhf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/php/frankenphp"
    }
  ],
  "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"
    }
  ],
  "summary": "FrankenPHP has delayed propagation of security fixes in upstream base images"
}

Mitigation
Requirements Policy

In some industries such as healthcare [REF-1320] [REF-1322] or technologies such as the cloud [REF-1321], it might be unclear about who is responsible for applying patches for third-party vulnerabilities: the vendor, the operator/customer, or a separate service. Clarifying roles and responsibilities can be important to minimize confusion or unnecessary delay when third-party vulnerabilities are disclosed.

Mitigation
Requirements

Require a Bill of Materials for all components and sub-components of the product. For software, require a Software Bill of Materials (SBOM) [REF-1247] [REF-1311].

Mitigation
Architecture and Design Implementation Integration Manufacturing

Maintain a Bill of Materials for all components and sub-components of the product. For software, maintain a Software Bill of Materials (SBOM). According to [REF-1247], "An SBOM is a formal, machine-readable inventory of software components and dependencies, information about those components, and their hierarchical relationships."

Mitigation
Operation Patching and Maintenance

Actively monitor when a third-party component vendor announces vulnerability patches; fix the third-party component as soon as possible; and make it easy for operators/customers to obtain and apply the patch.

Mitigation
Operation Patching and Maintenance

Continuously monitor changes in each of the product's components, especially when the changes indicate new vulnerabilities, end-of-life (EOL) plans, etc.

No CAPEC attack patterns related to this CWE.