I don't think the proposed CVE description is correct. This is only triggered on a 401 response and doesn't reveal any sensitive information like tokens. However it could be used to display arbitrary[*] data on someone else's domain. For example, by tricking a user into clicking a malicious link, an attacker may be able to create a web page that looks like a billing page for the given domain. First level checking (that it's at the right domain) wouldn't reveal anything amiss. Granted, there are a lot of assumptions for this to take place, some of which have not yet been demonstrated.
[*] the caveat to "arbitrary" is that the crafted HTML would need to not contain a "/". Which means that it might only work if javascript from the same relative URL would need to be loaded. Which means that it's probably only possible to be maliciously exploited if the deployer is using the domain_remap middleware. This is just speculation though, and has not yet been demonstrated. But if that is the case, then it's not too different from just storing a web page as a Swift object and getting a user to load that.
Hmm...maybe this isn't as big of deal as I thought.
I don't think the proposed CVE description is correct. This is only triggered on a 401 response and doesn't reveal any sensitive information like tokens. However it could be used to display arbitrary[*] data on someone else's domain. For example, by tricking a user into clicking a malicious link, an attacker may be able to create a web page that looks like a billing page for the given domain. First level checking (that it's at the right domain) wouldn't reveal anything amiss. Granted, there are a lot of assumptions for this to take place, some of which have not yet been demonstrated.
[*] the caveat to "arbitrary" is that the crafted HTML would need to not contain a "/". Which means that it might only work if javascript from the same relative URL would need to be loaded. Which means that it's probably only possible to be maliciously exploited if the deployer is using the domain_remap middleware. This is just speculation though, and has not yet been demonstrated. But if that is the case, then it's not too different from just storing a web page as a Swift object and getting a user to load that.
Hmm...maybe this isn't as big of deal as I thought.