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.
118 vulnerabilities reference this CWE, most recent first.
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"
}
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"
}
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.