If someone found an actual vulnerability I would want them to contact me privately so that I would have an opportunity to fix the problem before it was known publicly so we could protect our customers. Other than that of course I'm happy to hear of any findings.
1. Was fixed in version 126.96.36.199
2. You are describing a social engineering attack. Most companies use emails or logins that reflect the name of the user so if a hacker knows the names of people in a company he can try these social engineering attacks by calling the IT dept as you have said and if the IT dept is not careful they may help a hacker out. So your concern seems to be that the forums may make it easier to find out names to try in a social engineering attack.
Knowing a userid from mojoPortal does not give access to the login name nor email address and neither the login name nor email address is displayed in the forums but when we auto create a new user in mojoPortal from LDAP the display name is set the same as the login name since we have no other string to use and we have to put something there for display. I don't really see this as an issue related/limited to the userthreads.aspx page because any forum post shows the display name. However it is possible to disable the userthreads view by setting this to false in Web.config/user.config:
<add key="AllowUserThreadBrowsing" value="false"/>
There are some additional mitigations possible if you are concerned that the display names could be used for social engineering attacks. You can prevent users from changing their display names from Site Settings, there is a setting "Allow Users To Change their Display Name". If you wanted to make sure that mojoPortal users automatically created based on LDAP authentication have a display name different than their login name you could implement a custom UserRegisteredEventHandler where you could implement your own routine for deciding what the display name should be and update the display name. Or you could run a query periodically and update the table directly to change the display name if you find any that match the login name.
You mentioned it being for an Intranet, a true Intranet is a private network usually only available to employees so in that case if you are worried about hacking from internal employees, they probably already know who works in the company so these user names are not giving them additional information. On an Extranet (a public facing Intranet) then I can see where you might be concerned about non employees learning names of employees in order to try a social engineering attack against the IT dept. But again the above mitigations are possible.
Of course there are many other ways a hacker can find out the names of some employees at a company, often it is posted on a web site or publicly known or searching news articles one can find out the names of some people working there and they can guess email addresses and login names based on the employee name, so really it is on the IT dept to have good practices about handling calls requesting credentials or credential changes.
Also note that in terms of a brute force attack trying to login to mojoPortal, the account is going to be temporarily locked for a period of time after a specified number of failed login attempts (Configurable parameters in site settings), so its going to take them a lot of time and persistence.