HTTP/1.1 defines rules which
Transfer-Encoding headers are valid and how they should be interpreted. In particular, a
Transfer-Encoding: chunked header and a
are not allowed to appear in a single message at the same time. This is important to unambiguously delimit subsequent HTTP messages on a connection.
In theory, HTTP/1.1 allows multiple encodings, although, in practice, only
chunked is relevant. In the case that multiple encodings are present,
vulnerable versions of Akka HTTP do not correctly validate the rules of the specification and effectively ignore the
Transfer-Encoding header, use
Content-Length header if present for delimiting a message, and pass the message to the user unchanged.
If users used Akka HTTP as a reverse proxy, such a message might be forwarded to a backend server. This can potentially lead to “Request Smuggling” if the backend server has a similar but different interpretation for that (invalid) set of headers.
Based on our assessment, the CVSS score of this vulnerability is 4.2 (Medium), based on vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N/E:U/RL:O/RC:C).
A vulnerable Akka HTTP server will accept a malformed message as described above and hand it over to the user. If the user application proxies this message to another server unchanged and that server also accepts that message but interprets it as two HTTP messages, the second message has reached the second server without having been inspected by the proxy.
Note that Akka HTTP itself currently does not provide functionality to proxy requests to other servers (but it’s easy to build).
In summary, these conditions must be true for an application to be vulnerable:
Akka HTTP will no longer accept multiple encodings in
Transfer-Encoding but only a single
chunked encoding is valid. HTTP message carrying a combination of
Content-Length headers are rejected.
Thanks, Bastian Ike and Sebastian Rose of AOE for bringing this issue to our attention.