The only implications of which I’m aware are in relation to web servers that serve the same content regardless of the Host header. It is then possible for someone to log into and interact normally with the website, but the cookies will be associated with the domain controlled by the attacker. The attacker can then change where the domain points later and retrieve the cookies.
This sort of attack is rather obscure, though. It’s a lot more effective to create a phishing site with just a log in form—or, if you want to get fancy, even proxy everything directly from the real website. You can then steal passwords immediately, rather than stealing session cookies after-the-fact. This works even against servers that pay attention to the Host header.
Edit: After re-reading the relevant portion of the article, I believe the author is referring to something similar to this invalid scenario:
1. Alice operates a web store at alice.example.
2. To make purchases, alice.example makes HTTP requests to api.alice.example from within the browser.
3. api.alice.example doesn’t pay attention to Host headers.
4. Mallory operates a malicious website at mallory.example.
5. Mallory cannot make requests to api.alice.example from mallory.example—that would break the same-origin policy. She works around this by configuring api.mallory.example as a CNAME to api.alice.example.
6. Bob has an account at alice.example, and is currently logged in.
7. Mallory tricks Bob into visiting mallory.example.
8. The content loaded by mallory.example makes a request to api.mallory.example indicating that Bob is making a purchase.
This doesn’t work—Bob is safe, and Mallory doesn’t score any loot. When the browser makes the request to api.mallory.example, it will pass cookies from api.mallory.example and mallory.example, not api.alice.example and alice.example. The browser pretends it has no idea that api.mallory.example and api.alice.example point to the same server.
In order for this to work, Bob would need to log in again, but this time at mallory.example—and this brings us back to my original point; it’s easier and more effective to set up a standard phishing page without any CNAME shenanigans.
While I agree with most of the author’s points, this one baffles me. I don’t see any realistic security implication of what the author has described in this scenario. There are theoretical implications, but in every case it seems there are far easier and more effective attacks. Furthermore, it’s nearly impossible to solve the problem described here; the proposed solutions the author mentions for replacing the Public Suffix List don’t resolve the CNAME threat I’ve described.
Edit 2: I’ve opened an issue asking for clarification: https://github.com/sleevi/psl-problems/issues/4