This may be a real problem.
By definition the HTTP response Headers are usually trusted. In a context with some reverse proxy caches between you (the browser) and the 'faulty' server you may be able to do bad things on the reverse proxy caches (or http load balancers, ssl terminators, etc.).
You may be able to generate cookies from this server with GET arguments (like
&set-cookie=phpsessid=something;httpOnly=false;SameSite=none). But that's maybe not the biggest problem.
You should look at the behavior on existing headers. If there is a Content-Length header on the classical response, what happens when you add a
&content-length=0 argument on you query (or another size). Is this header added, is it replacing the existing one?
What happens if the response is chunked (
Transfer-Encoding: chunked) and you add a Content-length header on this response? Or the contrary.
This could become even more fun if you have a way of uploading files on the server. Because you could control the body of the response. You could add http responses in that body, enter the HTTP Response Splitting issues (HTTP Smuggling).
You could play with partial-Content queries (hide html in parts of uploaded images, in EXIF zones), forge stranges responses, try to alter any header related to the message size (transfer-encoding, content-length) or the mime type.
So, in terms of cache poisoning or http Desync it could be a real issue.
HTTP response headers should not be controlled by the client, the protocol is not made for that. Just look at all issues coming from CRLF injections, here you have the same vector (control over http headers in the response) but you do not even need to inject CRLF characters (but in CRLF injection you can inject the double CRLFCRLF to start the body here you cannot).