Skip to content
Heist/ feed
Back to feed
Medium

NanoMQ Incorrectly Accepts a Malformed SUBSCRIBE and Can Be Driven into an ASAN-Detectable Out-of-Bounds Read

Type: advisorySources: OSV

NanoMQ contains a protocol-semantics flaw in its MQTT v5 `SUBSCRIBE` handling: if a subscription entry is missing the final 1-byte `Subscription Options` field, the broker may still accept the malformed packet and install the subscription into internal broker state. Under a specific packet-length construction, the same parser flaw also causes a 1-byte out-of-bounds read that crosses the real heap allocation boundary and is detected by ASAN as a `heap-buffer-overflow`. If the consumed byte happens to look acceptable, NanoMQ may continue and append the malformed subscription entry into its internal `subinfol` state. In that case, a `SUBSCRIBE` packet that should be rejected by MQTT rules is instead treated as a successful subscription. Whether ASAN reports the bug does not depend on MQTT's logical `remain` boundary; it depends on whether the read crosses the real heap allocation boundary of the underlying message buffer. In other words, these are not two unrelated issues. They are two manifestations of the same parsing defect: by default, it appears as a semantic vulnerability, and under suitable input conditions, it also becomes a verifiable out-of-bounds read vulnerability.

Products
Not specified
Affected versions
Not specified
Fixed versions
Not specified
CVEs
CVE-2026-35217
Confirmed fixed CVEs
Not specified
Updated in this feed
4 Nov 2026, 02:03 UTC · Revision 1

Source evidence

NanoMQ Incorrectly Accepts a Malformed SUBSCRIBE and Can Be Driven into an ASAN-Detectable Out-of-Bounds Read

core-osv · Original source

Published 20 Jul 2026, 16:39 UTC

NanoMQ contains a protocol-semantics flaw in its MQTT v5 `SUBSCRIBE` handling: if a subscription entry is missing the final 1-byte `Subscription Options` field, the broker may still accept the malformed packet and install the subscription into internal broker state. Under a specific packet-length construction, the same parser flaw also causes a 1-byte out-of-bounds read that crosses the real heap allocation boundary and is detected by ASAN as a `heap-buffer-overflow`. If the consumed byte happens to look acceptable, NanoMQ may continue and append the malformed subscription entry into its internal `subinfol` state. In that case, a `SUBSCRIBE` packet that should be rejected by MQTT rules is instead treated as a successful subscription. Whether ASAN reports the bug does not depend on MQTT's logical `remain` boundary; it depends on whether the read crosses the real heap allocation boundary of the underlying message buffer. In other words, these are not two unrelated issues. They are two manifestations of the same parsing defect: by default, it appears as a semantic vulnerability, and under suitable input conditions, it also becomes a verifiable out-of-bounds read vulnerability.

