[80x25]

Here's the researcher's write-up of the issue with more details: https://spyclub.tech/2022/12/14/unusual-cache-poisoning-akam...

Interesting research and super useful write-up!

My observations:

- The characters that enable the Host header field forgery aren't unicode characters. They are a subset of separator characters from ASCII. My guess is that the Akamai parser is trimming the Host header field name and not enforcing the requirements from https://www.rfc-editor.org/rfc/rfc7230#section-5.4 after this trim, specifically:

   A server MUST respond with a 400 (Bad Request) status code to any
   HTTP/1.1 request message that lacks a Host header field and to any
   request message that contains more than one Host header field or a
   Host header field with an invalid field-value.

Even worse, the last Host header field appears to "win" and be the selected Host header field in the request forwarded to the origin.

- The OP does mention that Akamai intends to enable stricter header field parsing in 2023 but that response leaves a lot to be desired. They could probably provide a proactive analysis of a customer's traffic to inform them that they can turn on RFC compliant parsing without impact. Punting this decision to their customers requires their customers to be HTTP experts. If I were an Akamai customer, I would expect them to be my HTTP experts for me.