Для убедительности, приведу ещё такой пример.
Есть бекенд приложения, которое обслуживает множество хостов, всех этих хостах fastcgi_pass одинаковы, роутинг внутри приложения осуществляется по HTTP_HOST, дело в том, что использовать для роутинга SERVER_NAME, часто невозможно по ряду причин.

Nginx, конфиг:

server {
server_name example.com {

location /private/ {
internal;
auth_basic "Private ";
auth_basic_user_file conf/htpasswd;
...
}

fastcgi_pass 127.0.0.1:9000;
}
}

server {
server_name other.com {
…
fastcgi_pass 127.0.0.1:9000;
}
}

Теперь делаем запрос

GET http://other.com/private/ HTTP/1.1
Host: example.com

Nginx, определяет вирт хост как other.com в котором нет директив для location /private/ {internal; auth_basic}, но при этом Nginx передает бекенду HTTP_HOST = example.com, бекенд проверяет HTTP_HOST и отдает контент для example.com/private/.

Если вы не считаете это багом Nginx, тогда объясните мне, зачем указывать в location директивы internal; auth_basic, если любой студент сможет их обойти.

Данная уязвимость открыта для всех бекендов которые для роутинга использует HTTP_HOST, а как правило это именно так, одна из основных причин, бекенду нужно работать и в default_server.

Можно конечно сделать на бекенде, мапинг server_name и хостов, всегда на каждом запросе проверять isset($map[SERVER_NAME][ HTTP_HOST])
Но зачем все это, если в конфиге Nginx и так уже созданы все эти связи и Nginx на каждом запросе их и так всегда проверяет.
По этому я считаю, что эту уязвимость нужно закрыть на уровне Nginx.