CWE-1395
Allowed-with-ReviewDependency 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.
115 vulnerabilities reference this CWE, most recent first.
GHSA-HW5X-4R37-72W7
Vulnerability from github – Published: 2026-04-14 23:34 – Updated: 2026-04-14 23:34Impact
Unauthenticated denial of service.
Summary
When installing module packages from attacker-controlled sources, tofu init may use unbounded memory, cause high CPU usage, or deadlock 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-2026-32280: Unexpected work during chain building in crypto/x509
- CVE-2026-32281: Inefficient policy validation in crypto/x509
- CVE-2026-32283: Unauthenticated TLS 1.3 KeyUpdate record can cause persistent connection retention and DoS in crypto/tls
- CVE-2026-32288: Unbounded allocation for old GNU sparse in archive/tar
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.11.6 addresses these vulnerabilities by being built against Go 1.25.9, which contains improved versions of the upstream implementations.
The OpenTofu v1.10 and v1.9 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.25.9 for those series would effectively end support for certain versions of macOS, 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.10 or v1.9 releases we recommend planning to upgrade to OpenTofu v1.11.6 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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/opentofu/opentofu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T23:34:08Z",
"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 deadlock 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-2026-32280](https://www.cve.org/CVERecord?id=CVE-2026-32280): Unexpected work during chain building in crypto/x509\n- [CVE-2026-32281](https://www.cve.org/CVERecord?id=CVE-2026-32281): Inefficient policy validation in crypto/x509\n- [CVE-2026-32283](https://www.cve.org/CVERecord?id=CVE-2026-32283): Unauthenticated TLS 1.3 KeyUpdate record can cause persistent connection retention and DoS in crypto/tls\n- [CVE-2026-32288](https://www.cve.org/CVERecord?id=CVE-2026-32288): Unbounded allocation for old GNU sparse in archive/tar\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.11.6 addresses these vulnerabilities by being built against Go 1.25.9, which contains improved versions of the upstream implementations.\n\nThe OpenTofu v1.10 and v1.9 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.25.9 for those series would effectively end support for certain versions of macOS, 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.10 or v1.9 releases we recommend planning to upgrade to OpenTofu v1.11.6 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-hw5x-4r37-72w7",
"modified": "2026-04-14T23:34:09Z",
"published": "2026-04-14T23:34:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/security/advisories/GHSA-hw5x-4r37-72w7"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/4029"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/4030"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/4031"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/4032"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/pull/3966"
},
{
"type": "PACKAGE",
"url": "https://github.com/opentofu/opentofu"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/releases/tag/v1.11.6"
}
],
"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 has unbounded memory usage, high CPU usage, or deadlock in \"tofu init\" with maliciously-crafted dependency responses"
}
GHSA-HX5Q-V6PJ-533R
Vulnerability from github – Published: 2024-02-26 20:04 – Updated: 2024-02-26 20:04Impact
When SAML is used as the authentication mechanism, Central Dogma accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected.
Patches
The vulnerability has been patched in Central Dogma 0.64.3 by updating its Armeria dependency to 1.27.2. All users who use SAML as the authentication mechanism must upgrade from 0.64.3 or later.
Workarounds
A user can manually upgrade the armeria-saml module with the one from Armeria 1.27.2 or later, either by replacing the JAR in the Central Dogma distribution or by updating the dependency tree of the build.
References
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.64.2"
},
"package": {
"ecosystem": "Maven",
"name": "com.linecorp.centraldogma:centraldogma-server-auth-saml"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.64.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-26T20:04:50Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "### Impact\n\nWhen SAML is used as the authentication mechanism, Central Dogma accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected.\n\n### Patches\n\nThe vulnerability has been patched in Central Dogma 0.64.3 by updating its Armeria dependency to 1.27.2. All users who use SAML as the authentication mechanism must upgrade from 0.64.3 or later.\n\n### Workarounds\n\nA user can manually upgrade the `armeria-saml` module with the one from Armeria 1.27.2 or later, either by replacing the JAR in the Central Dogma distribution or by updating the dependency tree of the build.\n\n### References\n\n[`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)",
"id": "GHSA-hx5q-v6pj-533r",
"modified": "2024-02-26T20:04:50Z",
"published": "2024-02-26T20:04:50Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/line/armeria/security/advisories/GHSA-4m6j-23p2-8c54"
},
{
"type": "WEB",
"url": "https://github.com/line/centraldogma/security/advisories/GHSA-hx5q-v6pj-533r"
},
{
"type": "WEB",
"url": "https://github.com/line/centraldogma/commit/16903426be2e954c050b3ee47b8c38ee3218f0eb"
},
{
"type": "WEB",
"url": "https://github.com/line/centraldogma/commit/16903426be2e954c050b3ee47b8c38ee3218f0ebxz"
},
{
"type": "PACKAGE",
"url": "https://github.com/line/centraldogma"
},
{
"type": "WEB",
"url": "https://github.com/line/centraldogma/releases/tag/centraldogma-0.64.3"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "SAML authentication bypass due to missing validation on unsigned SAML messages"
}
GHSA-J9WF-6R2X-HQMX
Vulnerability from github – Published: 2026-02-19 22:07 – Updated: 2026-02-19 22:07Summary
Centrifugo v6.6.0 binary is compiled with Go 1.25.5 and
statically links github.com/quic-go/webtransport-go v0.9.0, having 7 known
CVEs
Go standard library — compiled with Go 1.25.5:
| CVE | Severity | CVSS | Fixed In |
|---|---|---|---|
| CVE-2025-68121 | CRITICAL | 10.0 | Go 1.25.7, 1.24.13 |
| CVE-2025-61726 | HIGH | 7.5 | Go 1.25.6, 1.24.12 |
| CVE-2025-61728 | MEDIUM | 6.5 | Go 1.25.6, 1.24.12 |
| CVE-2025-61730 | MEDIUM | 5.3 | Go 1.25.6, 1.24.12 |
Direct dependency github.com/quic-go/webtransport-go — pinned at v0.9.0
(go.mod line 34):
| CVE | Severity | CVSS | Fixed In |
|---|---|---|---|
| CVE-2026-21434 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
| CVE-2026-21435 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
| CVE-2026-21438 | MEDIUM | 5.3 | webtransport-go v0.10.0 |
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/centrifugal/centrifugo/v6"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-19T22:07:13Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary \n \n Centrifugo v6.6.0 binary is compiled with **Go 1.25.5** and \n statically links `github.com/quic-go/webtransport-go v0.9.0`, having **7 known \n CVEs**\n\n **Go standard library \u2014 compiled with Go 1.25.5:**\n\n | CVE | Severity | CVSS | Fixed In |\n |-----|----------|------|----------|\n | CVE-2025-68121 | **CRITICAL** | 10.0 | Go 1.25.7, 1.24.13 |\n | CVE-2025-61726 | HIGH | 7.5 | Go 1.25.6, 1.24.12 |\n | CVE-2025-61728 | MEDIUM | 6.5 | Go 1.25.6, 1.24.12 |\n | CVE-2025-61730 | MEDIUM | 5.3 | Go 1.25.6, 1.24.12 |\n\n **Direct dependency `github.com/quic-go/webtransport-go` \u2014 pinned at v0.9.0\n (`go.mod` line 34):**\n\n | CVE | Severity | CVSS | Fixed In |\n |-----|----------|------|----------|\n | CVE-2026-21434 | MEDIUM | 5.3 | webtransport-go v0.10.0 |\n | CVE-2026-21435 | MEDIUM | 5.3 | webtransport-go v0.10.0 |\n | CVE-2026-21438 | MEDIUM | 5.3 | webtransport-go v0.10.0 |",
"id": "GHSA-j9wf-6r2x-hqmx",
"modified": "2026-02-19T22:07:13Z",
"published": "2026-02-19T22:07:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/security/advisories/GHSA-j9wf-6r2x-hqmx"
},
{
"type": "PACKAGE",
"url": "https://github.com/centrifugal/centrifugo"
},
{
"type": "WEB",
"url": "https://github.com/centrifugal/centrifugo/releases/tag/v6.6.1"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Centrifugo v6.6.0 dependency vulnerabilities"
}
GHSA-M4GQ-X24J-JPMF
Vulnerability from github – Published: 2024-10-22 18:17 – Updated: 2024-10-23 14:24The following bundled files within the Mermaid NPM package contain a bundled version of DOMPurify that is vulnerable to https://github.com/cure53/DOMPurify/security/advisories/GHSA-mmhx-hmjr-r674, potentially resulting in an XSS attack.
This affects the built:
dist/mermaid.min.jsdist/mermaid.jsdist/mermaid.esm.mjsdist/mermaid.esm.min.mjs
This will also affect users that use the above files via a CDN link, e.g. https://cdn.jsdelivr.net/npm/mermaid@10.9.2/dist/mermaid.min.js
Users that use the default NPM export of mermaid, e.g. import mermaid from 'mermaid', or the dist/mermaid.core.mjs file, do not use this bundled version of DOMPurify, and can easily update using their package manager with something like npm audit fix.
Patches
developbranch: 6c785c93166c151d27d328ddf68a13d9d65adc00- backport to v10: 92a07ffe40aab2769dd1c3431b4eb5beac282b34
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 10.9.2"
},
"package": {
"ecosystem": "npm",
"name": "mermaid"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "10.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1321",
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-22T18:17:02Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The following bundled files within the Mermaid NPM package contain a bundled version of DOMPurify that is vulnerable to https://github.com/cure53/DOMPurify/security/advisories/GHSA-mmhx-hmjr-r674, potentially resulting in an XSS attack.\n\nThis affects the built:\n\n- `dist/mermaid.min.js`\n- `dist/mermaid.js`\n- `dist/mermaid.esm.mjs`\n- `dist/mermaid.esm.min.mjs`\n\nThis will also affect users that use the above files via a CDN link, e.g. `https://cdn.jsdelivr.net/npm/mermaid@10.9.2/dist/mermaid.min.js`\n\n**Users that use the default NPM export of `mermaid`, e.g. `import mermaid from \u0027mermaid\u0027`, or the `dist/mermaid.core.mjs` file, do not use this bundled version of DOMPurify, and can easily update using their package manager with something like `npm audit fix`.**\n\n### Patches\n\n- `develop` branch: 6c785c93166c151d27d328ddf68a13d9d65adc00\n- backport to v10: 92a07ffe40aab2769dd1c3431b4eb5beac282b34",
"id": "GHSA-m4gq-x24j-jpmf",
"modified": "2024-10-23T14:24:24Z",
"published": "2024-10-22T18:17:02Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-mmhx-hmjr-r674"
},
{
"type": "WEB",
"url": "https://github.com/mermaid-js/mermaid/security/advisories/GHSA-m4gq-x24j-jpmf"
},
{
"type": "WEB",
"url": "https://github.com/mermaid-js/mermaid/commit/6c785c93166c151d27d328ddf68a13d9d65adc00"
},
{
"type": "WEB",
"url": "https://github.com/mermaid-js/mermaid/commit/92a07ffe40aab2769dd1c3431b4eb5beac282b34"
},
{
"type": "PACKAGE",
"url": "https://github.com/mermaid-js/mermaid"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Prototype pollution vulnerability found in Mermaid\u0027s bundled version of DOMPurify"
}
GHSA-MGR7-5782-6JH9
Vulnerability from github – Published: 2025-01-13 16:18 – Updated: 2025-01-13 16:18Impact
The Heartcore headless client library depends on Refit to assist in making HTTP requests to Heartcore public APIs. Refit recently published an advisory regarding a CRLF injection vulnerability whereby it is possible for a malicious user to smuggle additional headers or potentially body content into a request.
This shouldn't affect Heartcore client library usage as the vulnerable method - HttpHeaders.TryAddWithoutValidation - is not used. However, since Refit is a transient dependency for applications using this library, then any users making direct use of Refit could be vulnerable.
Patches
The vulnerable version of Refit has been upgraded to a secure version, as of Umbraco.Headless.Client.Net version 1.5.0, available on Nuget.
Workarounds
If calling Refit from your own code, set any necessary HTTP headers without use of HttpHeaders.TryAddWithoutValidation.
References
See the original Refit advisory for further info.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.1"
},
"package": {
"ecosystem": "NuGet",
"name": "Umbraco.Headless.Client.Net"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-93"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-13T16:18:39Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "### Impact\nThe Heartcore headless client library depends on [Refit ](https://github.com/reactiveui/refit) to assist in making HTTP requests to Heartcore public APIs. Refit recently published an advisory regarding a CRLF injection vulnerability whereby it is possible for a malicious user to smuggle additional headers or potentially body content into a request.\n\nThis shouldn\u0027t affect Heartcore client library usage as the vulnerable method - `HttpHeaders.TryAddWithoutValidation` - is not used. However, since Refit is a transient dependency for applications using this library, then any users making direct use of Refit could be vulnerable.\n\n### Patches\nThe vulnerable version of Refit has been upgraded to a secure version, as of Umbraco.Headless.Client.Net version 1.5.0, available on [Nuget](https://www.nuget.org/packages/Umbraco.Headless.Client.Net/1.5.0).\n\n### Workarounds\nIf calling Refit from your own code, set any necessary HTTP headers without use of `HttpHeaders.TryAddWithoutValidation`.\n\n### References\nSee the [original Refit advisory](https://github.com/reactiveui/refit/security/advisories/GHSA-3hxg-fxwm-8gf7) for further info.\n",
"id": "GHSA-mgr7-5782-6jh9",
"modified": "2025-01-13T16:18:39Z",
"published": "2025-01-13T16:18:39Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/reactiveui/refit/security/advisories/GHSA-3hxg-fxwm-8gf7"
},
{
"type": "WEB",
"url": "https://github.com/umbraco/Umbraco.Headless.Client.Net/security/advisories/GHSA-mgr7-5782-6jh9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51501"
},
{
"type": "PACKAGE",
"url": "https://github.com/umbraco/Umbraco.Headless.Client.Net"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "The Umbraco Heartcore headless client library uses a vulnerable Refit dependency package"
}
GHSA-MJCP-GPGX-GGCG
Vulnerability from github – Published: 2025-12-09 22:48 – Updated: 2025-12-09 22:48When OpenTofu is acting as a TLS client authenticating a certificate chain provided by a TLS server, an excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard SANs in the leaf certificate.
For example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.
Details
When acting as a TLS client, OpenTofu relies on the implementation of TLS certificate verification from the standard library of the Go programming language.
The Go project has recently published the following advisory for that which indirectly affects OpenTofu's behavior:
- CVE-2025-61727: Improper application of excluded DNS name constraints when verifying wildcard names in crypto/x509
OpenTofu acts as a TLS client when calling a module or provider registry to request metadata, when downloading module or provider packages from "https" URLs, and when interacting with remote services for state storage and encryption. In these situations, OpenTofu could potentially accept as valid a certificate chain containing conflicting information about whether it is valid for the target hostname.
All certificates in the chain are still checked separately for validity, and so a successful attack requires an attacker-controlled server to produce a chain of valid-but-contradictory certificates and have access to the private keys associated with each one, and for the attacker to then arrange for OpenTofu to attempt to connect to the affected hostname.
Patches
OpenTofu v1.10.8 addresses these vulnerabilities by being built against Go 1.24.11, which contains an improved version of the upstream implementation.
The OpenTofu v1.9 and v1.8 series are also affected by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.11 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.8 in the near future.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/opentofu/opentofu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.10.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-296"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-09T22:48:08Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "When OpenTofu is acting as a TLS client authenticating a certificate chain provided by a TLS server, an excluded subdomain constraint in a certificate chain does not restrict the usage of wildcard [SANs](https://en.wikipedia.org/wiki/Public_key_certificate#Subject_Alternative_Name_certificate) in the leaf certificate.\n\nFor example a constraint that excludes the subdomain test.example.com does not prevent a leaf certificate from claiming the SAN *.example.com.\n\n### Details\n\nWhen acting as a TLS client, OpenTofu relies on the implementation of TLS certificate verification from the standard library of the Go programming language.\n\nThe Go project has recently published the following advisory for that which indirectly affects OpenTofu\u0027s behavior:\n\n- [CVE-2025-61727](https://www.cve.org/CVERecord?id=CVE-2025-61727): Improper application of excluded DNS name constraints when verifying wildcard names in crypto/x509\n\nOpenTofu acts as a TLS client when calling a module or provider registry to request metadata, when downloading module or provider packages from \"https\" URLs, and when interacting with remote services for state storage and encryption. In these situations, OpenTofu could potentially accept as valid a certificate chain containing conflicting information about whether it is valid for the target hostname.\n\nAll certificates in the chain are still checked separately for validity, and so a successful attack requires an attacker-controlled server to produce a chain of valid-but-contradictory certificates and have access to the private keys associated with each one, and for the attacker to then arrange for OpenTofu to attempt to connect to the affected hostname.\n\n### Patches\n\nOpenTofu v1.10.8 addresses these vulnerabilities by being built against Go 1.24.11, which contains an improved version of the upstream implementation.\n\nThe OpenTofu v1.9 and v1.8 series are also affected by these vulnerabilities. However, those series are built with a version of Go for which no upstream fix is available. Adopting Go 1.24.11 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.8 in the near future.",
"id": "GHSA-mjcp-gpgx-ggcg",
"modified": "2025-12-09T22:48:08Z",
"published": "2025-12-09T22:48:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/security/advisories/GHSA-mjcp-gpgx-ggcg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-61727"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/issues/3546"
},
{
"type": "PACKAGE",
"url": "https://github.com/opentofu/opentofu"
},
{
"type": "WEB",
"url": "https://github.com/opentofu/opentofu/releases/tag/v1.10.8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenTofu incorrectly validates excluded subdomain constraint in conjunction with TLS certificates containing wildcard SANs"
}
GHSA-MRXW-MXHJ-P664
Vulnerability from github – Published: 2025-03-14 18:51 – Updated: 2025-03-21 15:43Summary
Nokogiri v1.18.4 upgrades its dependency libxslt to v1.1.43.
libxslt v1.1.43 resolves:
- CVE-2025-24855: Fix use-after-free of XPath context node
- CVE-2024-55549: Fix UAF related to excluded namespaces
Impact
CVE-2025-24855
- "Use-after-free due to xsltEvalXPathStringNs leaking xpathCtxt->node"
- MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
- Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/128
- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2025-24855
CVE-2024-55549
- "Use-after-free related to excluded result prefixes"
- MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H
- Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127
- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2024-55549
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "nokogiri"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-416"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-14T18:51:37Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nNokogiri v1.18.4 upgrades its dependency libxslt to [v1.1.43](https://gitlab.gnome.org/GNOME/libxslt/-/releases/v1.1.43).\n\nlibxslt v1.1.43 resolves:\n\n- CVE-2025-24855: Fix use-after-free of XPath context node\n- CVE-2024-55549: Fix UAF related to excluded namespaces\n\n## Impact\n\n### CVE-2025-24855\n\n- \"Use-after-free due to xsltEvalXPathStringNs leaking xpathCtxt-\u003enode\"\n- MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H\n- Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/128\n- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2025-24855\n\n### CVE-2024-55549\n\n- \"Use-after-free related to excluded result prefixes\"\n- MITRE has rated this 7.8 High CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H\n- Upstream report: https://gitlab.gnome.org/GNOME/libxslt/-/issues/127\n- NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2024-55549",
"id": "GHSA-mrxw-mxhj-p664",
"modified": "2025-03-21T15:43:15Z",
"published": "2025-03-14T18:51:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sparklemotion/nokogiri/security/advisories/GHSA-mrxw-mxhj-p664"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55549"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24855"
},
{
"type": "PACKAGE",
"url": "https://github.com/sparklemotion/nokogiri"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libxslt/-/issues/127"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/GNOME/libxslt/-/issues/128"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Nokogiri updates packaged libxslt to v1.1.43 to resolve multiple CVEs"
}
GHSA-MWV6-3258-Q52C
Vulnerability from github – Published: 2025-12-11 22:49 – Updated: 2025-12-11 22:49A 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-55184.
A malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "next"
},
"ranges": [
{
"events": [
{
"introduced": "13.3.0"
},
{
"fixed": "14.2.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"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-400",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-11T22:49:27Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"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-55184](https://www.cve.org/CVERecord?id=CVE-2025-55184).\n\nA malicious HTTP request can be crafted and sent to any App Router endpoint that, when deserialized, can cause the server process to hang and consume CPU. This can result in denial of service in unpatched environments.",
"id": "GHSA-mwv6-3258-q52c",
"modified": "2025-12-11T22:49:28Z",
"published": "2025-12-11T22:49:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/vercel/next.js/security/advisories/GHSA-mwv6-3258-q52c"
},
{
"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-55184"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Next Vulnerable to Denial of Service with Server Components"
}
GHSA-P2Q9-36VW-C468
Vulnerability from github – Published: 2024-09-03 21:11 – Updated: 2024-09-03 21:11After several cryptographic vulnerabilities in libolm were disclosed publicly, the Matrix Foundation has officially deprecated the library. olm-sys is a thin wrapper around libolm and is now deprecated and potentially vulnerable in kind.
Users of olm-sys and its higher-level abstraction, olm-rs, are highly encouraged to switch to vodozemac as soon as possible. It is the successor effort to libolm and is written in Rust.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "olm-sys"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-03T21:11:21Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "After several cryptographic vulnerabilities in `libolm` were disclosed publicly, the Matrix Foundation has [officially deprecated the library](https://matrix.org/blog/2024/08/libolm-deprecation/). `olm-sys` is a thin wrapper around `libolm` and is now deprecated and potentially vulnerable in kind.\n\nUsers of `olm-sys` and its higher-level abstraction, `olm-rs`, are highly encouraged to switch to [`vodozemac`](https://crates.io/crates/vodozemac) as soon as possible. It is the successor effort to `libolm` and is written in Rust.\n",
"id": "GHSA-p2q9-36vw-c468",
"modified": "2024-09-03T21:11:21Z",
"published": "2024-09-03T21:11:21Z",
"references": [
{
"type": "PACKAGE",
"url": "https://gitlab.gnome.org/BrainBlasted/olm-sys"
},
{
"type": "WEB",
"url": "https://gitlab.gnome.org/BrainBlasted/olm-sys/-/issues/12"
},
{
"type": "WEB",
"url": "https://matrix.org/blog/2024/08/libolm-deprecation"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0368.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "olm-sys: wrapped library unmaintained, potentially vulnerable"
}
GHSA-Q382-VC8Q-7JHJ
Vulnerability from github – Published: 2026-03-19 12:44 – Updated: 2026-03-19 12:44The Go SDK recently transitioned to the segmentio/encoding library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with null Unicode characters appended at the end as equivalent to their base strings.
Impact
When combined with duplicate keys, the described behavior leads to a "last key wins" resolution that could override the intended MCP message. This had the potential for: - Bypassing intermediary inspection: Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages. - Cross-implementation inconsistency: Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.
Fix:
The segmentio/encoding package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (v0.5.4). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.
Credits:
Thank you to Francesco Lacerenza (Doyensec) for reporting this issue.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.4.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/modelcontextprotocol/go-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-19T12:44:07Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "The Go SDK recently transitioned to the `segmentio/encoding` library for JSON parsing in version 1.3.1. While this change addressed both case-insensitivity and ASCII folding issues, the new parser implemented aggressive key matching that treated keys with `null` Unicode characters appended at the end as equivalent to their base strings.\n\n#### Impact\n\nWhen combined with duplicate keys, the described behavior leads to a \"last key wins\" resolution that could override the intended MCP message. This had the potential for:\n - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.\n - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.\n\n#### Fix:\n\nThe `segmentio/encoding` package was patched with a fix in https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb and a new version of the package was released (`v0.5.4`). The SDK switched to the patched version of the dependency in 724dd47aa. Users are advised to update to v1.4.1 to resolve this issue.\n\n#### Credits:\nThank you to Francesco Lacerenza (Doyensec) for reporting this issue.",
"id": "GHSA-q382-vc8q-7jhj",
"modified": "2026-03-19T12:44:07Z",
"published": "2026-03-19T12:44:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/security/advisories/GHSA-q382-vc8q-7jhj"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/commit/724dd47aa3431b9d4cf9ac2eebbf7b38a629afca"
},
{
"type": "WEB",
"url": "https://github.com/segmentio/encoding/commit/7d5a25dbc5da13aed3cb047a127e4d0e96f536fb"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/go-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Improper handling of null Unicode character when parsing JSON in github.com/modelcontextprotocol/go-sdk"
}
Mitigation
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
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
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
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
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.