Common Weakness Enumeration

CWE-130

Allowed

Improper Handling of Length Parameter Inconsistency

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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.

160 vulnerabilities reference this CWE, most recent first.

GHSA-Q2WW-5357-X388

Vulnerability from github – Published: 2026-04-02 20:36 – Updated: 2026-05-13 16:19
VLAI
Summary
Rack has Content-Length mismatch in Rack::Files error responses
Details

Summary

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-Length using String#bytesize.
  • Avoid exposing Rack::Files directly 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.
Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "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:08
VLAI
Summary
Improper Handling of Length Parameter Inconsistency in Apache Ant
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.

Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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:07
VLAI
Summary
zeroconf: Unvalidated rdlength in record payload readers allows LAN-local cache corruption via crafted mDNS packet
Details

Impact

_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

Severity
6.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
4.9 (Medium)
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
Show details on source website
To clipboard 

{
  "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-07-06 21:30
VLAI
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.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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-07-06T21:30:25Z",
  "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: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-QG2P-9JWR-MMQF

Vulnerability from github – Published: 2024-07-10 06:33 – Updated: 2025-11-04 19:47
VLAI
Summary
Django vulnerable to Denial of Service
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.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "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:46
VLAI
Summary
rdiffweb's unlimited length email field can lead to DoS
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.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "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"
}

GHSA-QWHM-H7V3-MRJX

Vulnerability from github – Published: 2023-05-25 17:01 – Updated: 2023-05-30 09:05
VLAI
Summary
Improper handling of NTS cookie length that could crash the ntpd-rs server
Details

Impact

ntpd-rs does not validate the length of NTS cookies in received NTP packets to the server. An attacker can crash the server by sending a specially crafted NTP packet containing a cookie shorter than what the server expects. The server also crashes when it is not configured to handle NTS packets.

ntpd-rs running purely as an ntp client is not affected.

Patches

The issue was caused by improper slice indexing. The indexing operations were replaced by safer alternatives that do not crash the ntpd-rs server process but instead properly handle the error condition. A patch was released in version 0.3.3

Workarounds

ntpd-rs running purely as an ntp client is not affected. By default, ntpd-rs packages are not configured to run as a server.

For machines where serving the time is required, there is no known workaround. Users are recommended to upgrade ntpd-rs as soon as possible.

References

https://github.com/pendulum-project/ntpd-rs/pull/752

We would like to thank @mlichvar for identifying this issue

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "ntpd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.0"
            },
            {
              "fixed": "0.3.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-33192"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-130"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-05-25T17:01:12Z",
    "nvd_published_at": "2023-05-27T04:15:25Z",
    "severity": "HIGH"
  },
  "details": "### Impact\nntpd-rs does not validate the length of NTS cookies in received NTP packets to the server. An attacker can crash the server by sending a specially crafted NTP packet containing a cookie shorter than what the server expects. The server also crashes when it is not configured to handle NTS packets.\n\nntpd-rs running purely as an ntp client is not affected.\n\n### Patches\nThe issue was caused by improper slice indexing. The indexing operations were replaced by safer alternatives that do not crash the ntpd-rs server process but instead properly handle the error condition. A patch was released in version 0.3.3\n\n### Workarounds\nntpd-rs running purely as an ntp client is not affected. By default, ntpd-rs packages are not configured to run as a server.\n\nFor machines where serving the time is required, there is no known workaround. Users are recommended to upgrade ntpd-rs as soon as possible.\n\n### References\nhttps://github.com/pendulum-project/ntpd-rs/pull/752\n\nWe would like to thank @mlichvar for identifying this issue\n",
  "id": "GHSA-qwhm-h7v3-mrjx",
  "modified": "2023-05-30T09:05:58Z",
  "published": "2023-05-25T17:01:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pendulum-project/ntpd-rs/security/advisories/GHSA-qwhm-h7v3-mrjx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33192"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pendulum-project/ntpd-rs/pull/752"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pendulum-project/ntpd-rs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pendulum-project/ntpd-rs/releases/tag/v0.3.3"
    }
  ],
  "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": "Improper handling of NTS cookie length that could crash the ntpd-rs server"
}

