Dalli vulnerabilities

Values flagged as compressed were inflated with no size limit — a ~130 KB stored item could expand to 128 MB on read, regardless of the client's compress or serializer settings. Additionally, the size in a reply was used to read or buffer data without proper limits.

Dalli's pipelined reply parser treated any reply line without a value body (e.g. CLIENT_ERROR or SERVER_ERROR) as the MN that ends the batch. It stopped reading that server's replies and left the rest on the connection, where later commands read them as their own replies.

Dalli buffered request bytes in Ruby's IO write buffer, and quiet (multi) blocks don't flush until they end. When the process forks, the child inherits the buffer, and Ruby flushes it when the child closes or finalizes the socket, even if the child never uses Dalli, so the request is sent twice.

Dalli's meta protocol request formatter writes some numeric arguments into memcached commands without converting them to integers. If an application passes an attacker-controlled String to one of these arguments, CRLF sequences in it are sent to memcached as additional commands on the same connection.

When a client is configured with a namespace, a request that hit a transient network error (timeout or connection closed by memcached or a proxy) was retried with the namespace applied a second time, so app:x became app:app:x.

Per-request raw: true was ignored by some read methods, which still ran the configured serializer's load (Marshal by default) on values flagged as serialized — including get_multi, get_multi_cas, get_multi_with_metadata, get_cas and get_with_metadata.

p_token and l_token were checked only for CR, LF and NUL. A token containing spaces added arbitrary meta flags to the command — e.g. changing an item's TTL on a read, creating stub items on a miss, turning a delete into a stale tombstone, or choosing incr's initial value.