osv:CVE-2026-35217
Complete source record
{
  "id": "a335c9c122b5130e9c15f3518fcab28952655067783b3bf380524fcbb9c3e545",
  "url": "https://osv.dev/vulnerability/CVE-2026-35217",
  "method": "structured",
  "payload": {
    "kind": "advisory",
    "title": "NanoMQ Incorrectly Accepts a Malformed SUBSCRIBE and Can Be Driven into an ASAN-Detectable Out-of-Bounds Read",
    "summary": "NanoMQ contains a protocol-semantics flaw in its MQTT v5 `SUBSCRIBE` handling: if a subscription entry is missing the final 1-byte `Subscription Options` field, the broker may still accept the malformed packet and install the subscription into internal broker state. Under a specific packet-length construction, the same parser flaw also causes a 1-byte out-of-bounds read that crosses the real heap allocation boundary and is detected by ASAN as a `heap-buffer-overflow`. If the consumed byte happens to look acceptable, NanoMQ may continue and append the malformed subscription entry into its internal `subinfol` state. In that case, a `SUBSCRIBE` packet that should be rejected by MQTT rules is instead treated as a successful subscription. Whether ASAN reports the bug does not depend on MQTT's logical `remain` boundary; it depends on whether the read crosses the real heap allocation boundary of the underlying message buffer. In other words, these are not two unrelated issues. They are two manifestations of the same parsing defect: by default, it appears as a semantic vulnerability, and under suitable input conditions, it also becomes a verifiable out-of-bounds read vulnerability.",
    "evidence": "osv:CVE-2026-35217",
    "products": [],
    "severity": "medium",
    "structured": {
      "id": "CVE-2026-35217",
      "aliases": [
        "CVE-2026-35217",
        "GHSA-w4xh-p384-w556"
      ],
      "metrics": [
        {
          "type": "CVSS_V3",
          "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:H"
        }
      ],
      "affected": [
        {
          "ranges": [
            {
              "repo": "https://github.com/nanomq/nanomq",
              "type": "GIT",
              "events": [
                {
                  "introduced": "0"
                },
                {
                  "last_affected": "16bdb38921e7bbeab887cf229c2eb145889dfa88"
                }
              ],
              "database_specific": {
                "extracted_events": [
                  {
                    "range": [
                      {
                        "introduced": "0"
                      },
                      {
                        "last_affected": "0.24.14"
                      }
                    ],
                    "source": "AFFECTED_FIELD",
                    "strategy": "StringRangeExpression"
                  }
                ]
              }
            }
          ],
          "versions": [
            "0.24.14",
            "0.24.13",
            "0.24.12",
            "0.24.11",
            "0.24.10",
            "0.24.9",
            "0.24.8",
            "0.24.7",
            "0.24.6",
            "0.24.5",
            "0.24.4",
            "0.24.3-5",
            "0.24.3",
            "0.24.2",
            "0.24.1",
            "0.24.0",
            "0.23.10",
            "0.23.9",
            "0.23.8",
            "0.23.7-11",
            "0.23.7",
            "0.23.6",
            "0.23.5",
            "0.23.4",
            "0.23.3",
            "0.23.2",
            "0.23.1",
            "0.23.0",
            "0.22.10",
            "0.22.8",
            "0.22.7",
            "0.22.6",
            "0.22.2",
            "0.22.3",
            "0.22.1",
            "0.22.0",
            "0.21.10",
            "0.21.9",
            "0.21.8",
            "0.21.7",
            "0.21.6",
            "0.21.5",
            "0.21.2",
            "0.21.1",
            "0.21",
            "0.20.8",
            "0.20.6",
            "0.20.5",
            "0.20.0",
            "0.19.5",
            "0.19.1",
            "0.19.0",
            "0.18.2",
            "0.18.1",
            "0.17.8",
            "0.17.5",
            "0.17.2",
            "0.16.5",
            "0.16.3",
            "0.16.2",
            "0.16.0",
            "0.15.5",
            "0.15.3",
            "0.15.2",
            "0.15.1",
            "0.15.0",
            "0.14.8",
            "0.14.5",
            "0.12.1",
            "0.14.1",
            "0.14.0",
            "0.13.8",
            "0.13.6",
            "0.13.0",
            "0.12.5",
            "0.12.2",
            "0.12.0",
            "0.11.82",
            "0.11.8",
            "0.11.5",
            "0.11.3",
            "0.11.2",
            "0.11.0",
            "0.10.8",
            "0.10.5",
            "0.10.1",
            "0.9.7",
            "0.9.5",
            "0.9.2",
            "0.9.0",
            "0.8.6log",
            "0.8.5",
            "0.8.3",
            "0.8.0",
            "0.7.9",
            "0.7.8",
            "0.7.5",
            "0.7.5rc",
            "0.7.4rc",
            "0.7.4",
            "0.7.3",
            "0.7.2",
            "0.6.8",
            "0.7.0",
            "0.6.7rc",
            "0.6.4",
            "0.6.3",
            "0.6.2",
            "0.6.0",
            "0.5.9",
            "0.5.8",
            "0.5.5",
            "0.5.2",
            "0.5.0",
            "0.4.8",
            "0.4.5",
            "0.4.3",
            "0.4.2",
            "0.4.1",
            "0.4.0",
            "0.3.8",
            "0.3.5",
            "0.3.4",
            "0.3.3",
            "0.3.2",
            "0.3.0",
            "0.2.5",
            "0.2.2",
            "0.2.1",
            "0.2.0",
            "0.1.0",
            "0.0.3",
            "0.0.2",
            "0.0.1"
          ],
          "database_specific": {
            "source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-35217.json"
          }
        }
      ],
      "modified": "2026-10-28T02:30:32.664687108Z",
      "provider": "osv",
      "references": [
        "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/35xxx/CVE-2026-35217.json",
        "https://github.com/nanomq/nanomq/security/advisories/GHSA-w4xh-p384-w556",
        "https://nvd.nist.gov/vuln/detail/CVE-2026-35217"
      ],
      "provider_metadata": {
        "cwe_ids": [
          "CWE-125"
        ],
        "cna_assigner": "GitHub_M",
        "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/35xxx/CVE-2026-35217.json"
      }
    },
    "related_cves": [
      {
        "value": "CVE-2026-35217",
        "evidence": "/id"
      }
    ],
    "security_relevant": true,
    "severity_evidence": "/severity/0/score"
  },
  "source_id": "core-osv",
  "document_id": 499531,
  "published_at": "2026-07-20T16:39:49.102+00:00"
}