- Top reward
- $1,500
- Top severity paid
- Critical
- Assets in scope
- 12
- Public CVEs
- 0
- Last change
- No changes yet
At a glance
What to know before you start testing.
- Pays from $1,500
- for critical bugs.
- Report on Sorona
- Submit through the program page.
- Partial safe harbor
- Some legal protection; read the terms.
- Publish after a fix
- Coordinate the timing with the company.
Rewards
What Sorona lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical | $1,500+ | |
| High | $700+ | |
| Medium | $300+ | |
| Low |
|
$100 $100 / 1 month Claude Max |
- Safe harbor
-
Partial
Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf.
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Scope
12 assets you may test, 6 excluded.
Web 1
- https://mosquitto.org
Products and areas 11
- Authentication and authorisation end to end: password files, TLS client certificates, pre-shared keys and the plugin authentication interface
- Bridge mode, where one broker connects to another as a client and parses whatever the remote side sends back
- libmosquitto, the client library a great deal of device firmware links against, plus the mosquitto_pub and mosquitto_sub command-line clients
- MQTT 5.0 property handling: user properties, topic aliases, subscription identifiers and the response-topic machinery
- Session and message persistence, covering retained messages, queued QoS 1 and QoS 2 messages, will messages and the on-disk database the broker writes
- The $SYS topic tree and anything else that exposes broker state to a connected client
- The dynamic security plugin and the broker's plugin ABI, where an external module makes authorisation decisions on the broker's behalf
- The Eclipse Foundation vulnerability reporting policy accepts security issues in any Eclipse project and the research behind this entry found no Mosquitto-specific carve-out, so the whole tree is the declared target rather than a narrow asset list
- The MQTT packet parser across both 3.1.1 and 5.0, covering CONNECT, PUBLISH, SUBSCRIBE and every other control packet the broker reads before a client is authenticated
- TLS listener handling, including certificate processing, SNI, ALPN and the WebSockets listener
- Topic matching and the wildcard engine, along with the access control lists that decide who may publish or subscribe to what
Out of scope (6)
- Broker configurations an administrator chose, such as running with anonymous access allowed or without TLS on a public interface
- Client applications and vendor firmware that merely speak MQTT to a Mosquitto broker
- Denial of service that amounts to sending the broker more traffic than the hardware can carry
- Other MQTT brokers. EMQX, NanoMQ, HiveMQ and VerneMQ are separate codebases under separate vendors and separate policies, and EMQ's own policy states that reports will be rewarded
- Reports filed as public GitHub issues rather than through the Eclipse intake
- Upstream dependency defects such as OpenSSL, unless Mosquitto's own use of the library is what makes them reachable
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Sorona's policy.
While testing
-
Do not open a public GitHub issue for a security defect; the Eclipse process is a private intake with its own security team
-
Name the Mosquitto version and the component.
-
Include the exact control packet or byte sequence.
-
State which protocol version you reproduced on, because MQTT 3.1.1 and MQTT 5.0 take materially different paths through the broker
-
Say whether the broker was running with a plugin, a dynamic security configuration or a bridge
-
Report through the Eclipse Foundation vulnerability reporting process, which the repository's SECURITY.md points to at eclipse.org/security
Not accepted
-
Denial of service that amounts to sending the broker more traffic than the hardware can carry
-
Upstream dependency defects such as OpenSSL, unless Mosquitto's own use of the library is what makes them reachable
-
Broker configurations an administrator chose, such as running with anonymous access allowed or without TLS on a public interface
Summarised with AI from the program policy on Sorona, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from sorona.xyz on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview Mosquitto is the reference MQTT broker and the default one nearly everywhere MQTT is spoken: distribution packages on Debian and Alpine, the Docker official image, the standard Home Assistant add-on, plus a large share of industrial gateways and telemetry backhauls. It listens on TCP 1883 and 8883 and parses attacker-supplied control packets before any authentication decision is complete, so a parsing defect is reachable by anyone able to open a socket. A broker sits at the aggregation point for a whole fleet, where one compromise reaches every publisher and subscriber behind it. The Eclipse Foundation runs a coordinated-disclosure process with no bounty attached, so sorona.xyz pays you directly on qualified, reproduced findings. In scope The Eclipse Foundation vulnerability reporting policy accepts security issues in any Eclipse project and the research behind this entry found no Mosquitto-specific carve-out, so the whole tree is the declared target rather than a narrow asset list The MQTT packet parser across both 3.1.1 and 5.0, covering CONNECT, PUBLISH, SUBSCRIBE and every other control packet the broker reads before a client is authenticated MQTT 5.0 property handling: user properties, topic aliases, subscription identifiers and the response-topic machinery Topic matching and the wildcard engine, along with the access control lists that decide who may publish or subscribe to what Authentication and authorisation end to end: password files, TLS client certificates, pre-shared keys and the plugin authentication interface TLS listener handling, including certificate processing, SNI, ALPN and the WebSockets listener Session and message persistence, covering retained messages, queued QoS 1 and QoS 2 messages, will messages and the on-disk database the broker writes Bridge mode, where one broker connects to another as a client and parses whatever the remote side sends back The $SYS topic tree and anything else that exposes broker state to a connected client libmosquitto, the client library a great deal of device firmware links against, plus the mosquitto_pub and mosquitto_sub command-line clients The dynamic security plugin and the broker's plugin ABI, where an external module makes authorisation decisions on the broker's behalf Out of scope Broker configurations an administrator chose, such as running with anonymous access allowed or without TLS on a public interface Other MQTT brokers. EMQX, NanoMQ, HiveMQ and VerneMQ are separate codebases under separate vendors and separate policies, and EMQ's own policy states that reports will be rewarded Client applications and vendor firmware that merely speak MQTT to a Mosquitto broker Upstream dependency defects such as OpenSSL, unless Mosquitto's own use of the library is what makes them reachable Denial of service that amounts to sending the broker more traffic than the hardware can carry Reports filed as public GitHub issues rather than through the Eclipse intake Most-valued findings The research behind this entry records no published Mosquitto advisories to prioritise from, so what follows ranks by reachability rather than by history Memory corruption in the pre-authentication packet path, reached from a single connection to 1883 or 8883 before any credential is checked Access control bypass where a client publishes to or subscribes to a topic its ACL should have refused, including anything the wildcard matcher treats too generously Authentication bypass in the plugin interface or in TLS client-certificate handling, where a broker configured to demand credentials accepts a client without them Topic alias and property handling in MQTT 5.0, a newer surface with far less field exposure than the 3.1.1 path has had Bridge-mode defects, where a compromised remote broker attacks the local one through a connection the operator initiated outbound Anything that leaks one client's retained or queued messages to another, since a broker routinely carries several tenants' telemetry at once Memory corruption in libmosquitto, which propagates into every piece of device firmware that links it and never gets rebuilt Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Report through the Eclipse Foundation vulnerability reporting process, which the repository's SECURITY.md points to at eclipse.org/security Do not open a public GitHub issue for a security defect; the Eclipse process is a private intake with its own security team Name the Mosquitto version and the component. The broker, the libmosquitto client library and the command-line clients are separate surfaces and a defect may only exist in one Include the exact control packet or byte sequence. The highest-value class here is pre-authentication parsing of a malformed MQTT packet, and a byte-level reproducer is what makes that triageable State which protocol version you reproduced on, because MQTT 3.1.1 and MQTT 5.0 take materially different paths through the broker Say whether the broker was running with a plugin, a dynamic security configuration or a bridge, since those change which code the packet reaches The Eclipse Foundation runs a security team and a coordinated-disclosure process rather than a bounty, so there is no payment to negotiate upstream Disclosure Coordinated privately with the Eclipse Foundation security team, which triages the report, works the fix with the project and publishes an advisory alongside a patched release. Eclipse announces through its own process rather than through GitHub Security Advisories, so the advisory count on the repository understates the real record. Plan for an embargo that runs to the next patched release, and hold detail until the advisory is public. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability