RabbitMQ direct reply-to: forged suffix fanout causes quadratic mailbox memory

Summary

RabbitMQ direct reply-to addresses have the form:

amq.rabbitmq.reply-to..

When resolving a destination, RabbitMQ decodes and validates the PID but
discards the capability-key suffix. An attacker who obtains their own valid
direct reply-to address can create many distinct routing keys that preserve the
encoded PID and replace only the suffix.

A single message can carry these names through the AMQP CC header. RabbitMQ
creates one volatile target per distinct name and sends one cast per target to
the same channel/session PID. Every cast retains a copy of the message's full
O(N) routing-key structure, producing N × O(N) = O(N²) mailbox memory.

The final capability-key check happens only after each cast reaches the target
mailbox, too late to prevent amplification.

Preconditions

• The attacker has an authenticated AMQP account.
• The account can write to the default exchange.
• The attacker activates direct reply-to and obtains its own generated reply
  address. No victim address or cross-user information leak is required.

These are ordinary application permissions. No plugin or administrator role is
required.

Root cause

1. The suffix is parsed but never validated

%% deps/rabbit/src/rabbit_volatile_queue.erl:368-389
pid_from_name(<<?PREFIX, Bin/binary>>, CandidateNodes) ->
    ...
    [PidBase64, _KeyBase64] = binary:split(Bin, Cp),
    PidBin = base64:decode(PidBase64),
    ...
    {ok, rabbit_pid_codec:recompose(PidPart…