VULN_REPORT ID: CVE-2026-31419

Heap Overflow in an MQTT Broker: From CONNECT Packet to RCE

A malformed packet, a trusting parser, and what three weeks of heap grooming taught me about patience.

AUTHOR
HALFABIT
PUBLISHED
2026-05-14
TAG
#VULN-RESEARCH
STATUS
PATCHED ✓

01_BACKGROUND

MQTT brokers sit at the heart of most IoT deployments, parsing untrusted packets from any device that can reach the port. While auditing a popular open-source broker this spring, I noticed the CONNECT parser trusted a length field straight from the wire.

A client ID longer than 64 bytes overflows into adjacent allocator metadata. With the right heap layout, that corruption becomes a write-what-where primitive — and eventually remote code execution as the broker user.

02_VULNERABLE_SOURCE

LANGUAGE: C
1static int parse_connect(conn_t *c, const uint8_t *pkt) {2    uint16_t id_len = read_u16(pkt + 10);3    char *client_id = malloc(64);4 5    /* BUG: id_len is attacker-controlled */6    memcpy(client_id, pkt + 12, id_len);7 8    c->client_id = client_id;9    return ACK_OK;10}

Exploitation was the slow part. Finding the overflow took a day; shaping the heap so the corrupted chunk landed somewhere useful took three weeks of trial, error, and a lot of allocator source reading.

TERMINAL_OUTPUT: LESSONS_LEARNED.LOG

Never trust a length field you didn’t compute. Validate against the buffer you actually allocated.

Heap grooming is 80% of the work — the overflow was found in a day, exploitation took three weeks.

Coordinated disclosure went smoothly because I shipped a working patch with the report.