HackerOne Bug Bounty Disclosure: conflux-queued-zero-length-relay-end-triggers-heap-out-of-bounds-read-brian

Report title Conflux-queued zero-length RELAY_END triggers heap out-of-bounds read

Report link

Date submitted 2026-09-10T12:10:35.499Z

Tor contained a memory-safety bug in its Conflux traffic-handling code. A specially crafted zero-length `RELAY_END` cell could cause Tor to read one byte beyond the end of a heap allocation when the message was delivered out of order.

Tor permits `RELAY_END` cells with no payload and normally interprets them as having the `MISC` stream-ending reason. However, the vulnerable code attempted to read the first byte of the message before checking whether the message contained any bytes.

Under normal circumstances, Tor’s relay-cell storage could hide this mistake. Conflux changed the conditions by copying out-of-order messages into allocations sized exactly to the message length. For a zero-length message, the attempted read therefore occurred immediately past the allocated heap memory.

### How It Could Be Triggered

An attacker acting as a relay or exit could send a malformed, empty `RELAY_END` cell through a Conflux circuit. The issue required several specific conditions, including out-of-order delivery and a non-open application stream, such as a stream waiting for a connection. These requirements made exploitation difficult, but the vulnerable path was reachable remotely without authentication.

The flaw caused a heap out-of-bounds read. AddressSanitizer and other hardened builds reliably detected the invalid access and terminated the Tor process, resulting in a denial of service. On standard builds, the code could still read memory outside the allocation, although the report did not demonstrate information disclosure or code execution.

The reporter supplied an automated regression test that sent a zero-length `RELAY_END` message through Tor’s actual Conflux out-of-order queue. When the message was later processed, AddressSanitizer reported a heap-buffer-overflow in `connection_ap_process_end_not_open()`.

The vulnerable code should only read the reason byte when the message length is greater than zero. For an empty message, it should directly use `END_STREAM_REASON_MISC`:

int reason = msg->length > 0

? get_uint8(msg->body)

: END_STREAM_REASON_MISC;

Tor resolved the issue and confirmed that versions 0.4.8 and 0.4.9 were affected and released together. The report received a bounty under the Internet Bug Bounty program and was later publicly disclosed.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.

HackerOne report summary

Programme

Submitted by Brian Carpenter

Profile

Report title Conflux-queued zero-length RELAY_END triggers heap out-of-bounds read

Report link

Date submitted 2026-09-10T12:10:35.499Z

Tor contained a memory-safety bug in its Conflux traffic-handling code. A specially crafted zero-length `RELAY_END` cell could cause Tor to read one byte beyond the end of a heap allocation when the message was delivered out of order.

Tor permits `RELAY_END` cells with no payload and normally interprets them as having the `MISC` stream-ending reason. However, the vulnerable code attempted to read the first byte of the message before checking whether the message contained any bytes.

Under normal circumstances, Tor’s relay-cell storage could hide this mistake. Conflux changed the conditions by copying out-of-order messages into allocations sized exactly to the message length. For a zero-length message, the attempted read therefore occurred immediately past the allocated heap memory.

### How It Could Be Triggered

An attacker acting as a relay or exit could send a malformed, empty `RELAY_END` cell through a Conflux circuit. The issue required several specific conditions, including out-of-order delivery and a non-open application stream, such as a stream waiting for a connection. These requirements made exploitation difficult, but the vulnerable path was reachable remotely without authentication.

The flaw caused a heap out-of-bounds read. AddressSanitizer and other hardened builds reliably detected the invalid access and terminated the Tor process, resulting in a denial of service. On standard builds, the code could still read memory outside the allocation, although the report did not demonstrate information disclosure or code execution.

The reporter supplied an automated regression test that sent a zero-length `RELAY_END` message through Tor’s actual Conflux out-of-order queue. When the message was later processed, AddressSanitizer reported a heap-buffer-overflow in `connection_ap_process_end_not_open()`.

The vulnerable code should only read the reason byte when the message length is greater than zero. For an empty message, it should directly use `END_STREAM_REASON_MISC`:

int reason = msg->length > 0

? get_uint8(msg->body)

: END_STREAM_REASON_MISC;

Tor resolved the issue and confirmed that versions 0.4.8 and 0.4.9 were affected and released together. The report received a bounty under the Internet Bug Bounty program and was later publicly disclosed.

A considerable amount of time and effort goes into maintaining this website, creating backend automation and creating new features and content for you to make actionable intelligence decisions. Everyone that supports the site helps enable new functionality.

If you like the site, please support us on Patreon or Buy Me A Coffee using the buttons below.