Note that I use PHP in FastCGI mode and run it as an UNIX socket.

I can confirm that this issue is not present when using PHP7 and Apache (running as php_mod). Will try to investigate and check PHP7-FPM on other OS.

Tested it on Debian Jessie running Nginx 1.9.3-1 and PHP7-beta3 FPM (this one, to be exact: https://github.com/docker-library/php/blob/master/7.0/fpm/Dockerfile).

Same problem here.. It is only working as Apache module. The problem likely exists somewhere in the fpm sapi? 

I hope this is enough information to find the bug. For now I will stick to using apache2handler, which seems to be working fine.

I can confirm this is happening in 7.0.0RC1 too running php-fpm and nginx 1.2.0. It appears to be any http header not just the Authorization header. It's causing problems on some sites because $_SERVER['HTTP_X_REQUESTED_WITH'] sometimes contains 'XMLHttpRequest' even if it wasn't sent in the current request but it was sent in previous requests. The problem is very intermittent and trivial scripts don't seem to reproduce it.

Reporter states it's FPM only issue.
It sounds like request clean up is not done well in FPM SAPI.

Found an easy workaround which may help with troubleshooting. 
Setting pm.max_requests = 1 in the php-fpm config prevents this from happening since each process handles only 1 request. Obviously not a good idea in a production environment.

I can confirm this problem running the PHP-7.0.0 branch.

Here's a very simple test case:
<?php
echo $_SERVER['HTTP_X_TEST']. "\n";
fastcgi_finish_request();

$ curl -H "X-Test: 123" http://test
123
curl http://test
123

I guess this is also an security problem.

I haven't tested this yet (currently on mobile), but if I had to guess, I would say that this is caused by https://github.com/php/php-src/commit/f20118aa669f9992fee8a64024e623805669391b

I'll try without this commit later today and if my suspicions are correct, I'll try to come up with a patch.

I can confirm now that my previous hunch was correct. This bug was introduced in f20118aa669f9992fee8a64024e623805669391b.

The testcase given by Steffen passes with f20118aa669f9992fee8a64024e623805669391b's parent but fails with f20118aa669f9992fee8a64024e623805669391b.

Unfortunately, the code has significantly changed since that commit was introduced, so an easy revert will not do. I'll try to investigate a bit more in order to come up with a fix that works on current HEAD - no promises though.