It is interesting if F5 downgrades the connection to http1.0 as it does not need host header and this to trigger the potential bug.
You can also as a workaround try to insert the hostname with an rule at the HTTP_REQUEST_RELEASE event that is after the ASM/AWAF by first saving the hostname to variable at the HTTP_REQUEST event that is triggered before the AWAF/ASM module even if I think the Host header value should be available without saving it to a variable at the request event. HTTP::host is how you can get the hostname. When F5 cannot do something by default or in a case of potential bug irules usually can 😎
You can try to insert the host header with HTTP::host at the HTTP_REQUEST_RELEASE or HTTP::header options but it is interesting that under the HTTP::header article I have read that header sanitize options could remove the Host header so maybe the Policy Builder is doing some header sanitization etc. that causes the same issue but should have seen this.
HTTP::host (f5.com)
HTTP::header (f5.com)
Also upgrade to the latest versions as maybe you are hitting a bug like the one mentioned in A specifically crafted HTTP request may lead the BIG-IP system to pass malformed HTTP requests to a target pool member web server (HTTP Desync Attack) (f5.com) so better review the asm and ltm logs as well the policy builder recommendations for headers as in manual mode it will tell you what it wants to do without actually doing it as you host header may not follow some RFC and the Auto mode to just enforce a protection that "cleans" your host header.
Edit:
Oh now I have read that you mean the AWAF/ASM block message not that the WAF removed the host header and sending the request to the origin server without one. Have you enabled log and learn under the the policy building for the violation ?