Passing topic > 65535 bytes to Publish() corrupts message body #730
Description
Special thanks to Paul Gerste at Sonar for reporting this issue #714 via the Eclipse security team.
Note: Resolved by PR #714 (raised in May) and fix incorporated into release 1.5.1.
Update 2025-12-03 - CVE-2025-10543 is now public.
Summary:
In Eclipse Paho Go MQTT v3.1 library (paho.mqtt.golang) versions <=1.5.0 UTF-8 encoded strings, passed into the library, may be incorrectly encoded if their length exceeds 65535 bytes. This may lead to unexpected content in packets sent to the server (part of an MQTT topic may leak into the packet ID and message body in a PUBLISH packet).
The issue arises because the length of the data passed in was converted from an int64/int32 (depending upon CPU) to an int16 without checks for overflows. The int16 length was then written, followed by the data (e.g. topic). This meant that when the data (e.g. topic) was over 65535 bytes then the amount of data written exceeds what the length field indicates. This could lead to a corrupt packet, or mean that the excess data leaks into another field (e.g. topic leaks into message body).
Example
(from the Sonar Security Advisory)
injected := "injected!"
overflownTopic := "target" + injected + strings.Repeat("A", 65536-len(injected))
client.Publish(overflownTopic, 0, false, "foo")
Would lead to a message with the topic target and the message body injected!AAAAAAAAAAAAAAAAAAAAAAAAAAAA... (lots more A's and then "foo").
Notes
In certain circumstances this may be a security issue where:
- End user does not control message body (if they do a direct change would be simpler)
- End user can control the topic, and is able to submit over 65535 bytes
In this case the end user would be able to manipulate the message body. A carefully crafted topic might alter the body in such a way that applications that have subscribed to the topic do something that the end user is not authorised to trigger (or, potentially, crash). I believe this would be a fairly unusual situation because topics are frequently hardcoded, and when they are provided by the user should be validated.
Historically this library has made minimal checks on the data passed in, leaving validation up to the user (topics are frequently hardcoded, so checks for things like invalid unicode impose an unneccessary performance hit in many cases). However in this case I think that the behaviour is very much unexpected, and there is a potential for corruption (or unexpected data in the message body), so a check/fix is warranted.
In this case I have ( #714) added a check (and just truncated the data) because it's cheap, and the resulting corruption is likely to be unexpected (whereas truncation is probably expected).