When doing an malformed request to the undertow http handler, the text is echoed back instead of the protocol in the header. This could be a serious security issue.

Example:
Valid request (no space between /api and <):
curl -i -s -k -X GET 'http://localhost:5000/api<script>alert(hoi)</script>'
Valid response start: HTTP/1.1 200 OK

But when there's a space (hex 0x20) in the url (space between /api and <):
curl -i -s -k -X GET 'http://localhost:5000/api <script>alert(hoi)</script>'

Invalid/obscure response: <script>alert(hoi)</script> 200 OK

So the "HTTP/1.1" string is replaced with the text "<script>alert(hoi)</script>" in the url. This shouldn't be the case in my opinion.

It looks like the Protocol header parsing fails at line 215 in the HttpRequestParser and when line 247 is executed the protocol String is filled with the String in the malformed url after the space.'

Note: normally browsers do URL encoding right, so to exploiting this is fairly hard.