GHSA-R6C9-G6Q5-QRF9

Vulnerability from github – Published: 2026-05-18 20:11 – Updated: 2026-06-09 10:58
VLAI
Summary
OpenTelemetry eBPF Instrumentation: CPU-mismatch fallback uses 256-byte buffer with 8KB size
Details

Summary

The per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry.

Details

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/http_buf_size.h#L4-L7

k_kprobes_http2_buf_size is defined as 256 bytes, the size of the fallback buffer.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msg_buffer.h#L12-L36

Introduces 8KB per-CPU buffer and 256-byte fallback_buf in msg_buffer_t, creating a size mismatch for fallback use.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/k_tracer.c#L370-L394

On CPU mismatch, fallback_bufis used but size is still set to m_buf->real_size (up to 8KB) and passed downstream.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocol_http.h#L412-L441

bytes_len (from m_buf->real_size) is used to read payload data from u_buf; if u_buf is the 256B fallback, this can over-read and leak memory into telemetry.

https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/tpinjector/tpinjector.c#L192-L206

real_sizeis set up to 8192 bytes and stored with cpu_id; fallback_bufonly contains 256 bytes.

PoC

Local testing with an AddressSanitizer user-space PoC reproduced the same class of size-mismatch over-read as the vulnerable fallback-buffer path. That result is sufficient to ground the advisory in a fresh local reproduction even though the exact end-to-end eBPF path still depends on host BPF capabilities.

To reproduce the validated behavior locally:

  1. create a struct that models fallback_buf[256] and real_size
  2. populate only the 256-byte fallback buffer
  3. simulate the CPU mismatch path by using the fallback buffer as the source pointer while preserving a much larger real_size
  4. perform a read of real_size bytes from that 256-byte backing store under ASan

An equivalent reproducer is:

// save as /tmp/poc_msgbuf_oob.c
#include <stdint.h>
#include <stdio.h>
#include <string.h>

struct msg_buffer {
  unsigned char fallback_buf[256];
  uint16_t pos;
  uint16_t real_size;
  uint32_t cpu_id;
};

int main(void) {
  struct msg_buffer m = {0};
  unsigned char sink[8192];

  memset(m.fallback_buf, 'A', sizeof(m.fallback_buf));
  m.real_size = 4096;

  memcpy(sink, m.fallback_buf, m.real_size);
  printf("copied %u bytes from a 256-byte fallback buffer\n", m.real_size);
  return 0;
}

Compile and run with ASan:

cc -fsanitize=address -O1 -g -o /tmp/poc_msgbuf_oob /tmp/poc_msgbuf_oob.c
ASAN_OPTIONS=abort_on_error=1 /tmp/poc_msgbuf_oob

Expected result:

AddressSanitizer: heap-buffer-overflow or stack-buffer-overflow

That user-space PoC matches the size-mismatch condition in the vulnerable code path, even though the exact end-to-end eBPF runtime path still requires host BPF attach/load capability.

Impact

