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.
110 vulnerabilities reference this CWE, most recent first.
GHSA-GGPF-24JW-3FCW
Vulnerability from github – Published: 2025-04-23 02:26 – Updated: 2025-04-23 02:26Description
https://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54 reported a vulnerability where loading a malicious model could result in code execution on the vllm host. The fix applied to specify weights_only=True to calls to torch.load() did not solve the problem prior to PyTorch 2.6.0.
PyTorch has issued a new CVE about this problem: https://github.com/advisories/GHSA-53q9-r3pm-6pq6
This means that versions of vLLM using PyTorch before 2.6.0 are vulnerable to this problem.
Background Knowledge
When users install VLLM according to the official manual
But the version of PyTorch is specified in the requirements. txt file
So by default when the user install VLLM, it will install the PyTorch with version 2.5.1
In CVE-2025-24357, weights_only=True was used for patching, but we know this is not secure. Because we found that using Weights_only=True in pyTorch before 2.5.1 was unsafe
Here, we use this interface to prove that it is not safe.
Fix
update PyTorch version to 2.6.0
Credit
This vulnerability was found By Ji'an Zhou and Li'shuo Song
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.8.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-23T02:26:06Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Description\n\nhttps://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54 reported a vulnerability where loading a malicious model could result in code execution on the vllm host. The fix applied to specify `weights_only=True` to calls to `torch.load()` did not solve the problem prior to PyTorch 2.6.0.\n\nPyTorch has issued a new CVE about this problem: https://github.com/advisories/GHSA-53q9-r3pm-6pq6\n\nThis means that versions of vLLM using PyTorch before 2.6.0 are vulnerable to this problem.\n## Background Knowledge\nWhen users install VLLM according to the official manual\n\n\nBut the version of PyTorch is specified in the requirements. txt file\n\n\nSo by default when the user install VLLM, it will install the PyTorch with version 2.5.1\n\n\nIn CVE-2025-24357, weights_only=True was used for patching, but we know this is not secure.\nBecause we found that using Weights_only=True in pyTorch before 2.5.1 was unsafe\n\nHere, we use this interface to prove that it is not safe.\n\n\n\n## Fix\nupdate PyTorch version to 2.6.0\n\n## Credit\nThis vulnerability was found By Ji\u0027an Zhou and Li\u0027shuo Song",
"id": "GHSA-ggpf-24jw-3fcw",
"modified": "2025-04-23T02:26:06Z",
"published": "2025-04-23T02:26:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pytorch/pytorch/security/advisories/GHSA-53q9-r3pm-6pq6"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-ggpf-24jw-3fcw"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-rh4j-5rhw-hr54"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
}
],
"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": "CVE-2025-24357 Malicious model remote code execution fix bypass with PyTorch \u003c 2.6.0"
}
GHSA-GV8R-9RW9-9697
Vulnerability from github – Published: 2026-02-20 21:14 – Updated: 2026-03-11 20:35Summary
There is a potential vulnerability in Traefik managing HTTP/3 connections.
More details in the CVE-2025-68121.
Patches
- https://github.com/traefik/traefik/releases/tag/v2.11.37
- https://github.com/traefik/traefik/releases/tag/v3.6.8
Workarounds
No workaround
For more information
If you have any questions or comments about this advisory, please open an issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.7.34"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.11.36"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.11.37"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.6.7"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.6.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-20T21:14:27Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nThere is a potential vulnerability in Traefik managing HTTP/3 connections.\n\nMore details in the [CVE-2025-68121](https://nvd.nist.gov/vuln/detail/CVE-2025-68121).\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v2.11.37\n- https://github.com/traefik/traefik/releases/tag/v3.6.8\n\n## Workarounds\n\nNo workaround\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).",
"id": "GHSA-gv8r-9rw9-9697",
"modified": "2026-03-11T20:35:09Z",
"published": "2026-02-20T21:14:27Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-gv8r-9rw9-9697"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik affected by TLS ClientAuth Bypass on HTTP/3"
}
GHSA-H2RP-8VPX-Q9R4
Vulnerability from github – Published: 2025-03-13 16:26 – Updated: 2025-03-13 16:26Description
There have been two upstream security advisories and associated patches published under ISA-2025-001 and ISA-2025-002.
ISA-2025-001 affects the IBC-Go package., where non-deterministic JSON unmarshalling of IBC Acknowledgements can result in a chain halt.
ISA-2025-002 affects the Cosmos SDK package, where x/group can halt when erroring in EndBlocker.
Impact
If unaddressed, this could result in a chain halt.
Patches
Validators, full nodes, and IBC relayers should upgrade to cheqd-node v3.1.8. This upgrade does not require a software upgrade proposal on-chain and is meant to be non state-breaking.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/cheqd/cheqd-node"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-13T16:26:11Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "# Description\n\nThere have been two upstream security advisories and associated patches published under [ISA-2025-001](https://github.com/cosmos/ibc-go/security/advisories/GHSA-4wf3-5qj9-368v) and [ISA-2025-002](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-47ww-ff84-4jrg).\n\n**[ISA-2025-001](https://github.com/cosmos/ibc-go/security/advisories/GHSA-4wf3-5qj9-368v)** affects the IBC-Go package., where non-deterministic JSON unmarshalling of IBC Acknowledgements can result in a chain halt. \n\n**[ISA-2025-002](https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-47ww-ff84-4jrg)** affects the Cosmos SDK package, where `x/group` can halt when erroring in `EndBlocker`.\n\n### Impact\nIf unaddressed, this could result in a chain halt.\n\n### Patches\nValidators, full nodes, and IBC relayers should upgrade to [cheqd-node v3.1.8](https://github.com/cheqd/cheqd-node/releases/tag/v3.1.8). This upgrade does not require a software upgrade proposal on-chain and is meant to be non state-breaking.",
"id": "GHSA-h2rp-8vpx-q9r4",
"modified": "2025-03-13T16:26:11Z",
"published": "2025-03-13T16:26:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cheqd/cheqd-node/security/advisories/GHSA-h2rp-8vpx-q9r4"
},
{
"type": "WEB",
"url": "https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-47ww-ff84-4jrg"
},
{
"type": "WEB",
"url": "https://github.com/cosmos/ibc-go/security/advisories/GHSA-4wf3-5qj9-368v"
},
{
"type": "WEB",
"url": "https://github.com/cheqd/cheqd-node/commit/5a58b08dfb8dfc24631fb85b641cb75e9178d07f"
},
{
"type": "PACKAGE",
"url": "https://github.com/cheqd/cheqd-node"
},
{
"type": "WEB",
"url": "https://github.com/cheqd/cheqd-node/releases/tag/v3.1.8"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "cheqd-node Security patch for upstream vulnerabilities in IBC-Go (ISA-2025-001) and Cosmos SDK (ISA-2025-002)"
}
GHSA-H4GH-QQ45-VH27
Vulnerability from github – Published: 2024-09-03 21:59 – Updated: 2024-09-03 21:59pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 37.0.0-43.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20240903.txt.
If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "37.0.0"
},
{
"fixed": "43.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-03T21:59:48Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "pyca/cryptography\u0027s wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 37.0.0-43.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20240903.txt.\n\nIf you are building cryptography source (\"sdist\") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.\n",
"id": "GHSA-h4gh-qq45-vh27",
"modified": "2024-09-03T21:59:48Z",
"published": "2024-09-03T21:59:48Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pyca/cryptography/security/advisories/GHSA-h4gh-qq45-vh27"
},
{
"type": "PACKAGE",
"url": "https://github.com/pyca/cryptography"
},
{
"type": "WEB",
"url": "https://openssl-library.org/news/secadv/20240903.txt"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "pyca/cryptography has a vulnerable OpenSSL included in cryptography wheels"
}
GHSA-H8W2-RV57-VC6F
Vulnerability from github – Published: 2026-03-26 17:22 – Updated: 2026-03-26 17:22In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. An attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution. All three of the following conditions must be true to exploit this vulnerability:
1. Splunk Distribution of OpenTelemetry Java is attached as a Java agent (-javaagent)
2. An RMI endpoint is network-reachable (e.g. JMX remote port, an RMI registry, or any application-exported RMI service)
3. A gadget-chain-compatible library is present on the classpath
Impact
Arbitrary remote code execution with the privileges of the user running the instrumented JVM.
Recommendation
Upgrade to version 2.26.1 or later.
Workarounds
Set the following system property to disable the RMI integration:
-Dotel.instrumentation.rmi.enabled=false
References
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.splunk:splunk-otel-javaagent"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.26.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-502"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-26T17:22:53Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "In versions prior to 2.26.1, the RMI instrumentation registered a custom endpoint that deserialized incoming data without applying serialization filters. An attacker with network access to a JMX or RMI port on an instrumented JVM could exploit this to potentially achieve remote code execution.\u00a0All three of the following conditions must be true to exploit this vulnerability:\n1. Splunk Distribution of OpenTelemetry Java is attached as a Java agent (`-javaagent`)\n2. An RMI endpoint is network-reachable (e.g. JMX remote port, an RMI registry, or any application-exported RMI service)\n3. A gadget-chain-compatible library is present on the classpath\n\n### Impact\nArbitrary remote code execution with the privileges of the user running the instrumented JVM.\n\n### Recommendation\nUpgrade to version 2.26.1 or later.\n\n### Workarounds\nSet the following system property to disable the RMI integration:\n\n```\n-Dotel.instrumentation.rmi.enabled=false\n```\n\n### References\n[Advisory in OpenTelemetry Instrumentation for Java](https://github.com/open-telemetry/opentelemetry-java-instrumentation/security/advisories/GHSA-xw7x-h9fj-p2c7)",
"id": "GHSA-h8w2-rv57-vc6f",
"modified": "2026-03-26T17:22:54Z",
"published": "2026-03-26T17:22:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-telemetry/opentelemetry-java-instrumentation/security/advisories/GHSA-xw7x-h9fj-p2c7"
},
{
"type": "WEB",
"url": "https://github.com/signalfx/splunk-otel-java/security/advisories/GHSA-h8w2-rv57-vc6f"
},
{
"type": "PACKAGE",
"url": "https://github.com/signalfx/splunk-otel-java"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "splunk-otel-javaagent: Unsafe deserialization in RMI instrumentation may lead to Remote Code Execution"
}
GHSA-HF3C-WXG2-49Q9
Vulnerability from github – Published: 2025-04-15 21:21 – Updated: 2025-04-15 21:21Impact
This report is to highlight a vulnerability in XGrammar, a library used by the structured output feature in vLLM. The XGrammar advisory is here: https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3
The xgrammar library is the default backend used by vLLM to support structured output (a.k.a. guided decoding). Xgrammar provides a required, built-in cache for its compiled grammars stored in RAM. xgrammar is available by default through the OpenAI compatible API server with both the V0 and V1 engines.
A malicious user can send a stream of very short decoding requests with unique schemas, resulting in an addition to the cache for each request. This can result in a Denial of Service by consuming all of the system's RAM.
Note that even if vLLM was configured to use a different backend by default, it is still possible to choose xgrammar on a per-request basis using the guided_decoding_backend key of the extra_body field of the request with the V0 engine. This per-request choice is not available when using the V1 engine.
Patches
- https://github.com/vllm-project/vllm/pull/16283
Workarounds
There is no way to workaround this issue in existing versions of vLLM other than preventing untrusted access to the OpenAI compatible API server.
References
- https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "vllm"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.5"
},
{
"fixed": "0.8.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-1395",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-04-15T21:21:04Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\nThis report is to highlight a vulnerability in XGrammar, a library used by the structured output feature in vLLM. The XGrammar advisory is here: https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3\n\nThe [xgrammar](https://xgrammar.mlc.ai/docs/) library is the default backend used by vLLM to support structured output (a.k.a. guided decoding). Xgrammar provides a required, built-in cache for its compiled grammars stored in RAM. xgrammar is available by default through the OpenAI compatible API server with both the V0 and V1 engines.\n\nA malicious user can send a stream of very short decoding requests with unique schemas, resulting in an addition to the cache for each request. This can result in a Denial of Service by consuming all of the system\u0027s RAM.\n\nNote that even if vLLM was configured to use a different backend by default, it is still possible to choose xgrammar on a per-request basis using the `guided_decoding_backend` key of the `extra_body` field of the request with the V0 engine. This per-request choice is not available when using the V1 engine. \n### Patches\n\n* https://github.com/vllm-project/vllm/pull/16283\n\n### Workarounds\n\nThere is no way to workaround this issue in existing versions of vLLM other than preventing untrusted access to the OpenAI compatible API server.\n\n### References\n\n* https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3",
"id": "GHSA-hf3c-wxg2-49q9",
"modified": "2025-04-15T21:21:04Z",
"published": "2025-04-15T21:21:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mlc-ai/xgrammar/security/advisories/GHSA-389x-67px-mjg3"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/security/advisories/GHSA-hf3c-wxg2-49q9"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/pull/16283"
},
{
"type": "WEB",
"url": "https://github.com/vllm-project/vllm/commit/cb84e45ac75b42ba6795145923e8eb323bb825ad"
},
{
"type": "PACKAGE",
"url": "https://github.com/vllm-project/vllm"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "vLLM vulnerable to Denial of Service by abusing xgrammar cache"
}
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"
}
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.