Set a maximum packet size, cap queued messages per client, limit connections and put a hard memory limit on the broker. In Mosquitto several of these default to unlimited or generous values, so a single misbehaving or malicious client can use a lot of memory unless you change them. Test after tuning.
Why limits matter on a broker
A broker holds state on behalf of clients: sessions, subscriptions, and messages waiting for clients that are slow or offline. A client that never reads, or a publisher that floods a topic, can make that state grow. OWASP's API Security Top 10 treats missing limits on memory, upload size, processes and operations per request as the cause of unrestricted resource consumption, and the same thinking applies to brokers.
The Mosquitto settings and their defaults
The Mosquitto configuration manual documents these options. Defaults below come from that page, so confirm them against your own version.
| Setting | What it limits | Documented default or note |
|---|---|---|
| max_packet_size | Size of a whole incoming MQTT packet | 2000000 bytes since 2.1, no limit before |
| message_size_limit | Largest publish payload accepted | 0, meaning all valid messages accepted |
| max_queued_messages | QoS 1 and 2 messages queued per client | 1000, with 0 meaning no maximum (not recommended) |
| max_queued_bytes | Queued bytes per client | 0, meaning no maximum |
| max_inflight_messages | Messages in transit at once | 20 |
| max_connections | Connected clients per listener | Minus one means unlimited, set a number to cap |
| global_max_clients | Client sessions across the broker | Minus one, meaning unlimited |
| memory_limit | Heap memory the broker may allocate | Set a value to cap use, needs memory tracking compiled in |
The manual also explains that a client session counts as connected clients plus persistent sessions that have disconnected but not yet expired. So a flood of persistent sessions can fill memory even with few connections.
The manual notes that when the queued bytes limit is reached, subsequent messages are silently dropped. That is a design choice you should understand: protecting memory means some messages are lost for slow clients.
What can go wrong
- Large payloads. Without a payload limit, one client can publish very large messages that are then forwarded to every subscriber.
- Slow subscribers. A client that stays connected but never acknowledges makes queues grow until a limit is hit.
- Persistent sessions. Clients that connect with a persistent session and never return leave state behind.
- Connection floods. Many cheap connections consume file descriptors and memory.
Steps to tune
- Measure normal traffic: largest legitimate payload, typical queue depth, number of devices.
- Set the payload and packet size limits just above the largest legitimate message.
- Set queue limits by count and by bytes, based on how long a device may be offline.
- Set per listener connection limits and a global client cap that leaves room to grow.
- Set a hard memory limit so the broker fails predictably instead of taking down the host.
- Put the broker in a container or service with memory and file descriptor limits too.
- Load test with a slow subscriber, a large publisher and a connection storm. Confirm the broker stays up and others are unaffected.
- Alert on dropped messages, queue size and session count.
Do not forget the software itself
Limits reduce the damage of abuse, but bugs in broker code can bypass them. Keep the broker and client libraries updated, and track advisories for them.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a dependency inventory lists versions, and check whether your broker libraries would appear.
Quick check
Does Mosquitto cap queued messages by default?
It documents a default of 1000 queued QoS 1 and 2 messages per client, but no byte limit by default. Set both to match your devices.
What happens when the queue is full?
Per the manual, once the byte limit is reached, further messages are silently dropped. Monitor drops so you notice.
Safeguard scans your dependencies and SBOMs for known vulnerabilities, including broker and client libraries, and shows which are reachable. A free scan is at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