This is a confidentiality issue in the HTTP tracing path. The vulnerable read occurs in OBI's local fallback-buffer handling when context propagation is enabled, the tpinjector sock_msg path is active, HTTP large-buffer capture is configured with a non-zero size, and a CPU mismatch occurs between producer and consumer contexts. Under those conditions, OBI can over-read from the fallback buffer and export unrelated memory through telemetry.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45681"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-125",
      "CWE-130"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T20:11:20Z",
    "nvd_published_at": "2026-06-02T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe per-CPU message-buffer fallback path uses a 256-byte backup buffer but preserves the original payload size, which can be up to 8KB. If a CPU mismatch occurs, OBI can read beyond the fallback buffer and leak adjacent memory into telemetry.\n\n### Details\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/http_buf_size.h#L4-L7\n\n`k_kprobes_http2_buf_size` is defined as 256 bytes, the size of the fallback buffer.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/common/msg_buffer.h#L12-L36\n\nIntroduces 8KB per-CPU buffer and 256-byte `fallback_buf` in `msg_buffer_t`, creating a size mismatch for fallback use.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/k_tracer.c#L370-L394\n\nOn CPU mismatch, `fallback_buf `is used but size is still set to `m_buf-\u003ereal_size` (up to 8KB) and passed downstream.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/generictracer/protocol_http.h#L412-L441\n\n`bytes_len (from m_buf-\u003ereal_size)` is used to read payload data from `u_buf`; if `u_buf` is the 256B fallback, this can over-read and leak memory into telemetry.\n\nhttps://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/032473449b53d9f02ec4619d4f5b84e6a81db362/bpf/tpinjector/tpinjector.c#L192-L206\n\n`real_size `is set up to 8192 bytes and stored with `cpu_id`; `fallback_buf `only contains 256 bytes.\n\n### PoC\n\nLocal testing with an AddressSanitizer user-space PoC reproduced the same class of size-mismatch over-read as the vulnerable fallback-buffer path. That result is sufficient to ground the advisory in a fresh local reproduction even though the exact end-to-end eBPF path still depends on host BPF capabilities.\n\nTo reproduce the validated behavior locally:\n\n1. create a struct that models `fallback_buf[256]` and `real_size`\n2. populate only the 256-byte fallback buffer\n3. simulate the CPU mismatch path by using the fallback buffer as the source pointer while preserving a much larger `real_size`\n4. perform a read of `real_size` bytes from that 256-byte backing store under ASan\n\nAn equivalent reproducer is:\n\n```c\n// save as /tmp/poc_msgbuf_oob.c\n#include \u003cstdint.h\u003e\n#include \u003cstdio.h\u003e\n#include \u003cstring.h\u003e\n\nstruct msg_buffer {\n  unsigned char fallback_buf[256];\n  uint16_t pos;\n  uint16_t real_size;\n  uint32_t cpu_id;\n};\n\nint main(void) {\n  struct msg_buffer m = {0};\n  unsigned char sink[8192];\n\n  memset(m.fallback_buf, \u0027A\u0027, sizeof(m.fallback_buf));\n  m.real_size = 4096;\n\n  memcpy(sink, m.fallback_buf, m.real_size);\n  printf(\"copied %u bytes from a 256-byte fallback buffer\\n\", m.real_size);\n  return 0;\n}\n```\n\nCompile and run with ASan:\n\n```bash\ncc -fsanitize=address -O1 -g -o /tmp/poc_msgbuf_oob /tmp/poc_msgbuf_oob.c\nASAN_OPTIONS=abort_on_error=1 /tmp/poc_msgbuf_oob\n```\n\nExpected result:\n\n```text\nAddressSanitizer: heap-buffer-overflow or stack-buffer-overflow\n```\n\nThat user-space PoC matches the size-mismatch condition in the vulnerable code path, even though the exact end-to-end eBPF runtime path still requires host BPF attach/load capability.\n\n### Impact\n\nThis is a confidentiality issue in the HTTP tracing path. The vulnerable read occurs in OBI\u0027s local fallback-buffer handling when context propagation is enabled, the `tpinjector` sock_msg path is active, HTTP large-buffer capture is configured with a non-zero size, and a CPU mismatch occurs between producer and consumer contexts. Under those conditions, OBI can over-read from the fallback buffer and export unrelated memory through telemetry.",
  "id": "GHSA-r6c9-g6q5-qrf9",
  "modified": "2026-06-09T10:58:36Z",
  "published": "2026-05-18T20:11:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-r6c9-g6q5-qrf9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45681"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: CPU-mismatch fallback uses 256-byte buffer with 8KB size"
}

GHSA-R6W8-XQQ4-GMHR

Vulnerability from github – Published: 2026-04-27 06:31 – Updated: 2026-04-27 06:31
VLAI
Details

An improper handling of the length parameter inconsistency vulnerability has been identified in Moxa’s Secure Router. Because of improper validation of length parameters in the HTTPS management interface, an unauthenticated remote attacker could send specially crafted requests that trigger a buffer overflow condition, causing the web service to become unresponsive. Successful exploitation may result in a denial-of-service condition requiring a device reboot to restore normal operation. While successful exploitation can severely impact the availability of the affected device, no impact to the confidentiality or integrity of the affected product has been identified. Additionally, no confidentiality, integrity, or availability impact to the subsequent system has been identified.

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-3868"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-130"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-27T04:16:09Z",
    "severity": "HIGH"
  },
  "details": "An improper handling of the length parameter inconsistency vulnerability has been identified in Moxa\u2019s Secure Router.\u00a0Because of improper validation of length parameters in the HTTPS management interface, an unauthenticated remote attacker could send specially crafted requests that trigger a buffer overflow condition, causing the web service to become unresponsive.\u00a0Successful exploitation may result in a denial-of-service condition requiring a device reboot to restore normal operation.\u00a0While successful exploitation can\u00a0severely\u00a0impact the availability of the affected device, no impact to the confidentiality or integrity of the affected product has been identified. Additionally, no confidentiality, integrity, or availability impact to the subsequent system has been identified.",
  "id": "GHSA-r6w8-xqq4-gmhr",
  "modified": "2026-04-27T06:31:24Z",
  "published": "2026-04-27T06:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3868"
    },
    {
      "type": "WEB",
      "url": "https://www.moxa.com/en/support/product-support/security-advisory/mpsa-261521-cve-2026-3867-cve-2026-3868-improper-ownership-management-and-improper-handling-of-length-parameter-incons"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "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/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-R7HP-8XQQ-GFPR

Vulnerability from github – Published: 2025-09-19 12:30 – Updated: 2025-09-24 06:30
VLAI
Details

Improper Handling of Length Parameter Inconsistency vulnerability in Mitsubishi Electric Corporation MELSEC-Q Series Q03UDVCPU, Q04UDVCPU, Q06UDVCPU, Q13UDVCPU, Q26UDVCPU, Q04UDPVCPU, Q06UDPVCPU, Q13UDPVCPU, and Q26UDPVCPU with the first 5 digits of serial No. "24082" to "27081" allows a remote attacker to cause an integer underflow by sending specially crafted packets to the affected product to stop Ethernet communication and the execution of control programs on the product, when the user authentication function is enabled. The user authentication function is enabled by default only when settings are configured by GX Works2, which complies with the Cybersecurity Law of the People's Republic of China, and is normally disabled.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-8531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-130"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-19T10:15:36Z",
    "severity": "MODERATE"
  },
  "details": "Improper Handling of Length Parameter Inconsistency vulnerability in Mitsubishi Electric Corporation MELSEC-Q Series Q03UDVCPU, Q04UDVCPU, Q06UDVCPU, Q13UDVCPU, Q26UDVCPU, Q04UDPVCPU, Q06UDPVCPU, Q13UDPVCPU, and Q26UDPVCPU with the first 5 digits of serial No. \"24082\" to \"27081\" allows a remote attacker to cause an integer underflow by sending specially crafted packets to the affected product to stop Ethernet communication and the execution of control programs on the product, when the user authentication function is enabled. The user authentication function is enabled by default only when settings are configured by GX Works2, which complies with the Cybersecurity Law of the People\u0027s Republic of China, and is normally disabled.",
  "id": "GHSA-r7hp-8xqq-gfpr",
  "modified": "2025-09-24T06:30:29Z",
  "published": "2025-09-19T12:30:19Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8531"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU97846038"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-25-266-02"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/psirt/vulnerability/pdf/2025-013_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

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
Implementation

Do not let the user control the size of the buffer.

Mitigation
Implementation

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.

← Back to the CWE list