CWE-130
AllowedImproper Handling of Length Parameter Inconsistency
Abstraction: Base · Status: Incomplete
The product parses a formatted message or structure, but it does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data.
187 vulnerabilities reference this CWE, most recent first.
GHSA-MHVP-2G8X-V832
Vulnerability from github – Published: 2025-05-27 18:30 – Updated: 2025-06-02 18:30NVIDIA CUDA Toolkit for all platforms contains a vulnerability in the cuobjdump binary, where a failure to check the length of a buffer could allow a user to cause the tool to crash or execute arbitrary code by passing in a malformed ELF file. A successful exploit of this vulnerability might lead to arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2025-23247"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-27T17:15:25Z",
"severity": "MODERATE"
},
"details": "NVIDIA CUDA Toolkit for all platforms contains a vulnerability in the cuobjdump binary, where a failure to check the length of a buffer could allow a user to cause the tool to crash or execute arbitrary code by passing in a malformed ELF file. A successful exploit of this vulnerability might lead to arbitrary code execution.",
"id": "GHSA-mhvp-2g8x-v832",
"modified": "2025-06-02T18:30:32Z",
"published": "2025-05-27T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23247"
},
{
"type": "WEB",
"url": "https://nvidia.custhelp.com/app/answers/detail/a_id/5643"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2025-2151"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-MPJ3-4VV5-G8QC
Vulnerability from github – Published: 2022-05-24 17:28 – Updated: 2023-12-12 21:31Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software parses a formatted message or structure but does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data, causing the application on the surveillance station to restart.
{
"affected": [],
"aliases": [
"CVE-2020-16224"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-09-11T14:15:00Z",
"severity": "LOW"
},
"details": "Patient Information Center iX (PICiX) Versions B.02, C.02, C.03, PerformanceBridge Focal Point Version A.01, IntelliVue patient monitors MX100, MX400-MX850, and MP2-MP90 Versions N and prior, IntelliVue X3 and X2 Versions N and prior. The software parses a formatted message or structure but does not handle or incorrectly handles a length field that is inconsistent with the actual length of the associated data, causing the application on the surveillance station to restart.",
"id": "GHSA-mpj3-4vv5-g8qc",
"modified": "2023-12-12T21:31:06Z",
"published": "2022-05-24T17:28:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-16224"
},
{
"type": "WEB",
"url": "https://us-cert.cisa.gov/ics/advisories/icsma-20-254-01"
},
{
"type": "WEB",
"url": "https://www.philips.com/productsecurity"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PV7R-9VJG-G3F9
Vulnerability from github – Published: 2022-02-11 00:00 – Updated: 2023-06-19 17:00Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pgfx-g6rc-8cjv. This link is maintained to preserve external references.
Original Description
A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HTTP/2 frame. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. This vulnerability is caused by a logical error when parsing a HTTP/2 HEADERS frame where the frame contains priority information without any other data. This logical error caused confusion about the size of the frame, leading to a parsing error. This parsing error immediately crashes the entire process. Sending a HEADERS frame with HTTP/2 priority information does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted frame. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the frame in memory-safe code, so the crash is safe. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.
{
"affected": [
{
"package": {
"ecosystem": "SwiftURL",
"name": "github.com/apple/swift-nio-http2"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.19.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-19T17:00:46Z",
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of GHSA-pgfx-g6rc-8cjv. This link is maintained to preserve external references.\n\n## Original Description\n\nA program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HTTP/2 frame. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. This vulnerability is caused by a logical error when parsing a HTTP/2 HEADERS frame where the frame contains priority information without any other data. This logical error caused confusion about the size of the frame, leading to a parsing error. This parsing error immediately crashes the entire process. Sending a HEADERS frame with HTTP/2 priority information does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted frame. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the frame in memory-safe code, so the crash is safe. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.",
"id": "GHSA-pv7r-9vjg-g3f9",
"modified": "2023-06-19T17:00:46Z",
"published": "2022-02-11T00:00:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/apple/swift-nio-http2/security/advisories/GHSA-ccw9-q5h2-8c2w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24666"
},
{
"type": "PACKAGE",
"url": "https://github.com/apple/swift-nio-http2"
}
],
"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": "Duplicate advisory: swift-nio-http2 vulnerable to denial of service via invalid HTTP/2 HEADERS frame length",
"withdrawn": "2023-06-19T17:00:46Z"
}
GHSA-Q2WW-5357-X388
Vulnerability from github – Published: 2026-04-02 20:36 – Updated: 2026-05-13 16:19Summary
Rack::Files#fail sets the Content-Length response header using String#size instead of String#bytesize. When the response body contains multibyte UTF-8 characters, the declared Content-Length is smaller than the number of bytes actually sent on the wire.
Because Rack::Files reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.
This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect Content-Length value.
Details
Rack::Files#fail constructs error responses using logic equivalent to:
def fail(status, body, headers = {})
body += "\n"
[
status,
{
"content-type" => "text/plain",
"content-length" => body.size.to_s,
"x-cascade" => "pass"
}.merge!(headers),
[body]
]
end
Here, body.size returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect Content-Length value.
Rack::Files includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the Content-Length header still reflects character count rather than byte count.
As a result, the server can send more bytes than declared in the response headers.
This violates HTTP message framing requirements, which define Content-Length as the number of octets in the message body.
Impact
Applications using Rack::Files may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.
In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on Content-Length, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.
Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.
Mitigation
- Update to a patched version of Rack that computes
Content-LengthusingString#bytesize. - Avoid exposing
Rack::Filesdirectly to untrusted traffic until a fix is available, if operationally feasible. - Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
- Prefer closing backend connections on error paths if response framing anomalies are a concern.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.2.23"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0.beta1"
},
{
"fixed": "3.1.21"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "rack"
},
"ranges": [
{
"events": [
{
"introduced": "3.2.0"
},
{
"fixed": "3.2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34831"
],
"database_specific": {
"cwe_ids": [
"CWE-130",
"CWE-135"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-02T20:36:10Z",
"nvd_published_at": "2026-04-02T17:16:26Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.\n\nBecause `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.\n\nThis results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.\n\n## Details\n\n`Rack::Files#fail` constructs error responses using logic equivalent to:\n\n```ruby\ndef fail(status, body, headers = {})\n body += \"\\n\"\n [\n status,\n {\n \"content-type\" =\u003e \"text/plain\",\n \"content-length\" =\u003e body.size.to_s,\n \"x-cascade\" =\u003e \"pass\"\n }.merge!(headers),\n [body]\n ]\nend\n```\n\nHere, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.\n\n`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.\n\nAs a result, the server can send more bytes than declared in the response headers.\n\nThis violates HTTP message framing requirements, which define `Content-Length` as the number of octets in the message body.\n\n## Impact\n\nApplications using `Rack::Files` may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.\n\nIn some deployment topologies, particularly with keep-alive connections and intermediaries that rely on `Content-Length`, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.\n\nEven where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.\n\n## Mitigation\n\n* Update to a patched version of Rack that computes `Content-Length` using `String#bytesize`.\n* Avoid exposing `Rack::Files` directly to untrusted traffic until a fix is available, if operationally feasible.\n* Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.\n* Prefer closing backend connections on error paths if response framing anomalies are a concern.",
"id": "GHSA-q2ww-5357-x388",
"modified": "2026-05-13T16:19:10Z",
"published": "2026-04-02T20:36:10Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rack/rack/security/advisories/GHSA-q2ww-5357-x388"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34831"
},
{
"type": "PACKAGE",
"url": "https://github.com/rack/rack"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2026-34831.yml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Rack has Content-Length mismatch in Rack::Files error responses"
}
GHSA-Q5R4-CFPX-H6FH
Vulnerability from github – Published: 2021-08-02 16:56 – Updated: 2022-02-08 21:08When reading a specially crafted TAR archive an Apache Ant build can be made to allocate large amounts of memory that finally leads to an out of memory error, even for small inputs. This can be used to disrupt builds using Apache Ant. Apache Ant prior to 1.9.16 and 1.10.11 were affected.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.ant:ant"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.ant:ant"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.11"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-36373"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": true,
"github_reviewed_at": "2021-07-15T19:15:21Z",
"nvd_published_at": "2021-07-14T07:15:00Z",
"severity": "MODERATE"
},
"details": "When reading a specially crafted TAR archive an Apache Ant build can be made to allocate large amounts of memory that finally leads to an out of memory error, even for small inputs. This can be used to disrupt builds using Apache Ant. Apache Ant prior to 1.9.16 and 1.10.11 were affected.",
"id": "GHSA-q5r4-cfpx-h6fh",
"modified": "2022-02-08T21:08:16Z",
"published": "2021-08-02T16:56:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36373"
},
{
"type": "WEB",
"url": "https://ant.apache.org/security.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r27919fd4db07c487239c1d9771f480d89ce5ee2750aa9447309b709a@%3Ccommits.groovy.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r544c9e8487431768465b8b2d13982c75123109bd816acf839d46010d@%3Ccommits.groovy.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r54afdab05e01de970649c2d91a993f68a6b00cd73e6e34e16c832d46%40%3Cuser.ant.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rad36f470647c5a7c02dd78c9973356d2840766d132b597b6444e373a@%3Cnotifications.groovy.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf4bb79751a02889623195715925e4fd8932dd3c97e0ade91395a96c6@%3Cdev.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210819-0007"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Improper Handling of Length Parameter Inconsistency in Apache Ant"
}
GHSA-QC2X-6F54-M6H9
Vulnerability from github – Published: 2026-06-22 23:07 – Updated: 2026-06-22 23:07Impact
_read_character_string and _read_string in src/zeroconf/_protocol/incoming.py sliced self.data[self.offset : self.offset + length] and advanced self.offset by the declared length without checking it against self._data_len. Python's slice silently returns fewer bytes when the end index runs past the buffer, so a record whose 16-bit RDLENGTH (RFC 1035 §3.2.1) over-advertised by tens of kilobytes was constructed from a truncated payload, appended to DNSIncoming._answers, and committed to the cache before any later parse failure surfaced. The follow-up _read_name for the next record then failed, but the corrupt record had already entered the answer list and propagated to DNSCache and ServiceInfo.
Any unauthenticated host on the local link (UDP/5353, 224.0.0.251 / ff02::fb) can multicast a single mDNS response carrying a TXT, HINFO, or A/AAAA record that advertises rdlength=65535 and only a handful of real payload bytes; consumers calling ServiceInfo.properties then parse the truncated bytes as if they matched the wire, and downstream integrations (Home Assistant and other zeroconf-driven discovery) trust the decoded record. The bug is parser-state desync rather than RCE, but it seeds the cache with attacker-shaped key/value and address records for a TTL window and is a building block for higher-impact chains.
The impact is likely lower than the other recently released advisories as there is no additional risk of OOM so the severity was manually set to low to override the score CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (6.5, Medium) since that doesn't fully consider the mDNS threat model.
Patches
Fixed in zeroconf 0.149.16 (PR #1756). Note that this change originally intended to ship in 0.149.13 but we ran out of space on PyPI: see https://github.com/python-zeroconf/python-zeroconf/issues/1769
Upgrade to >= 0.149.16.
Workarounds
There is no in-process workaround; upgrading is the fix. Otherwise, restrict mDNS (UDP/5353) to trusted Layer-2 segments via AP client isolation, guest-network separation, or host firewall rules.
Resources
- PR #1756, fix
- Issue #1752, public tracking issue
- RFC 1035 §3.2.1, RFC 1035 §3.3, CWE-130
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "zeroconf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.149.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48487"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-22T23:07:44Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Impact\n\n`_read_character_string` and `_read_string` in `src/zeroconf/_protocol/incoming.py` sliced `self.data[self.offset : self.offset + length]` and advanced `self.offset` by the declared `length` without checking it against `self._data_len`. Python\u0027s slice silently returns fewer bytes when the end index runs past the buffer, so a record whose 16-bit RDLENGTH (RFC 1035 \u00a73.2.1) over-advertised by tens of kilobytes was constructed from a truncated payload, appended to `DNSIncoming._answers`, and committed to the cache before any later parse failure surfaced. The follow-up `_read_name` for the next record then failed, but the corrupt record had already entered the answer list and propagated to `DNSCache` and `ServiceInfo`.\n\nAny unauthenticated host on the local link (UDP/5353, `224.0.0.251` / `ff02::fb`) can multicast a single mDNS response carrying a TXT, HINFO, or A/AAAA record that advertises rdlength=65535 and only a handful of real payload bytes; consumers calling `ServiceInfo.properties` then parse the truncated bytes as if they matched the wire, and downstream integrations (Home Assistant and other zeroconf-driven discovery) trust the decoded record. The bug is parser-state desync rather than RCE, but it seeds the cache with attacker-shaped key/value and address records for a TTL window and is a building block for higher-impact chains.\n\nThe impact is likely lower than the other recently released advisories as there is no additional risk of OOM so the severity was manually set to low to override the score CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (6.5, Medium) since that doesn\u0027t fully consider the mDNS threat model.\n\n### Patches\n\nFixed in `zeroconf` 0.149.16 ([PR #1756](https://github.com/python-zeroconf/python-zeroconf/pull/1756)). Note that this change originally intended to ship in 0.149.13 but we ran out of space on PyPI: see https://github.com/python-zeroconf/python-zeroconf/issues/1769\n\nUpgrade to `\u003e= 0.149.16`.\n\n### Workarounds\n\nThere is no in-process workaround; upgrading is the fix. Otherwise, restrict mDNS (UDP/5353) to trusted Layer-2 segments via AP client isolation, guest-network separation, or host firewall rules.\n\n### Resources\n\n- [PR #1756](https://github.com/python-zeroconf/python-zeroconf/pull/1756), fix\n- [Issue #1752](https://github.com/python-zeroconf/python-zeroconf/issues/1752), public tracking issue\n- [RFC 1035 \u00a73.2.1](https://www.rfc-editor.org/rfc/rfc1035#section-3.2.1), [RFC 1035 \u00a73.3](https://www.rfc-editor.org/rfc/rfc1035#section-3.3), [CWE-130](https://cwe.mitre.org/data/definitions/130.html)",
"id": "GHSA-qc2x-6f54-m6h9",
"modified": "2026-06-22T23:07:44Z",
"published": "2026-06-22T23:07:44Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-zeroconf/python-zeroconf/security/advisories/GHSA-qc2x-6f54-m6h9"
},
{
"type": "WEB",
"url": "https://github.com/python-zeroconf/python-zeroconf/issues/1752"
},
{
"type": "WEB",
"url": "https://github.com/python-zeroconf/python-zeroconf/pull/1756"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-zeroconf/python-zeroconf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "zeroconf: Unvalidated rdlength in record payload readers allows LAN-local cache corruption via crafted mDNS packet"
}
GHSA-QCJ7-GQXF-2CQQ
Vulnerability from github – Published: 2026-05-04 12:30 – Updated: 2026-09-03 15:31A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.
{
"affected": [],
"aliases": [
"CVE-2026-33846"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-04T10:15:59Z",
"severity": "HIGH"
},
"details": "A heap buffer overflow vulnerability exists in the DTLS handshake fragment reassembly logic of GnuTLS. The issue arises in merge_handshake_packet() where incoming handshake fragments are matched and merged based solely on handshake type, without validating that the message_length field remains consistent across all fragments of the same logical message. An attacker can exploit this by sending crafted DTLS fragments with conflicting message_length values, causing the implementation to allocate a buffer based on a smaller initial fragment and subsequently write beyond its bounds using larger, inconsistent fragments. Because the merge operation does not enforce proper bounds checking against the allocated buffer size, this results in an out-of-bounds write on the heap. The vulnerability is remotely exploitable without authentication via the DTLS handshake path and can lead to application crashes or potential memory corruption.",
"id": "GHSA-qcj7-gqxf-2cqq",
"modified": "2026-09-03T15:31:45Z",
"published": "2026-05-04T12:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33846"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-33846.json"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2450625"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-33846"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:60019"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:59831"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:58981"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57483"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:57402"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56911"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56853"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:56786"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:41921"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36006"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36005"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:36004"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:34372"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:33125"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:32962"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30850"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30849"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:30004"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:29197"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26409"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:26319"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20613"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20612"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:20611"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:13274"
}
],
"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"
}
]
}
GHSA-QCVW-2HM7-Q2RP
Vulnerability from github – Published: 2026-07-17 06:31 – Updated: 2026-07-17 06:31Improper Handling of Length Parameter Inconsistency (CWE-130) vulnerability exists in TTSSH2 plugin of Tera Term provided by TeraTerm Project. When Tera Term attempts to establish an SSH connection to a server set up by an attacker, out-of-bounds read/write may occur. As a result, the contents of adjacent memory regions may be transmitted to the server, and Tera Term may behave unexpected or terminate abnormally.
{
"affected": [],
"aliases": [
"CVE-2026-60060"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-17T05:16:41Z",
"severity": "MODERATE"
},
"details": "Improper Handling of Length Parameter Inconsistency (CWE-130) vulnerability exists in TTSSH2 plugin of Tera Term provided by TeraTerm Project. When Tera Term attempts to establish an SSH connection to a server set up by an attacker, out-of-bounds read/write may occur. As a result, the contents of adjacent memory regions may be transmitted to the server, and Tera Term may behave unexpected or terminate abnormally.",
"id": "GHSA-qcvw-2hm7-q2rp",
"modified": "2026-07-17T06:31:00Z",
"published": "2026-07-17T06:31:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-60060"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN65294474"
},
{
"type": "WEB",
"url": "https://teratermproject.github.io/SA/JVN65294474-en.html"
},
{
"type": "WEB",
"url": "https://teratermproject.github.io/SA/JVN65294474.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-QG2P-9JWR-MMQF
Vulnerability from github – Published: 2024-07-10 06:33 – Updated: 2025-11-04 19:47An issue was discovered in Django 4.2 before 4.2.14 and 5.0 before 5.0.7. urlize and urlizetrunc were subject to a potential denial of service attack via certain inputs with a very large number of brackets.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Django"
},
"ranges": [
{
"events": [
{
"introduced": "4.2"
},
{
"fixed": "4.2.14"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "Django"
},
"ranges": [
{
"events": [
{
"introduced": "5.0"
},
{
"fixed": "5.0.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-38875"
],
"database_specific": {
"cwe_ids": [
"CWE-130",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-10T21:41:03Z",
"nvd_published_at": "2024-07-10T05:15:12Z",
"severity": "HIGH"
},
"details": "An issue was discovered in Django 4.2 before 4.2.14 and 5.0 before 5.0.7. urlize and urlizetrunc were subject to a potential denial of service attack via certain inputs with a very large number of brackets.",
"id": "GHSA-qg2p-9jwr-mmqf",
"modified": "2025-11-04T19:47:31Z",
"published": "2024-07-10T06:33:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38875"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/7285644640f085f41d60ab0c8ae4e9153f0485db"
},
{
"type": "WEB",
"url": "https://github.com/django/django/commit/79f368764295df109a37192f6182fb6f361d85b5"
},
{
"type": "WEB",
"url": "https://docs.djangoproject.com/en/dev/releases/security"
},
{
"type": "PACKAGE",
"url": "https://github.com/django/django"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/django/PYSEC-2024-56.yaml"
},
{
"type": "WEB",
"url": "https://groups.google.com/forum/#%21forum/django-announce"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240808-0005"
},
{
"type": "WEB",
"url": "https://www.djangoproject.com/weblog/2024/jul/09/security-releases"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Django vulnerable to Denial of Service"
}
GHSA-QRJ3-HRGJ-FM7R
Vulnerability from github – Published: 2022-09-27 00:00 – Updated: 2025-05-21 18:46rdiffweb prior to 2.4.8 does not validate email length, allowing users to insert an email longer than 255 characters. If a user signs up with an email with a length of 1 million or more characters and logs in, withdraws, or changes their email, the server may cause denial of service due to overload. Version 2.4.8 sets length limits for username, email, and root directory.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "rdiffweb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3272"
],
"database_specific": {
"cwe_ids": [
"CWE-130"
],
"github_reviewed": true,
"github_reviewed_at": "2022-09-30T04:39:38Z",
"nvd_published_at": "2022-09-26T17:16:00Z",
"severity": "HIGH"
},
"details": "rdiffweb prior to 2.4.8 does not validate email length, allowing users to insert an email longer than 255 characters. If a user signs up with an email with a length of 1 million or more characters and logs in, withdraws, or changes their email, the server may cause denial of service due to overload. Version 2.4.8 sets length limits for username, email, and root directory.",
"id": "GHSA-qrj3-hrgj-fm7r",
"modified": "2025-05-21T18:46:55Z",
"published": "2022-09-27T00:00:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3272"
},
{
"type": "WEB",
"url": "https://github.com/ikus060/rdiffweb/commit/667657c6fe2b336c90be37f37fb92f65df4feee3"
},
{
"type": "PACKAGE",
"url": "https://github.com/ikus060/rdiffweb"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/rdiffweb/PYSEC-2022-291.yaml"
},
{
"type": "WEB",
"url": "https://huntr.com/bounties/733678b9-daa1-4d6a-875a-382fa09a6e38"
}
],
"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": "rdiffweb\u0027s unlimited length email field can lead to DoS"
}
Mitigation
When processing structured incoming data containing a size field followed by raw data, ensure that you identify and resolve any inconsistencies between the size field and the actual size of the data.
Mitigation
Do not let the user control the size of the buffer.
Mitigation
Validate that the length of the user-supplied data is consistent with the buffer size.
CAPEC-47: Buffer Overflow via Parameter Expansion
In this attack, the target software is given input that the adversary knows will be modified and expanded in size during processing. This attack relies on the target software failing to anticipate that the expanded data may exceed some internal limit, thereby creating a buffer overflow.