Summary
Moquette may publish a client's Last-Will message without enforcing the authorization and reserved-topic checks applied to ordinary MQTT PUBLISH messages. If a client can configure a Will for a restricted topic, an unexpected disconnect may cause the broker to inject an unauthorized message there.
Affected context
The issue occurs in Moquette deployments that process MQTT Last-Will messages when clients disconnect unexpectedly. It becomes risky when authorization policies restrict which topics a client may publish to, but the Will-publication path does not apply the same write-permission and reserved-topic controls as normal publishes.
Exploit preconditions
- Attack surface: MQTT client connection and Last-Will configuration
- Required access: A client account or connection permitted to configure a Last-Will message
- Trigger point: Unexpected client disconnection causing the broker to publish the configured Will
- Why exploitation is possible: The Will path can bypass normal
canWriteauthorization and reserved-topic checks
Why this happens
The underlying defect is an authorization inconsistency between two message-publication paths. Normal PUBLISH handling applies topic-write permissions and reserved-topic restrictions, while PostOffice.publishWill can publish the Last-Will message without equivalent checks. This maps to CWE-862: Missing Authorization, because the broker performs a security-sensitive action without verifying whether the client is authorized to perform it.
Potential impact
- An attacker may inject messages into topics outside their permitted publish scope
- Applications consuming restricted topics could receive forged or misleading events
- Security, monitoring, or workflow decisions could be influenced by unauthorized messages
- Reserved-topic protections may be bypassed through the Last-Will mechanism
General mitigation guidance
Mitigation generally focuses on making Last-Will publication subject to the same authorization policy as ordinary publishing.
Common defensive patterns include:
- Applying topic-write authorization and reserved-topic checks before publishing any Will message
- Centralizing publication authorization so alternate message paths cannot bypass policy enforcement
- Treating client-provided Will topics and payloads as untrusted input
- Using deny-by-default topic permissions and least-privilege client identities
- Testing unexpected-disconnect behavior against the same authorization matrix used for normal PUBLISH operations
How teams detect issues like this
Organizations can look for authorization inconsistencies across MQTT publication paths through:
- Static analysis of Will-handling code for missing permission checks
- Code review signals where internal publication functions accept client-controlled topics without an authorization decision
- Tests that compare normal PUBLISH and Last-Will behavior for identical topic permissions
- Broker audit policies that flag clients publishing to topics outside their assigned scope
- Automated security review tools that identify alternate execution paths around centralized access-control checks
