STOMP pre-authentication frame size limit is not enforced

Vulnerability

In rabbit_stomp.hrl (lines 60-61), two frame size constants are defined:

-define(DEFAULT_MAX_FRAME_SIZE, 4 * 1024 * 1024).            %% 4MB
-define(DEFAULT_MAX_FRAME_SIZE_UNAUTHENTICATED, 65536).      %% 64KB

The intent is clearly to limit unauthenticated STOMP connections to 64KB frames while allowing authenticated connections up to 4MB. However, DEFAULT_MAX_FRAME_SIZE_UNAUTHENTICATED is never referenced anywhere in the codebase.

In rabbit_stomp_reader.erl (line 98), only the 4MB limit is applied to ALL connections regardless of authentication state:

MaxFrameSize = application:get_env(rabbitmq_stomp, max_frame_size, ?DEFAULT_MAX_FRAME_SIZE),

A grep of the entire rabbitmq_stomp directory confirms zero references to DEFAULT_MAX_FRAME_SIZE_UNAUTHENTICATED outside its definition in the .hrl file.

Impact

• Pre-authentication resource exhaustion: Unauthenticated STOMP clients can send frames up to 4MB (should be capped at 64KB)
• Memory amplification: An attacker opening many unauthenticated connections, each sending 4MB frames, can exhaust server memory
• Defense-in-depth failure: The intended security control exists as dead code, providing a false sense of security

Note: This is a lower-severity finding since 4MB per connection alone is not sufficient for OOM on most systems. The risk increases with many concurrent unauthenticated connections.

Comparison with MQTT

The MQTT plugin correctly…