So if I read this correctly the flaw that you've recognised is that a user's name could look like an url and people's email readers are autoconverting this to an url? In that case I think the gmail dot aliasing is somewhat of a red herring as there are other much better ways of targeting people.

Now, our usernames are limited to alphadashdots, so the worst that can be done is that there is an autolink to a domain and so the likelihood of making a really successful attack is extremely limited. The attacker also has no control over the surrounding text and it looks by default something like:

Hi <username> thanks for registering at gitea 

Which again severely reduces potential for realistic attack. (If we allowed spaces in our usernames this would be a lot more of a problem.)

Now:

1. I am against preventing the .com etc. trailers because I know users use these and find them convenient.
2. I think the "." aliasing is a red herring, the same could be said about "+".
3. The real problem comes from the email reader autolinking even though we're sending them HTML mail.

If we were to think of ameliorating this:

• For plaintext email I guess we could replace . with [U+200D].[U+200D]
• For HTML we could do the same AND/OR make the username a link to the activate email address AND/OR turn off format-detection by adding the following header to the email:

<meta name="format-detection" content="telephone=no,date=no,address=no,email=no,url=no"/>

If we do add ZWJs we potentially need to ignore any pasted in ZWJ in the username - I guess it would be fine not to do this as the number of people affected would be low.

However I'm equally of the opinion that this is very low severity and is more of a bug than anything else. If a CVE were to be produced for this it should be very low. The impacts above are somewhat hyperbolic

https://github.com/go-gitea/gitea/pull/19169 represents an initial PR that implements the above.

I guess the questions that remain are:

• Should we be setting this format-detection on all of the rest of the email templates?
• Is it worth fixing/dealing with the copy-paste username thing above?

Hello @maintainer Yes, this can be abuse for allowing "." it converts to an URL for which it can redirect a person so it's better to don't allow "." in username. Note the email is coming from gitea so there is more chance of successful exploit of this issue if you send this to 1000 people there will be a chance that 100 of them will click on the malicious domain

I am not telling you to give space in username just you need to remove the dot "." Note:- Most of the applications don't allow "." in the username field even you see GitHub it also doesn't allow it check here:- https://drive.google.com/file/d/1v8gFfbAqSxUqI-FwJIy81Rf7J2co1ykw/view?usp=sharing

You can try the fix as you said so I can test it again.

This bug is verified by other companies and also most of them have fixed it you can also see this medium writeup or you can check HackerOne disclose reports https://medium.com/@abhishake21/hyperlink-injection-easy-money-sometimes-cc1104655300

Here the impact was open redirect as it's redirecting behalf of your company mail and the user will click on it. And the CVSS score should be btw 4.3 - 6.5 medium:-

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

From CVSS perspective is pretty much 0 because availability is not affected at all. I agree this can be used for phishing to get more credible sender but that does not affect Gitea as a product/service from security perspective at all.

CVSS for this is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:N/A:N

CWE is not the valid as this is not problem in Gitea templates but autolink functionality in email client, I don't think there is CWE that would describe this issue.

Hello first of all as you make the attack Attack Complexity is High CVSS score should be CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N and this vulnerability is verified by other companies you can check other application there will be rare chance to get "." in username field. The CWE can be changed to CWE-601 because it lead to open redirect

@maintainer

I really feel like this report is confusing many different things, 1. is gmail allowing periods in emails 2. is periods in usernames which could have email clients autolink, but in those cases it results in something like "Hello google.com" (if google.com is the username), but if that is an issue, then we'd need to block all TLDs, and I know some autolinkers aren't even aware of tlds and just autolink things that look like email addresses. Plenty of other applications also allow periods in their usernames (instagram for example).

Also, we can't block periods in emails, because even if we filter for gmail addreses, some users can host their domains at google and still use this feature.

Also, CWE-1336 is also incorrect, as a user isn't tricking our template engine into rendering something unexpected. As mentioned above, it is the email client that is handling this. And I don't have the sway to change how gmail does anything

Complexity either low or high does not really matter as CVSS score would be still 0.0 but yes it can be also set as low: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:N

As for periods in usernames or them ending with tld should not be limited as there are many valid use cases for this. Quite many companies will use them in form of name.surname for usernames so this is totally valid.

Also CWE-601 is still not valid as open redirect would be if gitea would be redirecting to malicious site, user clicking on link is not open redirect. I don't think there is CWE for this at all.

First of all let me be clear how deeply grateful I am for being alerted to this problem.

This is a class of behaviour I hadn't considered before and we need to check the rest of our email templates to ensure that they're actually behaving correctly. Certainly I suspect we need to add this format-detection meta tag to rest of our emails but I would appreciate your review here. There may be other problems - more likely to be genuinely high severity there.

However...

This is certainly not a CWE-601 - an open redirect means that the injected URL is used in a HTTP Redirect. There is no redirect involved here. The definition of CWE-601 is clear that redirect is involved - and there is not.

This is a CWE-99, CWE-610 or CWE-116. Most likely a CWE-116.

Now, regarding assessment of severity:

If the attacker had the ability to adjust more of the email to add extra detail and/or they were able to make a complete URL I would agree with a high severity rating but... as far as I can see all they can do is inject a domain which will be turned into a link by their email reader in a weird position surrounded by text which should make it clear that it is not meant to be the link.

I can only see the most fatfingered or ignorant of users falling for this. Hence my argument for Low to Very Low severity. It absolutely needed to be fixed though.

If however, you can show how an attacker could further disrupt the email to make it more likely that a user would click on this injected "link" I'd agree with a much higher severity - however I cannot see how they could do it.

If one looks at the documents that were linked with the initial report you'll see that in cases where a similar problem was considered a serious vulnerability the attacker had the ability to more seriously disrupt the structure of the email and insert a full link. In cases where it was considered a non-issue the "link" appeared incongruously within the textual structure of the email and it would be clear from context that this was not a real link. For us the situation is even less likely as the best an attacker can do is link to some weird domain and domain only.

We need to establish the correct severity for security flaws - and the correct category for them. It helps no one to overhype the seriousness of issues or to miscategorise vulnerabilities as it leads to disbelief of the seriousness of other vulnerabilities and disinclines rapid resolution of problems. Similarly it helps no-one to dismiss seriousness of other vulnerabilities. I do agree that this is a problem that needs to be fixed (in fact I have fixed it) but it is NOT a high severity problem and gaming an algorithmic scoring system to make it high severity is not helpful.

But let me once again state how deeply grateful I am for being alerted to this problem.

CWE-116 would probably be most appropriate

@admin would it be possible to change the CWE assessment for this - it is most certainly not an open redirect. I think CWE-116 is most appropriate.

Sorted! 👍