CVE-2026-112332 in Motor.NET
Summary
by MITRE • 10/22/2026
Motor.NET before 0.19.0 contains an uncaught exception vulnerability in JsonNetDeserializer.Deserialize that allows a remote attacker who can publish to a consumed queue or topic to crash the service permanently by sending structurally valid JSON that does not match the handler's expected type. Attackers can exploit the fact that JsonSerializationException is not caught alongside JsonReaderException and InvalidCastException, causing TypedConsumerService.SingleMessageConsumeAsync to treat the error as CriticalFailure and call StopApplication, which combined with the unacknowledged message being redelivered on restart results in a permanent crash-loop.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in Motor.NET prior to version 0.19.0 represents a critical availability risk stemming from improper exception handling within its JSON deserialization logic. Specifically, the JsonNetDeserializer.Deserialize method fails to catch all relevant serialization exceptions that can arise during message processing. While the code correctly handles JsonReaderException and InvalidCastException, it neglects to account for JsonSerializationException. This oversight creates a gap in error resilience where structurally valid JSON payloads that do not align with the expected data types of the consumer handler trigger an unhandled exception rather than being gracefully managed or rejected with appropriate feedback.
From a technical perspective, this flaw resides within the TypedConsumerService.SingleMessageConsumeAsync method which acts as the primary entry point for processing incoming messages from RabbitMQ queues or topics. When a message arrives that is syntactically correct JSON but semantically incompatible with the target object structure, JsonNetDeserializer throws a JsonSerializationException. Because this specific exception type is not included in the catch blocks designed to handle deserialization errors, the runtime treats it as an unhandled critical failure. Consequently, the service invokes StopApplication, initiating a shutdown sequence for the entire application instance rather than isolating or logging the error while continuing operation.
The operational impact of this vulnerability extends beyond a simple process crash due to a specific mechanism inherent in message queue systems known as redelivery on failure. When Motor.NET crashes and restarts, it reconnects to the broker and requests unacknowledged messages from the consumed queues or topics. Since the original problematic message was never acknowledged before the crash occurred, the broker resends this exact same payload upon reconnection. The restarted service immediately encounters the same deserialization error, triggers another critical failure, and shuts down again. This creates a permanent crash-loop where the application is unable to recover autonomously, leading to sustained denial of service for any consumers relying on that specific queue or topic.
This vulnerability aligns with CWE-754, which describes improper check for unusual or exceptional conditions, as well as CWE-248, an unhandled exception in a critical path. In the context of the MITRE ATT&CK framework, this flaw facilitates Denial of Service (T1499) by allowing remote attackers to exhaust service availability through resource exhaustion and application instability. The attack vector is particularly dangerous because it requires only the ability to publish messages to an existing queue or topic, a privilege that may be granted to various internal services or compromised endpoints within a microservices architecture.
Mitigation strategies must focus on both immediate patching and architectural resilience improvements. The primary remediation is upgrading Motor.NET to version 0.19.0 or later, where the deserialization logic has been updated to catch JsonSerializationException alongside other serialization errors. For environments unable to upgrade immediately, implementing a dead-letter queue mechanism can help isolate problematic messages before they trigger application crashes. Additionally, configuring the message broker with retry policies that limit the number of redeliveries for specific queues can prevent infinite loops caused by unprocessable payloads. Application-level monitoring should also be enhanced to detect repeated deserialization failures and alert administrators before a crash-loop condition becomes permanent.